Výkon: dominují DB read-modely — fn_plan_current_bundle 3.8 s, fn_site_full_status 1.7 s (měřeno na živé DB); dále payloady, polling, chybějící virtualizace Planning tabulky, bundle 1.2 MB bez chunking. Responsivita: pevné výšky grafů, tooltip × StatePanel/tabulka kolize na touch, StatePanel grid, breakpointy. Plné detaily a fixy v docs/audits/. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.0 KiB
2.0 KiB
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
- Backend SQL: fn_plan_current_bundle + fn_site_full_status (největší dopad, řeší se samostatně).
- FE quick wins: polling 60/15 s, telemetry limit 420, lazy routes + manualChunks.
- FE větší: 2-vlnové načítání, virtualizace Planning tabulky, memoizace.