Výkonnostní rozpočet

Nikdo se nerozhodne web zpomalit. Stane se to dvaceti čtyřmi správnými rozhodnutími: tady date picker (+40 kB), tam carousel (+25 kB), chat pro marketing (+60 kB), knihovna ikon importovaná celá místo jednotlivých (+35 kB). Po roce posílá stránka 600 kB JavaScriptu a nikdo neumí ukázat commit, který to způsobil.

Rozpočet mění otázku z „můžeme to přidat?“ na „co odebereme, aby se to vešlo?“ To je produktivní hádka: tým začne poměřovat funkce proti uživatelům na pomalém připojení a odpovědí je často 30 kB místo 90 kB.

Vyberte dvě tři čísla, každé svázané s tím, co návštěvník pocítí. Bajty bundlu pro první routu (bundlewatch, size-limit, rozpočet v Lighthouse CI) proti limitu po kompresi — celý JS, ne jen váš kód. LCP pro tři nejdůležitější typy stránek, měřené v terénu na 75. percentilu. A limit počtu požadavků, protože stránka se 120 požadavky je na 4G pomalá, ať je každý soubor sebemenší.

Varovné prahy jsou stejně důležité jako tvrdý limit: build padne při +10 %, varuje při +2 %. Rozpočet, který padne jen na absolutním čísle, vychová tým, který číslo zvedne, aby build prošel. Potřebuje i cestu ven: dočasnou výjimku s vlastníkem a datem vypršení, sepsanou, ne tiché obejití.

Rozpočet měřený jen v laboratoři na rychlém stroji neodchytí nic, co uživatel pocítí. Číslo zvolené bez znalosti současného stavu je buď triviálně splněné, nebo nesplnitelné — nejdřív změřte, pak nastavte limit o 10 % pod dnešní hodnotou. A čtvrté: když je projekt pětistránkový marketingový web s 30 kB JavaScriptu, není co rozpočítávat a čas je lepší dát hero obrázku.

To samé platí pro starý e-shop s dluhem: striktní rozpočet od prvního dne spadne při každém buildu a tým ho za týden umlčí. Začněte západkou — build padne, jen když se číslo zhorší — a utahujte ji, jak se dluh splácí.