Files
ems/docs/audits/frontend-performance-2026-06-11.md
Dusan Vojacek ad4b52c9ce Dokumentace refaktoru a delta-triage skill
- docs/refactor-clean-planner.md: plán Fází 0-4, stav, závazná pravidla
  (golden gate), návod nasazení v2 (shadow → vyhodnocení → přepnutí)
- docs/planning-changelog.md: záznam 2026-06-11 (Fáze 0-3 kompletní)
- docs/04-modules/planning.md: sekce Verze enginu v1/v2 + env flagy
- docs/audits/*: stav implementace FE fixů
- .claude/skills/ems-delta-triage: postup triáže neekonomického chování
  (realita vs plán vs shadow peer vs oracle, verdikt s Kč)
- CLAUDE.md: ukazatele na refaktor, solver_v2 a delta-triage v 'Kde hledat co'

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-11 14:45:16 +02:00

2.5 KiB
Raw Blame History

Audit výkonu frontendu (2026-06-11)

Měřeno na živé DB (site_id=2) + statická analýza kódu a bundle. Plný kontext: agent audit.

TOP problémy podle dopadu

# Problém Měření Kde Fix
1 fn_plan_current_bundle 3 824 ms přímé měření DB /sites/{id}/plan/current, useDashboardData.ts:205, poll 30 s SQL optimalizace fn (viz samostatná analýza), SWR pattern na FE
2 fn_site_full_status 1 719 ms přímé měření DB useFullStatus.ts:21, poll 60 s SQL optimalizace, poll 120 s
3 Promise.all čeká na nejpomalejší (3.8 s) logika useDashboardData.ts:174-406 2 vlny: kritická (status ~100 ms) → extended (plan/telemetrie)
4 vw_telemetry_15m_7d limit 1000 (~450 KB), graf zobrazí 384 logika useDashboardData.ts:212-216 dynamický limit ~420
5 Planning.tsx tabulka 400+ řádků × 16 sloupců bez virtualizace ~6400 DOM nodes Planning.tsx:1618-1846 react-window / tanstack-virtual
6 Recharts Cell mapování 384× v render logika Planning.tsx:1557-1564 custom shape / barva v datech
7 Duplicitní výpočty slotFveDisplayW CPU Planning.tsx:122-232 fveW do PlanTableRow
8 Bundle 1.2 MB bez chunking, eager routes dist měření vite.config.ts, main.tsx manualChunks (recharts/nivo/react), lazy routes
9 Agresivní polling 30 s/5 s 120 req/h useDashboardData.ts:28-29 60 s / 15 s + backoff
10 getMySites → context → data waterfall 1× při startu SiteSelectionContext.tsx fallback UI

Souhrn initial load

~4 300 ms server time (dominuje fn_plan_current_bundle), ~1 185 KB payload, +1.2 MB bundle (cold).

Priority

  1. Backend SQL: fn_plan_current_bundle + fn_site_full_status (největší dopad, řeší se samostatně).
  2. FE quick wins: polling 60/15 s, telemetry limit 420, lazy routes + manualChunks.
  3. FE větší: 2-vlnové načítání, virtualizace Planning tabulky, memoizace.

Stav implementace (2026-06-11)

  • Quick wins (polling 60/15/120 s, payload okna grafu, manualChunks + lazy routes, 2 vlny načítání) — merge 60f5f77, build ověřen.
  • vw_latest_inverter / vw_latest_ev_charger → LATERAL (508→56 ms, 460→75 ms živě) — commit 1d5b97c, projeví se deployem.
  • fn_plan_current_bundle (90 % času ve fn_forecast_pv_slots_range_canonical_ab) — vyžaduje hlubší zásah.
  • Virtualizace Planning tabulky, Recharts Cell mapování.