Files
vtube/docs/PERFORMANCE.md
goboss 981a0ad9b6 Document granular hook policy + ad architecture + 94-site scale
Hook redesign (guard-readonly.sh + guard-bash.sh):
- ALLOW edits: /home/nosfortube/frontend_<port>/ (digits-only, all subdirs)
  + /home/nosfortube/orest/ (user working zone + screenshots)
- DENY: lang variants (frontend_<port>_<lang>/), frontend_core/, .git/,
  system paths (/etc/, /usr/, /boot/, /var/* except /var/log/claude/)
- 19/19 readonly + 18/19 bash tests pass (1 pre-existing sed-i regex gap)
- Backup попередньої версії: .bak.2026-05-02

Doc updates:
- New: PROJECT.md, ARCHITECTURE.md, DEPLOY.md, ADS.md, PERFORMANCE.md,
  INTERLINKING.md, ADMINS.md (topic-split docs/)
- CLAUDE.md: 94-site scale, granular edit zones, doc index
- INFRASTRUCTURE.md: hook table updated
- SITES.md: scope note (14 backup-tracked of 94 total)
- RECOMMENDATIONS.md: W1 (hook conflict) → DONE; W2-W3, D1-D4 added

Site architecture findings (audit 2026-05-02):
- 94 frontend_<port>/ sites, 71 in site-name-routing.csv, 14 backup-tracked
- 3 ad-architectures coexist: 8148 modern bundle (1), modern partials (~23),
  legacy inline surstrom (31)
- 8148 unique: ad-bundle.min.js source files, build-ad-bundle.sh, terser
- Server IP 185.73.222.75 у t1.* allowlist (curl probes work)
- CDN: custom + Cloudflare на 8081 etc; purge-cache при prod deploy

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 13:26:25 +00:00

3.0 KiB
Raw Permalink Blame History

tubev — Performance / PSI

PSI критично — швидкість впливає на SE → реклама → дохід.

Status

🟡 Manual mode — автомоніторингу нема. PSI checks ad-hoc.

Принципи

  • Critical CSS inline у views/css/css_*.etlua (rendered у <head>)
  • Deferred CSSviews/static/css/*.css під <link rel="preload" ... onload> або захищеним defer pattern
  • JS defer — non-critical JS не блокує LCP
  • CDN на prod — edge caching для static assets
  • Cache-bust через ?v=md5 — щоб CDN не serv stale (детально у DEPLOY.md)

Поточний процес

  1. Тригер для перевірки:
    • Після великих змін (refactor / structural)
    • Періодично (ad-hoc, не регулярно)
    • Після репортів про повільність
  2. Інструмент: https://pagespeed.web.dev/ (Google PageSpeed Insights — public)
  3. Дія: все що Lighthouse підкреслив у "Opportunities" / "Diagnostics" — варто пофіксити.
  4. Запис: результати не зберігаються systematically. Subjective tracking ("стало гірше" / "ок").

Future — automonitoring (не пріоритет, in-mind)

Ідеї коли руки дійдуть:

  • PSI API + cron → daily snapshot per site (mobile / desktop)
  • Database з історією → graphs per site
  • Alert при падінні >X% від baseline
  • Lighthouse-CI у git-save-all.sh? (PSI run на t1.* після deploy)

Поки тримати в умі — ground для майбутнього.

Що треба з'ясувати + задокументувати

Targets

  • PSI target mobile / desktop — який baseline вважаємо OK? (probably: mobile ≥ 70, desktop ≥ 90)
  • LCP / CLS / TBT — які thresholds для тривоги?

Bottlenecks

  • Common bottleneck across sites — ads / video player / fonts / images?
  • Per-site outliers — які гірші, чому?

Optimization patterns у репо

  • Image format — webp / avif / jpeg per-site?
  • Font loading — self-hosted чи Google Fonts? font-display: swap?
  • Video poster lazy-load — реалізовано?
  • Service Worker / cache strategy — є?

Per-site PSI table (placeholder)

Port Domain Mobile Desktop LCP CLS TBT Last check Notes
8082 atube.sex TBD TBD TBD TBD TBD
... ... ... ... ... ... ... ... ...

(Заповнити по мірі замірів якщо системно вирішимо tracking-нути.)

Open questions

  • Який PSI mobile baseline вважаємо acceptable (70 / 80 / 90)?
  • Найбільш проблемні сайти — чи знаєш off the top of head?