Modul 6 · 6.1
Co způsobuje pomalý web a jak to změřit?
Modul 6: Rychlost · Doba čtení: 9 minut
Cíl lekce: Po této lekci dokážete změřit, kde se ztrácí čas, a rozpoznat rozdíl mezi pomalostí na straně serveru a pomalostí v prohlížeči.
Klíčové pojmy: TTFB, Core Web Vitals (LCP, INP, CLS), laboratorní data, terénní data, PageSpeed Insights, panel sítě, komprese, externí skripty, limity hostingového balíčku, 503
Nejprve měřit, teprve pak ladit
"Web je pomalý" může mít deset různých příčin. Kdo bez měření nasadí naráz cachovací plugin, plugin pro optimalizaci obrázků a větší balíček, neví pak, co vlastně pomohlo, a navíc má o tři věci víc, které musí hlídat. Proto vždy začněte třemi otázkami (stejnými jako v manuálu Vašeho hostingu):
- Je pomalé všechno, nebo jen administrace? Pomalá administrace s rychlou veřejnou částí ukazuje na pluginy, které v administraci dělají hodně práce, nebo na roboty, kteří útočí na přihlašovací stránku.
- Je to pořád, nebo jen v určitých chvílích? Pouze ve špičce nebo při běhu naplánované úlohy: pak Váš balíček naráží na své limity.
- Je to u všech, nebo jen u Vás? Zkuste to na telefonu přes 4G nebo 5G, nebo požádejte někoho jiného. Pokud je to pomalé jen u Vás, je problém ve Vašem připojení nebo VPN.
Dvě poloviny: server a prohlížeč
Čas, který čeká návštěvník, se skládá ze dvou částí (lekce 1.2):
- Server vytváří HTML: webový server, PHP, pluginy, databáze. To vidíte jako TTFB (time to first byte), čas do prvního bajtu odpovědi. web.dev uvádí jako základní pravidlo, že většina webů by měla usilovat o TTFB 0,8 sekundy nebo méně.
- Prohlížeč přečte toto HTML a poté načte vše, co je v něm obsaženo: styly, skripty, písma, obrázky, video, měřicí kódy, chatovací widgety. Teprve když se toho dostatečně načte, návštěvník něco uvidí.
Vysoké TTFB řešíte na straně serveru: cachování (lekce 6.2), méně nebo lehčí pluginy, novější verze PHP, uklizená databáze (lekce 6.3) nebo více výkonu. Nízké TTFB s přesto pomalou stránkou ukazuje na stranu prohlížeče: příliš velké obrázky, příliš mnoho skriptů, externí prvky.
Core Web Vitals
Google měří zkušenost návštěvníků pomocí tří hodnot, Core Web Vitals:
| Měření | Co měří | Dobré, pokud |
|---|---|---|
| LCP (Largest Contentful Paint) | Jak rychle je viditelný největší kus obsahu (často velká fotografie nebo nadpis) | 2,5 sekundy nebo méně |
| INP (Interaction to Next Paint) | Jak rychle stránka reaguje, když kliknete, klepnete nebo píšete | 200 milisekund nebo méně |
| CLS (Cumulative Layout Shift) | Jak moc se stránka posouvá během načítání | 0,1 nebo méně |
INP nahradilo v březnu 2024 starší měření FID. Google tyto hodnoty mimo jiné používá při řazení výsledků vyhledávání, ale hlavní důvod, proč je zlepšovat, je jednoduchý: návštěvníci odcházejí z pomalé nebo poskakující stránky.
Laboratorní data a terénní data
Existují dva druhy měření a dávají různá čísla:
- Laboratorní data: test v jednom okamžiku, z jednoho místa, se simulovaným telefonem a připojením. Vhodné pro porovnání (před a po změně), ale nejde o skutečného návštěvníka.
- Terénní data: měření u skutečných návštěvníků s Chromem za posledních 28 dní. To je to, co návštěvníci skutečně zažívají. Malé weby mívají na terénní data málo návštěvníků.
PageSpeed Insights (pagespeed.web.dev) zobrazuje obojí: nahoře terénní data (pokud existují), pod nimi laboratorní test se skóre a konkrétními doporučeními. Nedívejte se slepě jen na skóre od 0 do 100. Podívejte se na jednotlivé části: je LCP špatné, protože je server pomalý (TTFB), nebo protože velká fotografie má 3 MB?
Testujte vždy několikrát (čísla se mění) a otestujte i běžnou stránku, ne jen domovskou stránku.
Vlastní pohled přes prohlížeč
Vývojářské nástroje Vašeho prohlížeče (F12) ukazují, co se skutečně děje:
- Panel Síť: obnovte stránku s vypnutou cache (zaškrtněte "Vypnout cache"). Uvidíte každý soubor, který se načítá, jeho velikost a dobu trvání. Seřaďte podle velikosti: největší soubory bývají obrázky. Seřaďte podle domény: kolik toho přichází od jiných stran (písma, měřicí kódy, videa)?
- První požadavek (samotné HTML): klikněte na něj, panel Timing. "Waiting for server response" je TTFB.
- Hlavičky tohoto prvního požadavku: je přítomna komprese (
content-encoding: brnebogzip) a přišla stránka z cache (lekce 6.2)?
Obvyklí viníci
V praxi je pomalost u WordPressu nejčastěji způsobena jedním z těchto:
- Chybí stránková cache: každá stránka se při každé návštěvě vytváří znovu (lekce 6.2).
- Příliš mnoho nebo příliš těžké pluginy, zejména pluginy, které při každém požadavku volají externí služby nebo provádějí náročné dotazy (lekce 5.3).
- Velké obrázky: fotografie o 5 MB z telefonu na domovské stránce (lekce 4.4 a 6.3).
- Těžká šablona nebo page builder, který na každé stránce načítá mnoho skriptů a stylů (lekce 5.1).
- Externí prvky: písma, videa, chatovací widgety, měřicí kódy, tlačítka sociálních sítí od jiných stran. Každé je spojení s jiným serverem, který může být pomalý.
- Stará verze PHP (lekce 8.4).
- Nepořádná databáze: tisíce revizí, spam, logovací tabulky pluginů (lekce 6.3).
- Roboti: crawlery, AI crawlery a pokusy o přihlášení zaměstnávají Váš balíček (lekce 7.3).
- Balíček naráží na své limity: málo výkonu (CPU), procesů nebo paměti pro daný provoz.
Limity Vašeho balíčku
U sdíleného hostingu dostává každý balíček pevnou část serveru: výkon, paměť, rychlost disku a počet současných procesů. Pokud Váš web spotřebovává víc, je zpomalen, nebo návštěvníci dostanou chybovou hlášku 503 (Service Unavailable, u některých poskytovatelů "Resource Limit Is Reached"). U DirectAdmin s CloudLinuxem to vidíte v sekci Resource Usage (s "faults", pokud byl Váš web zpomalen) a pomocí X-Ray vidíte po jednotlivých stránkách, který plugin nebo dotaz spotřebovává čas. Jiní poskytovatelé mají podobné přehledy, někdy jen na vyžádání.
Větší balíček pomůže, pokud Váš web skutečně potřebuje víc (rušný e-shop). Špatně nastavený web tím nevyřešíte: problém se pak vrátí později. Nejprve hledejte příčinu.
Shrnutí
- Nejprve měřte: všechno nebo jen administrace, pořád nebo jen občas, u všech nebo jen u Vás.
- TTFB je strana serveru (usilujte o 0,8 sekundy nebo méně); zbytek je to, co načítá prohlížeč.
- Core Web Vitals: LCP (2,5 s), INP (200 ms) a CLS (0,1); INP nahradilo FID v roce 2024.
- PageSpeed Insights zobrazuje terénní i laboratorní data; panel sítě ukazuje, co se skutečně načítá.
- Většina pomalosti vzniká kvůli chybějící cache, těžkým pluginům, velkým obrázkům a externím prvkům; větší balíček je až poslední krok.
Kvíz
Úkol
Úkol A6.1: Změřte svůj TTFB a kompresi. Zadejte adresu svého webu a, pokud chcete, i jednu běžnou stránku (například kontaktní stránku). Program si u každé stránky třikrát vyžádá odpověď bez cookies a zobrazí prostřední TTFB, velikost HTML a zda server posílá HTML komprimovaně (content-encoding gzip nebo br). Porovnejte výsledek s testem v PageSpeed Insights a poznamenejte si, co Vás zaujalo.
Další čtení
Tyto články popisují kroky v panelech WebOké; v jiných panelech fungují obdobně.
- Příručka k DirectAdmin 18.3: Moje webová stránka je pomalá
- Příručka k DirectAdmin 17.3: Resource Usage: CPU, paměť a procesy
- Příručka k DirectAdmin 17.4: X-Ray: zjišťování pomalých stránek
- Příručka k DirectAdmin 17.5: 503 nebo "Resource Limit Is Reached": co dělat?
- Můj web je pomalý nebo využívá příliš mnoho CPU: jak ho zrychlit
- Core Web Vitals (web.dev, anglicky): https://web.dev/articles/vitals
- PageSpeed Insights: https://pagespeed.web.dev/
