Rychlost webu a Core Web Vitals: proč pomalý web stojí zákazníky

Zákazník, který vás našel v Mapách, klepne na odkaz na web a čeká. Když se mu na displeji dlouho nic neukáže, nebo mu tlačítko „Zavolat“ uteče pod prstem, protože se nahoře dodatečně načetl banner, vrátí se zpátky do výsledků. Tam na něj čeká konkurence.

Rychlost webu se dá změřit zdarma a u malých firemních webů mívá pár opakujících se příčin. Níže je, co Google měří, jak číst výsledky a co obvykle pomůže.

Co jsou Core Web Vitals

Core Web Vitals jsou tři metriky, kterými Google popisuje, jak web působí na skutečné návštěvníky. Od března 2024 jsou to tyto:

Metrika	Co měří	Dobré	Špatné
LCP (Largest Contentful Paint)	kdy se zobrazí největší prvek na obrazovce, typicky úvodní fotka nebo nadpis	do 2,5 s	nad 4 s
INP (Interaction to Next Paint)	jak rychle stránka viditelně zareaguje na klepnutí, kliknutí nebo psaní	do 200 ms	nad 500 ms
CLS (Cumulative Layout Shift)	jak moc obsah nečekaně poskakuje	do 0,1	nad 0,25

INP v březnu 2024 nahradil starší metriku FID. Pokud vám někdo posílá zprávu s FID, pracuje se zastaralými údaji.

Důležitý detail je 75. percentil. Web neplní limit tím, že se vám jednou načte rychle v kanceláři na Wi-Fi. Limit musí splnit aspoň tři ze čtyř návštěv, a to zvlášť na mobilu a zvlášť na počítači. Aby stránka v hodnocení prošla, musí být dobré všechny tři metriky.

Jak rychlost webu změřit

Laboratorní a terénní data

Než otevřete první nástroj, vyplatí se znát rozdíl, jinak vás čísla zmatou:

• Laboratorní data vznikají v testu s předem nastaveným zařízením a sítí. Jsou hned k dispozici a dají se opakovat, ale neukazují, co zažívají vaši skuteční návštěvníci.
• Terénní data pocházejí od skutečných lidí na jejich telefonech a připojeních. Google o nich píše, že nejpřesněji ukazují, s čím mají uživatelé problém.

U Googlu terénní data pocházejí z Chrome UX Reportu (CrUX). Je to veřejná databáze anonymních měření od uživatelů Chromu a čerpají z ní PageSpeed Insights i Search Console.

PageSpeed Insights

Na pagespeed.web.dev vložíte adresu stránky a dostanete dvě části zprávy:

1. Nahoře data od skutečných uživatelů za posledních 28 dní a verdikt, jestli stránka hodnocením Core Web Vitals prošla. Když pro konkrétní stránku není dost dat, nástroj ukáže souhrn za celý web. Když nejsou ani ty, tahle část chybí.
2. Dole laboratorní test Lighthouse se skóre 0 až 100. Pro mobil simuluje telefon střední třídy na pomalejší mobilní síti. Skóre 90 až 100 je dobré, 50 až 89 průměrné, pod 50 špatné.

Skóre se mezi jednotlivými testy liší o několik bodů a není to chyba. Podle dokumentace Lighthouse za tím bývá hlavně změna podmínek, třeba zatížení serveru nebo jiná reklama na stránce. Stovku nečekejte, ani Google ji nepovažuje za cíl.

Search Console: přehled Core Web Vitals

Pokud máte web v Google Search Console, najdete tam přehled Core Web Vitals. Ten nehodnotí jednotlivé adresy, ale skupiny podobných stránek (třeba všechny články blogu) a každé skupině přidělí stav podle její nejhorší metriky. Po opravě kliknete na ověření opravy a Search Console pak 28 dní sleduje, jestli se problém neobjevuje dál.

U menších webů tu často uvidíte hlášku, že data nejsou k dispozici. Znamená to, že Chrome nenasbíral dost anonymních měření. Nic vám tím nehrozí, jen se musíte spolehnout na laboratorní test.

Když terénní data nemáte

Většina webů řemeslníků, salonů a poraden má tak málo návštěv, že je CrUX nezachytí. Pak doporučuji:

• testovat v PageSpeed Insights vždy mobilní verzi, úvodní stránku a stránku nejdůležitější služby,
• otevřít web na svém telefonu přes mobilní data, ne přes firemní Wi-Fi, a sledovat, kdy se ukáže kontakt,
• zkusit klepnout na telefon a odeslat formulář dřív, než se stránka úplně načte.

Kolik zákazníků vlastně pomalý web stojí

Tady narazíte na hodně čísel bez zdroje, proto opatrně.

Nejčastěji opakovaná statistika tvrdí, že 53 % lidí odejde, když se web na mobilu načítá déle než 3 sekundy. Pochází ze studie Googlu a DoubleClicku z roku 2016 (The Need for Mobile Speed). Podle poznámky pod čarou jde o anonymní data Google Analytics zhruba z 3 700 mobilních webů z března 2016, které souhlasily se sdílením srovnávacích dat. Studie byla psaná pro vydavatele, kteří se živí reklamou, a další čísla v ní byla měřená na síti 3G. Původní formulace navíc zní, že takové návštěvy „pravděpodobně budou opuštěny“. Jako ilustrace, že na rychlosti záleží, to obstojí. Jako přesné číslo pro dnešní web českého instalatéra ne.

Novější je studie Milliseconds Make Millions (Deloitte pro Google, 2020). Čtyři týdny sledovala mobilní weby značek z maloobchodu, cestování, luxusního zboží a sběru poptávek v Evropě a USA. Při zrychlení o 0,1 s zaznamenala u maloobchodu o 8,4 % víc konverzí a u stránek pro sběr poptávek o 8,3 % lepší míru okamžitého opuštění. Pozor: šlo o velké značky, studii zadal Google a autoři popisují souvislost, ne přímý důkaz příčiny.

Univerzální číslo pro malou firmu nikdo nemá. Rozumnější je měřit vlastní web: kolik lidí z mobilu odchází hned z úvodní stránky a kolik jich klepne na telefon nebo odešle formulář. Poptávky by vám přitom měly chodit na jedno místo, jinak nepoznáte, jestli zrychlení něco změnilo. Víc o tom v článku Co musí mít firemní web, aby přinášel poptávky.

Ovlivňuje rychlost pozice v Googlu?

Ano, ale méně, než slibují prodejci „SEO optimalizace rychlosti“. Google v dokumentaci píše tři věci:

• Core Web Vitals jeho systémy pro řazení používají a dobré hodnoty doporučuje.
• Dobré výsledky v Search Console nebo jiných nástrojích nezaručují horní pozice. Snaha o dokonalé skóre jen kvůli SEO podle Googlu nemusí být nejlepší využití času.
• Google vždy ukazuje nejrelevantnější obsah, i když je stránka pomalejší. Dobrý zážitek ze stránky pomůže hlavně tam, kde je víc podobně relevantních výsledků.

Pro malou firmu z toho plyne jednoduché pořadí. Nejdřív obsah, který odpovídá na to, co lidé hledají. Potom rychlost do zelených hodnot. Honit poslední body skóre nemá smysl.

Co web malé firmy brzdí nejčastěji

Obrovské fotky

Fotka z telefonu má běžně několik megabajtů a tisíce pixelů na šířku. Na webu se přitom zobrazí v ploše o šířce telefonu. Na úvodní stránce bývá právě taková fotka prvkem LCP.

Co pomůže:

• zmenšit fotky na velikost, ve které se opravdu zobrazují, a pro telefony nabízet menší verzi,
• ukládat je ve formátu WebP nebo AVIF, které mají při stejné kvalitě menší velikost než JPEG a PNG,
• úvodní fotku nenačítat líně (loading=“lazy” ji zpozdí) a naopak jí dát vysokou prioritu (fetchpriority=“high”),
• u všech obrázků uvádět šířku a výšku, aby prohlížeč rezervoval místo a obsah neposkakoval.

Page buildery a těžké šablony

Vizuální editory a univerzální šablony musí umět všechno, takže do každé stránky přibalí spoustu kódu, který vaše stránka nepotřebuje. Výsledkem bývá pomalé načtení i pomalá reakce na klepnutí, tedy špatné INP. Google mezi příčinami pomalé reakce uvádí dlouhé úlohy na hlavním vlákně prohlížeče a příliš velké množství prvků na stránce.

Pokud web na WordPressu stojí na builderu a desítkách pluginů, začněte úklidem: vypněte pluginy, které nic nedělají, a odstraňte posuvníky a animace, které nikdo nečte. U nového webu je jednodušší rychlost zadat od začátku než ji dohánět.

Skripty třetích stran

Chatovací okno, měřicí kódy, reklamní pixely, widget s recenzemi, vložená mapa a video z YouTube. Každý z nich načítá vlastní kód z cizího serveru, který neovládáte.

Co pomůže:

• projít, co na webu opravdu běží, a smazat kódy po starých kampaních,
• u videa, mapy a chatu použít takzvanou fasádu: místo přehrávače se zobrazí jen náhled a skutečný kód se načte, až na něj návštěvník klikne,
• měřicí a marketingové skripty načítat až po souhlasu s cookies. U cookies, které nejsou nezbytné, to vyžaduje i zákon o elektronických komunikacích.

Levný hosting

Než se cokoli zobrazí, musí server odpovědět. Tuhle dobu měří metrika TTFB a web.dev za dobrou považuje odpověď do 0,8 sekundy, nad 1,8 sekundy za špatnou. Přetížený sdílený hosting nebo web, který každou stránku složitě skládá z databáze, se sem často nevejde.

Co pomůže: cache stránek, CDN, které posílá obsah ze serveru blíž návštěvníkovi, a omezení přesměrování. Když web přes reklamu nebo zkrácený odkaz projde několika přesměrováními, každé z nich přidává čekání.

Webové fonty

Vlastní písmo vypadá dobře, ale prohlížeč si ho musí stáhnout. Do té doby text buď nevidíte, nebo se zobrazí náhradním písmem a po načtení se přeskládá. Obojí může způsobit poskakování obsahu.

Co pomůže: méně řezů písma (tři váhy místo osmi), přednačtení hlavního fontu a nastavení náhradního písma s podobnými rozměry. Systémová písma jsou nejrychlejší varianta.

Lišty a bannery, které odsunou obsah

Cookie lišta, akční pruh nebo widget vložený nad obsah až po načtení posune celou stránku dolů. Návštěvník chce klepnout na telefon a trefí něco jiného. Pro takové prvky je potřeba rezervovat místo předem, nebo je zobrazit jako překryvnou vrstvu, která obsah neposouvá.

Co udělat tento týden

1. Otestujte v PageSpeed Insights mobilní verzi úvodní stránky a stránky hlavní služby. Zapište si LCP, INP, CLS a skóre.
2. Podívejte se, co je prvkem LCP. Pokud je to fotka, zmenšete ji a převeďte do WebP.
3. Projděte skripty třetích stran a smažte, co nepoužíváte.
4. Pokud máte Search Console, otevřete přehled Core Web Vitals a zjistěte, které skupiny stránek mají problém.
5. Otevřete web na telefonu přes mobilní data a vyzkoušejte, jestli jde hned zavolat nebo odeslat poptávku.

Když po úklidu zůstane web pomalý kvůli šabloně nebo hostingu, většinou už nejde o drobné úpravy. Jak stavíme nové weby, popisujeme na stránce Tvorba webu na míru.