Znáte to: agentura pošle screenshot z PageSpeed Insights se zeleným kolečkem a číslem 92, vy otevřete web na mobilu v tramvaji a první obrázek naskočí po čtyřech vteřinách. Obě věci jsou pravda zároveň. Rychlost webu totiž není jedno číslo, ale dvě úplně různé věci, které se měří jinak, znamenají něco jiného a Google je používá k jiným účelům. Kdo tomu nerozumí, opravuje špatné věci, platí za zrychlování, které nikdo nepozná, a diví se, proč pozice ve vyhledávání stojí.
V tomhle článku projdeme, co se za skóre rychlosti opravdu skrývá, proč se vaše měření liší od toho, co vidí Google, které tři věci zpomalují většinu českých webů a v jakém pořadí je opravit. Na konci je postup, který zvládnete za jedno odpoledne bez programátora.
Dvě různá měření: laboratoř a skuteční návštěvníci
Když spustíte test v PageSpeed Insights nebo v našem měření rychlosti webu, proběhne takzvané laboratorní měření. Nástroj Lighthouse otevře vaši stránku v prohlížeči se simulovaným pomalým mobilem a pomalejším připojením, zaznamená, co se kdy vykreslilo, a spočítá skóre 0 až 100. Je to zkouška v kontrolovaných podmínkách: pokaždé stejný „telefon", stejná „síť", stejná stránka. Hodí se na porovnání před a po změně.
Druhé měření je z terénu. Chrome na telefonech a počítačích skutečných lidí, kteří k tomu dali souhlas, posílá Googlu anonymně údaje o tom, jak rychle se vaše stránky načetly. Google je sbírá do databáze CrUX (Chrome User Experience Report) a z ní bere hodnoty, které vidíte v Search Console pod názvem Core Web Vitals. Tohle číslo nezměříte sami, Google vám ho ukáže, až když má web za posledních 28 dní dost návštěv.
A tady je ten rozpor z úvodu: pro pořadí ve vyhledávání Google používá terénní data, ne laboratorní skóre. Lighthouse 92 je dobrá zpráva pro vývojáře, ale pokud polovina vašich návštěvníků přichází přes slabý signál z venkova na tři roky starém telefonu, jejich zkušenost je jiná a Google to ví. Platí to i naopak: web s laboratorním skóre 60 může mít terénní hodnoty v pořádku, protože jeho návštěvníci sedí na rychlém Wi-Fi v kancelářích.
Proto náš nástroj ukazuje obojí vedle sebe: laboratorní měření, které spustíte kdykoli, a terénní hodnoty z CrUX, pokud je Google pro vaši doménu má. Když se liší, je to samo o sobě informace o tom, kdo k vám chodí.
Odkud se měří, je důležitější, než si myslíte
Většina online nástrojů na rychlost měří ze serverů v USA nebo v západní Evropě. Pro český web, který běží na českém hostingu a má návštěvníky z Česka, to znamená, že k naměřenému času připočítávají pár set milisekund jen za cestu přes půl kontinentu. Na výsledném skóre to může udělat deset i patnáct bodů a hlavně to zkresluje, co opravit.
Typický příklad: web na českém hostingu bez CDN. Test z Frankfurtu hlásí pomalou odezvu serveru a doporučí CDN. Test z Prahy ukáže, že server odpovídá za 80 milisekund a skutečný problém je obrázek o třech megabajtech v hlavičce. Oprava obrázku je zadarmo a trvá deset minut, CDN je měsíční platba a dva dny práce. Měření z Prahy jsme do nástroje dali přesně kvůli tomuhle rozhodování.
Tři čísla, na kterých záleží
Za skóre se schovávají desítky metrik, ale pro pořadí ve vyhledávání i pro pocit návštěvníka rozhodují tři. Google jim říká Core Web Vitals a u každé má práh, do kterého je „dobrá".
LCP, Largest Contentful Paint: za jak dlouho se vykreslí největší prvek v první obrazovce, obvykle hlavní obrázek nebo nadpis. Dobré je do 2,5 vteřiny. Tohle je metrika, kterou návštěvník vnímá jako „načetlo se". Nejčastější viník: obrovský obrázek v hlavičce, obrázek načítaný až skriptem, nebo pomalý server.
INP, Interaction to Next Paint: jak dlouho trvá, než stránka zareaguje na klepnutí, od okamžiku dotyku do změny na obrazovce. Dobré je do 200 milisekund. Když klepnete na menu a nic se dvě vteřiny neděje, je to INP. Viník bývá JavaScript: chat, cookie lišta, měřicí skripty, animace, které blokují hlavní vlákno prohlížeče.
CLS, Cumulative Layout Shift: jak moc stránka při načítání poskakuje. Dobré je do 0,1. Znáte to z e-shopů: chcete kliknout na tlačítko, nad ním se dovykreslí banner, tlačítko ujede a kliknete na něco jiného. Viník: obrázky a reklamy bez zadaných rozměrů, fonty, které se načtou později a přeskládají text.
Všimněte si, co v seznamu není: celková velikost stránky, počet požadavků, „plně načteno" za X vteřin. To jsou pomocné údaje. Stránka o pěti megabajtech může mít výborné LCP, když se důležité věci načtou první a zbytek doběhne, až když už návštěvník čte.
Co zpomaluje většinu českých webů
Za poslední měsíce jsme nástrojem změřili stovky stránek a vzorec se opakuje. Nejsou to exotické technické problémy, ale tři věci, které vznikají při běžné správě webu.
Obrázky nahrané rovnou z telefonu. Fotka z mobilu má 4 000 pixelů na šířku a tři megabajty. Na webu se zobrazí v šířce 800 pixelů. Prohlížeč na mobilu stáhne všechny tři megabajty a pak je zmenší. Když je takových fotek na úvodní stránce šest, je to dvacet megabajtů, což na slabém signálu znamená deset vteřin. Řešení: zmenšit na šířku, ve které se opravdu zobrazují, a uložit jako WebP. Dnes to umí každý redakční systém i WordPress s jedním pluginem. Tohle je zdaleka nejčastější a nejlevnější oprava.
Skripty třetích stran. Chat, cookie lišta, Facebook Pixel, Google Tag Manager, mapa, YouTube video, tlačítka pro sdílení, hodnocení Heureka. Každý z nich načítá vlastní kód, často stovky kilobajtů, a ten běží dřív, než se stránka vykreslí. Viděli jsme weby, kde cizí skripty tvořily 70 procent toho, co prohlížeč stahuje. Řešení: každý skript, který na stránce opravdu nepotřebujete, pryč. Co zůstane, načítat se zpožděním (atribut defer nebo načtení až po první interakci). Videa vkládat jako náhledový obrázek, který se po kliknutí teprve promění v přehrávač.
Pomalá první odpověď serveru. Když server posílá první bajt stránky až po vteřině, nepomůže žádná optimalizace obrázků. Příčiny: levný sdílený hosting přetížený jinými weby, WordPress s třiceti pluginy a bez cache, nebo e-shop, který při každém načtení počítá něco, co by mohl mít spočítané. Řešení: zapnout serverovou cache stránek (u WordPressu stačí plugin), a pokud to nepomůže, vyměnit hosting. Z Prahy to změříte přímo jako TTFB, Time to First Byte, u českého webu by měl být pod 300 milisekund.
Jak číst report, aby vás nezahltil
Výstup z měření má několik částí a každá odpovídá na jinou otázku. Když je budete číst v tomhle pořadí, ušetříte si půl hodiny tápání.
Skóre podle Googlu nahoře je ta známka ze zkoušky, zvlášť pro mobil a pro počítač. Mobil bývá o dvacet až třicet bodů horší, to je normální: měří se na simulovaném pomalém telefonu přes pomalou síť. Vedle skóre jsou hodnoty FCP, LCP, TBT, CLS a Speed Index; barva u každé říká, jestli je v zelené, oranžové nebo červené. Dívejte se hlavně na LCP a CLS, zbytek je doplněk.
Reální návštěvníci je oddíl s terénními daty z Chrome. Pokud tam stojí, že Google pro váš web nemá dost měření, není to chyba ani známka pomalosti; prostě na web nechodí tolik lidí s Chromem, aby vznikl spolehlivý vzorek. Platí to pro většinu menších českých webů. Řiďte se pak laboratoří a měřením z Prahy.
Doporučení Googlu jsou položky, které navrhuje Lighthouse, seřazené podle odhadované úspory. Pozor na jednotky: „úspora 300 ms" u nepoužívaných stylů zní dobře, ale pokud je zároveň v hlavičce obrázek o dvou megabajtech, přeskočte styly a jděte na obrázek. Lighthouse řadí podle svého modelu, ne podle vaší pracnosti.
Měření z Prahy je to, co Google neumí: tři měření z českého datacentra, z nich medián. Pruh rozkládá čas na DNS, navázání šifrovaného spojení, čekání na server a stažení HTML. Pokud je nejdelší dílek „čekání na server", je problém na hostingu nebo v aplikaci. Pokud je server rychlý a stránka je přesto pomalá, problém je v tom, co se stahuje potom, tedy obrázky a skripty.
Akční plán z Prahy je seznam konkrétních nálezů seřazený podle dopadu: velikost obrázků (i s výčtem těch největších), obrázky bez rozměrů, komprese, cache, přesměrování. U každého je napsáno, co udělat. Tohle je část, kterou pošlete správci webu nebo agentuře, když chcete, aby opravili správné věci v správném pořadí.
Tři mýty, které stojí peníze
„Stačí nainstalovat plugin na rychlost." Pluginy typu „optimalizace jedním kliknutím" zapnou cache a minifikaci, což pomůže, ale neumí zmenšit fotku, kterou jste nahráli ze mobilu, ani vyhodit chat, který nikdo neobsluhuje. Často přidají vlastní skript, a web je po nich o kousek pomalejší. Nejdřív odstraňte, co nepotřebujete, teprve pak optimalizujte, co zůstalo.
„Potřebujeme CDN." Síť pro doručování obsahu pomáhá, když máte návštěvníky z více zemí nebo když je server opravdu přetížený. Český web s českými návštěvníky na slušném českém hostingu z ní získá málo a přibude mu další služba, která se platí a občas rozbije. Nejdřív změřte TTFB z Prahy; pokud je pod 300 ms, CDN kvůli rychlosti nepotřebujete.
„Když bude skóre 100, Google nás posune nahoru." Rychlost je pro Google jedním z mnoha signálů a rozhoduje spíš jako hranice než jako závod: web v zelené už dalším zrychlením nic nezíská. Obsah, odkazy a to, jestli stránka odpovídá na to, co lidé hledají, váží řádově víc. Zrychlete web do zelené a pak investujte energii do obsahu; rozdíl mezi 85 a 100 nikdo z návštěvníků nepozná.
Proč na tom záleží i mimo Google
O rychlosti se mluví hlavně kvůli SEO, ale vyhledávání je ve skutečnosti ten menší důvod. Větší je chování lidí. Googlu vlastní data říkají, že při prodloužení načítání z 1 na 3 vteřiny stoupne pravděpodobnost odchodu o třetinu, a při 5 vteřinách o 90 procent. Platí to tím víc, čím dražší provoz máte: návštěvník z placené reklamy, který odejde dřív, než se stránka načte, je zaplacený klik bez šance na objednávku.
U e-shopů se to dá vyčíslit přímo. Pokud máte konverzi 2 procenta a zrychlení o vteřinu vám podle dat velkých e-shopů přinese zhruba 7 až 10 procent navíc, je to při obratu 300 000 Kč měsíčně dalších 20 až 30 tisíc, každý měsíc, bez jediné koruny navíc za reklamu. Málokterá úprava webu má takovou návratnost jako hodina strávená nad obrázky.
Postup na jedno odpoledne
Nepotřebujete programátora, abyste udělali osmdesát procent práce. Tady je pořadí, ve kterém to má smysl.
1. Změřte výchozí stav a uložte si ho. Spusťte měření rychlosti úvodní stránky a dvou nejnavštěvovanějších podstránek (produkt, ceník, článek). Zapište si skóre a tři hodnoty. Bez výchozího stavu později nepoznáte, co pomohlo. V účtu na rdy.cz se vám měření ukládají a v Vývoji webu vidíte graf v čase.
2. Obrázky. Report vám vypíše obrázky, které jsou větší, než je potřeba, i s tím, kolik by ušetřily. Začněte těmi v první obrazovce, ty rozhodují o LCP. Zmenšit, převést na WebP, u všech obrázků doplnit rozměry (šířku a výšku), tím zmizí i poskakování.
3. Skripty. Vypište si, co všechno na webu běží. Ke každému se zeptejte: kdy jsem se naposledy díval na data, která sbírá? Chat, který nikdo neobsluhuje, a pixel ze sítě, kde už neinzerujete, jsou kandidáti na smazání. Zbytek nastavte na zpožděné načítání.
4. Cache a hosting. Pokud je první odpověď serveru nad 500 milisekund, zapněte cache. Pokud to nepomůže, je čas na jiný tarif nebo hosting; rozdíl mezi levným sdíleným a slušným hostingem je dnes pár set korun měsíčně.
5. Změřte znovu a nastavte hlídání. Po úpravách spusťte stejná tři měření. Zrychlení webu není jednorázová akce: každý nový plugin, banner nebo fotka z telefonu ho zase zpomalí. Proto jsme k měření přidali Hlídač webu, který stránku měří pravidelně a pošle e-mail, když se zhorší skóre nebo některá z hodnot; pokles nejdřív ověří druhým měřením, aby nehlásil náhodný výkyv.
Co nečekat a kde je hranice
Laboratorní skóre 100 není cíl. Je to známka za zkoušku v ideálních podmínkách a dohnat posledních deset bodů stojí obvykle víc, než přinese. Rozumný cíl pro firemní web je skóre nad 80 na mobilu a všechny tři Core Web Vitals v zelené v terénních datech. Pro e-shop s tisíci produkty je nad 70 dobrý výsledek, protože každý produktový výpis nese fotky a skripty, které se jen tak neodstraní.
Některé věci také ovlivnit nemůžete. Terénní data závisí na tom, odkud a na čem k vám lidé chodí; web pro stavební firmu, na který se dívají lidé na stavbách přes mobilní data, bude mít horší čísla než intranet velké banky. A pokud měříte web, který Google nezná (nový, nebo s málo návštěvami), terénní data prostě nejsou a zbývá laboratoř.
Rychlost je také jen jedna část toho, jak web funguje. Když je pomalý, lidé odcházejí; když je rychlý, ale nejde pochopit, co nabízíte, odcházejí také. Proto doporučujeme vedle rychlosti projít i SEO analýzu, kontrolu titulků, popisků a struktury, a deset nejčastějších chyb, které české weby opakují. Rychlý web se špatným obsahem je rychle opuštěný web.
Začněte jedním měřením
Nejlepší čas na změření rychlosti byl před měsícem, druhý nejlepší je teď. Vložte adresu do měření rychlosti webu, počkejte minutu a podívejte se, co je v reportu nahoře. Zpravidla tam bude jeden z těch tří problémů z tohoto článku, a zpravidla půjde opravit ještě dnes. A pokud u vás report ukazuje něco jiného, než o čem tu píšeme, napište nám na info@rdy.cz; takové případy nás zajímají nejvíc.
