Proč je web pomalý

Pomalý web nepoznáte podle toho, že by se točilo kolečko. Poznáte ho podle poptávek, které nepřijdou, protože člověk odešel dřív, než se stihlo načíst první tlačítko.

Rychlost se neměří pocitem, měří se třemi čísly

Když se ptám klienta, jestli má rychlý web, slyším skoro vždycky, že se mu zdá v pohodě. Jenže on ho má v cache, sedí na optice a dívá se na něj na velkém monitoru. Návštěvník z mobilu na LTE cestou z práce vidí něco jiného. Rychlost proto neřeším pocitem, ale třemi konkrétními čísly.

Largest Contentful Paint by měl být pod 2,5 sekundy, Interaction to Next Paint pod 200 milisekund a Cumulative Layout Shift pod 0,1. Tahle tři čísla používá Google jako součást hodnocení stránky a zároveň docela přesně popisují, co člověk cítí. LCP je čekání na obsah, INP je zpoždění po kliknutí, CLS je poskakování stránky pod prstem.

Měřím vždy dvakrát. Laboratorně přes PageSpeed Insights se simulovaným pomalým mobilem, protože tam vidím konkrétní viníky s milisekundami, a potom v reálných datech z Chrome UX Reportu, protože ta ukazují, co zažívají skuteční lidé. Když se čísla rozcházejí, věřím reálným datům. Laboratoř umí lhát oběma směry, hlavně u webů s malou návštěvností.

Obrázky tvoří 70 až 90 procent váhy stránky

U webů, které dostávám k opravě, tvoří obrázky běžně 70 až 90 procent přenesených dat. Typický případ: fotograf nahraje do galerie snímky rovnou z Lightroomu, 4 000 pixelů na šířku a tři megabajty kus. Prohlížeč je zmenší na 600 pixelů, ale stáhnout musí originál. Deset takových fotek znamená třicet megabajtů a osm sekund čekání na mobilu.

Oprava je nudná a funguje vždycky. Fotku zmenším na skutečnou zobrazovanou velikost krát dva kvůli retina displejům, uložím ve formátu WebP nebo AVIF a doplním atributy width a height, aby stránka nepodskakovala. Ze tří megabajtů se stane 120 kilobajtů a rozdíl na oko nikdo nepozná. U jednoho e-shopu to samo o sobě srazilo LCP z 6,1 na 2,3 sekundy.

• Fotky ukládat v šířce maximálně 1 600 pixelů, u produktových náhledů stačí 800
• WebP jako výchozí formát, AVIF u velkých fotek v hlavičce, PNG jen pro loga s průhledností
• Atribut loading nastavený na lazy u všeho pod prvním překlopením obrazovky
• Hero obrázek naopak načítat přednostně, lazy load na něm rychlost zhoršuje
• Vždy vyplněné width a height, jinak vzniká poskakování obsahu a špatné CLS
• Žádné video na pozadí v hlavičce, pokud pro něj není důvod v konverzích

Každý widget třetí strany si účtuje svoje milisekundy

Cookie lišta, chat, pixel Meta, Google Analytics, mapa v patičce, widget s recenzemi, embed z Instagramu. Každá z těch věcí vypadá nevinně a každá stáhne vlastní balík javascriptu z cizího serveru. Na jednom webu instalatéra jsem napočítal jedenáct externích skriptů, dohromady 1,4 megabajtu kódu. Samotný web měl přitom 180 kilobajtů.

Zjistit to jde za minutu. V Chrome otevřete vývojářské nástroje, záložku Network, filtr JS a seřadíte podle velikosti. Uvidíte přesně, kdo si bere kolik. Potom se u každého řádku zeptejte, jestli ta věc za poslední tři měsíce něco přinesla. U chatu, který nikdo nepoužil, je odpověď jasná.

• Cookie lišta z hotového řešení: 60 až 200 kB, vlastní zvládne totéž ve 3 kB
• Chat widget: 300 až 700 kB, načítat až po kliknutí na ikonu
• Google Analytics 4: kolem 80 kB, stačí načíst se zpožděním po první interakci
• Meta pixel: kolem 120 kB, při serverovém měření přes CAPI se dá odlehčit
• Embed Instagramu nebo YouTube: 500 kB a víc, nahradit náhledovým obrázkem
• Knihovny na slidery a karusely: 100 až 300 kB, ve většině případů zbytečné

Hosting rozhoduje o první půlsekundě

Time to First Byte je čas, než server pošle první data. Na levném sdíleném hostingu, kde na jednom stroji běží tři sta webů, jsem naměřil běžně 900 milisekund. To je skoro celá sekunda, ve které se nedělo vůbec nic, protože prohlížeč ještě neměl co kreslit. Žádná optimalizace obrázků tenhle handicap nedožene.

Statický web na CDN má TTFB kolem 50 milisekund, protože soubory leží na serveru fyzicky blízko návštěvníkovi. Pro firemní prezentaci, která se mění jednou za měsíc, je to nejlevnější a nejrychlejší varianta. Databázi a PHP potřebujete jen tehdy, když web opravdu něco počítá nebo prodává. Většina firemních webů, které vidím, nepotřebuje ani jedno.

Písma a jeden velký CSS soubor blokují vykreslení

Písmo z Google Fonts se stahuje z cizí domény, což znamená další DNS dotaz, další spojení a odklad textu. Řešení je stáhnout si soubor woff2, nahrát ho k sobě a přidat font display swap, aby se text ukázal hned v systémovém písmu a přeblikl, až dorazí to vaše. Tři sta milisekund pryč.

Druhý blokátor je jeden velký CSS soubor, ve kterém je styl pro všechny stránky webu. Prohlížeč musí stáhnout a zpracovat celý, než nakreslí byť jedno písmeno. U šablon z tržišť má tenhle soubor běžně 400 kilobajtů, z toho se na úvodní stránce použije osm procent. Odstranit nepoužité styly je nudná práce na hodinu, ale je vidět okamžitě.

Postup zrychlení, který zvládnete za odpoledne

Postupuji vždy stejně a od nejtěžšího viníka. Nejdřív obrázky, protože tam je devadesát procent přínosu za deset procent práce. Pak škrtání skriptů, pak písma, pak hosting. Kód se ladí naposledy, protože je to nejdražší a nejméně vděčné. Většinu webů dostanu pod 2,5 sekundy bez toho, abych sáhl na strukturu.

Když web někdo staví znovu, dělám rychlost součástí zadání, ne dodatečnou opravou. Nový web stavím od 19 990 Kč a dodávám do sedmi dní, měření přes Pixel a CAPI stojí 6 900 Kč jednorázově. Samotný provoz a dohled nad rychlostí je 990 Kč měsíčně, což je míň, než stojí jedna ztracená poptávka.

• Změřte LCP na mobilu a číslo si zapište, ať máte s čím porovnávat
• Zmenšete a překonvertujte všechny obrázky, začněte hlavičkou
• Vypněte všechno, co jste za poslední půlrok k ničemu nepoužili
• Přesuňte písma na vlastní doménu a nastavte font display swap
• Odložte měřicí skripty až za první interakci návštěvníka
• Otestujte znovu a rozdíl si uložte jako snímek obrazovky

Časté otázky

Jaká rychlost webu je dost dobrá?

Cílím na Largest Contentful Paint pod 2,5 sekundy na mobilu ve 4G a na celkovou váhu stránky do 1,5 megabajtu. Pod tuhle hranici se dostane devět z deseti firemních webů. Honit se za stovkou bodů v PageSpeed Insights nemá smysl, posledních patnáct bodů stojí víc práce než celý zbytek dohromady.

Pomůže přechod na dražší hosting?

Pomůže, ale jen s tou částí, kterou hosting ovlivňuje, tedy s časem do prvního bajtu. Když máte na stránce dvacet megabajtů fotek, přesun na výkonnější server ušetří půl sekundy a zbylých sedm zůstane. Nejdřív proto vždy řeším obsah stránky a teprve potom, jestli má smysl se stěhovat jinam.

Kolik stojí zrychlení existujícího webu?

Záleží na tom, na čem web běží. U statického webu nebo běžného WordPressu je to zpravidla jeden až dva dny práce. Když je problém v šabloně z tržiště, která táhne pět knihoven, bývá levnější postavit web znovu od 19 990 Kč než donekonečna opravovat cizí kód, který nikdo nezdokumentoval.