Jak v Google Search Console číst Core Web Vitals a zlepšit rychlost webu

Google Search Console (GSC) je bezplatný nástroj, ve kterém vám Google ukazuje, jak vidí váš web ve vyhledávání. Patří sem i pohled na rychlost, tedy na metriky Core Web Vitals. A právě tady se laici nejčastěji ztrácejí.

Tenhle článek je pro lidi, kteří mají rychlost webu na starost, ale v Search Console tápou. Pro vývojáře, marketéry, projektové manažery a majitele webů, kteří potřebují číst data o Core Web Vitals a vědět, co s tím dělat dál.

Proč to píšeme zrovna my? V PageSpeed.ONE jsme úspěšně zoptimalizovali desítky velkých i malých webů našich klientů. Search Console je u nás druhý nejdůležitější nástroj, hned po vlastním monitoringu rychlosti. Bereme ji vážně, protože v praxi pravidelně vidíme souvislost mezi Core Web Vitals a výsledky v SEO, cenou za proklik v PPC i konverzemi.

Co je Google Search Console a proč ji řešit#

Google Search Console je sada reportů o tom, jak si váš web vede v Google Vyhledávání. Uvidíte v ní, na jaké dotazy se zobrazujete, které stránky Google zaindexoval, jaké má s webem technické problémy a jak hodnotí uživatelskou zkušenost včetně rychlosti.

Pro webaře je zásadní z jednoho prostého důvodu: jsou to data přímo od Googlu, ne odhad třetí strany. Když Google řekne, že část vašich stránek je z pohledu Core Web Vitals „špatná“, je to ten samý signál, který se promítá do hodnocení ve vyhledávání.

A proč obzvlášť pro rychlost? Rychlost je jedním z hodnotících signálů. Má vliv na SEO i na cenu za proklik v PPC, protože pomalá vstupní stránka zhoršuje Quality Score v Google Ads. Vliv Core Web Vitals na byznys vídáme opakovaně, například u e-shopu Denatura, kde jsme optimalizaci rychlosti spojili s průběžnou analýzou v Search Console a postupně viděli zlepšení pozic ve vyhledávání.

Search Console rychle ukáže, kde máte z pohledu Googlu problémové URL nebo skupiny stránek.

Jak Google měří rychlost#

Než se pustíme do reportů, je potřeba rozumět tomu, jak Google rychlost vůbec měří. Bez toho se v číslech ztratíte.

Základy: metriky, CrUX a hodnocení podle nejhorší metriky#

Rychlost popisují tři metriky Core Web Vitals: rychlost načtení (LCP), rychlost reakce na interakci (INP) a vizuální stabilita (CLS). Každá má svoje hranice pro „dobrou“, „vyžaduje vylepšení“ a „špatnou“ hodnotu. Podrobně je rozebíráme v samostatných článcích o LCP, INP a CLS.

Důležité je, odkud čísla pocházejí. Nejsou to jednorázové testy, ale data od reálných uživatelů Chrome z datasetu Chrome UX Report (CrUX). Google sbírá rychlost tak, jak ji zažili skuteční návštěvníci za posledních 28 dní, a to zvlášť pro mobil a desktop.

Pozor na jedno pravidlo, které mate i pokročilé: skupina stránek se hodnotí podle nejhorší metriky. Pokud má skupina špatný CLS, ale výborný INP, celá skupina je „špatná“. Stačí jeden problém a celá skupina spadne do červené.

Tři úrovně měření rychlosti#

Rychlost se neměří jen na jedné úrovni. Vyplatí se rozlišovat tři, protože každá odpovídá na jinou otázku a má jiný nástroj:

• Doménová úroveň říká, jak je na tom celý web. Tahle data najdete v monitoringu PageSpeed.ONE a dalších nástrojích pracujících s CrUX.
• Úroveň skupin stránek ukazuje, které typy stránek táhnou web dolů. Tohle je doména reportu Core Web Vitals v Search Console.
• Konkrétní stránky řešíte, když potřebujete doladit jednu URL. K tomu slouží test rychlosti webu (Insights) nebo CrUX API.

Tři úrovně měření rychlosti webu. Search Console pokrývá hlavně prostřední úroveň, tedy skupiny stránek.

O každé úrovni a o tom, kde data získat, píšeme níže podrobněji.

Principy: komu se jaká data přiřadí#

Google nepřiřazuje rychlost všem stránkám stejně. Funguje to v krocích:

• Pokud má konkrétní stránka dost vlastní návštěvnosti, hodnotí se podle svých vlastních Core Web Vitals.
• Pokud stránka vlastní data nemá, Google ji zařadí do skupiny podobných stránek (to vidíte právě v Search Console), nebo použije hodnocení celé domény. Doménová hodnota přitom pokrývá většinu URL na webu, proto je tak zásadní.
• Pozor, že ani doména nemusí mít CrUX data. U nových nebo málo navštěvovaných webů Google prostě nemá dost měření.

Na tyto principy navazují další pravidla CrUX, která sem patří jen okrajově, ale je dobré o nich vědet: data běží ve 28denním kumulativním okně, takže se změny projevují se zpožděním, a u jednostránkových aplikací (SPA) se některé metriky měří jinak. Detaily najdete v článku o Chrome UX Reportu.

Reporty rychlosti v Google Search Console#

Teď to hlavní: kde reporty najít a jak je číst, abyste si z nich neodnesli špatný závěr.

Report Core Web Vitals#

Report najdete v levém menu Search Console v sekci Prostředí stránky (Experience), položka Core Web Vitals. Otevře se vám souhrn rozdělený na mobil a desktop. Vždy řešte obě části zvlášť, protože mobilní a desktopová zkušenost se obvykle liší.

Po rozkliknutí mobilu nebo desktopu se dostanete k jednotlivým skupinám stránek s popisem problému (například „LCP delší než 2,5 s“). Tady je největší nápověda, co optimalizovat. Google vám u každé skupiny nabídne i příklady konkrétních URL.

Pozor na matoucí graf Core Web Vitals#

Graf v reportu Core Web Vitals svádí k omylu. Laici si myslí, že ukazuje hodnotu metriky. Neukazuje. Ukazuje počet stránek v zeleném, oranžovém a červeném pásmu.

To má praktický důsledek. Posun stránek z oranžové do zelené může znamenat třeba zlepšení LCP z 2,51 s na 2,49 s, kdy se jen přehoupla hranice pásma, ale skutečná rychlost se prakticky nezměnila. A naopak velký skok v grafu nemusí znamenat velký skok ve vnímané rychlosti.

Report v Search Console ukazuje, kolik URL spadá do pásma „vyžaduje vylepšení“, ne průměrnou hodnotu metriky pro doménu.

Jak ho tedy číst správně? Sledujte podíl oranžových a červených stránek. Když je víc než 10 % URL oranžových nebo červených, určitě to řešte, ať zbytečně nepřicházíte o body u Googlu.

Report odezvy backendu#

Druhý důležitý report je schovaný a opět trochu matoucí. Najdete ho v Nastavení (Settings) v části Statistiky procházení (Crawl stats), kde Google reportuje průměrnou dobu odezvy serveru. Je to v podstatě TTFB, tedy čas, než server začne odpovídat. I když je report zastrčený, je velmi důležitý ze dvou důvodů.

Za prvé, odezva serveru má přímý vliv na metriky Core Web Vitals. Pomalý backend zdržuje načtení a podepíše se hlavně na LCP. Za druhé, ovlivňuje takzvaný Crawl Budget, tedy kolik stránek a jak často je Google ochotný procházet. Čím pomalejší server, tím méně Google stihne. Pojem i doporučení popisuje dokumentace Googlu ke Crawl Budgetu.

Jak dobu odezvy interpretovat?

• Pokud je dlouhodobě nad 0,8 s, určitě to řešte s infrastrukturou, vývojáři nebo experty.
• Pokud výkyvy k horším číslům korelují s návštěvností, posilte infrastrukturu, server vám nestíhá ve špičkách.
• Pokud výkyvy s návštěvností nesouvisí, může za nimi být provoz robotů. Stále častěji jsou to AI boti, na které máme Strategii pro AI boty.

Jak měřit rychlost s Google Search Console#

Search Console je skvělý dílek skládačky, ale sama o sobě nestačí. Pojďme si projít, co z ní vytěžit a čím ji doplnit.

Potřebujete doménová data#

Doménový pohled, tedy jak je na tom rychlost celého webu v čase, Search Console pořádně neumí. Tohle musíte mít jinde, v monitoringu. Klíčové jsou tři věci: alerty, dlouhodobé měření s historií dat a debugovací informace pro vývojáře.

V PageSpeed.ONE k tomu slouží report Domény s kompletními daty z CrUX. Uvidíte vývoj po dnech i po měsících a debugovací data, jako je rozpad LCP na jednotlivé části. K tomu zkušební verze zdarma, Hlídač, který vás sám upozorní na zhoršení, a další funkce. Tohle je přesně ta část, kterou Search Console nepokryje, a proto se bez samostatného monitoringu při serióznější práci na rychlosti neobejdete.

Pro jednorázová zjištění stavu pak stačí test rychlosti webu PageSpeed.ONE nebo PageSpeed Insights od Googlu. Hodí se na rychlou kontrolu, ne na sledování vývoje v čase.

Jednotlivá URL#

Konkrétní URL doporučujeme řešit jen u opravdu důležitých stránek, typicky homepage, nebo u webů, kde už máte doménová a skupinová data (viz níže) v pořádku. Nemá smysl ladit jednu stránku, dokud máte rozbité celé skupiny.

Potřebujete skupiny stránek#

Skupiny stránek jsou doménou Search Console, jinde je takhle hezky pohromadě nedostanete. Pracujte se dvěma reporty, které jsme popsali výše: s reportem Core Web Vitals a s reportem odezvy backendu. První vám řekne, které typy stránek jsou problémové, druhý odhalí pomalý server.

Opravili jste problém a v Google Search Console pořád straší?#

Search Console mívá zpoždění a není dokonale přesná, takže oprava se v ní neprojeví hned. Nepanikařte. Po opravě problémů můžete v reportu Core Web Vitals kliknout na tlačítko Start Tracking (Zahájit sledování). Spustí se 28denní monitorovací okno, které automaticky ověří, jestli oprava zabrala. Stavy URL přitom uvidíte jako Pending (čeká se), Passed (prošlo) nebo Failed (neprošlo).

Co znamená „No data available“#

Někdy v reportu narazíte na hlášku „No data available“ (žádná dostupná data). Znamená to jedno ze dvou: buď je property v Search Console nová a Google ještě nemá co ukázat, nebo má web málo návštěvnosti a nedostatek dat v CrUX. V obou případech doménový pohled doplníte synth měřením v monitoringu.

Praktické checklisty#

Na závěr dva seznamy, podle kterých se můžete řídit v praxi.

Co dělat pravidelně#

• Sledujte monitoring domén. Doménový pohled na rychlost vám dá nejrychlejší přehled o stavu celého webu. Ideálně z nástroje, který vás upozorní sám.
• Sledujte skupiny stránek v Search Console. Tady uvidíte, které typy stránek táhnou hodnocení dolů a kde začít s opravami.
• Hledejte vliv na SEO a PPC. Zlepšení nebo zhoršení rychlosti si dejte do souvislosti s daty z reportu Výkon (Performance) v Search Console. Uvidíte, jestli se to propisuje do pozic a prokliků.
• Zvolte správnou frekvenci. Malý web stačí kontrolovat jednou za měsíc, velký web klidně každý týden až každý den. Ideální stav je, když se nástroje hlásí samy: monitoring PageSpeed.ONE to dělá, do Search Console se musíte dívat ručně.

Co dělat, když je skupina v Core Web Vitals oranžová nebo červená#

• Berte to jako prioritu. Tohle jsou URL, které dostávají nižší hodnocení. Najděte konkrétní příklady stránek ve skupině, Search Console vám je nabídne.
• Měřte tyto URL v monitoringu. Dejte si je pod dohled, ať vidíte vývoj, ne jen jeden snímek.
• Dívejte se na debugovací data. Kombinujte synth měření a debugovací CrUX data, ať víte, co přesně metriku kazí.
• Otestujte stránku v prohlížeči. Jak na to, popisuje článek o Web Vitals v prohlížeči.
• Sáhněte po našich návodech. Podle problémové metriky mrkněte na optimalizaci LCP, INP nebo CLS. Pro rychlý start: u LCP řešte velikost a formát obrázků a odezvu serveru, u INP zbytečný JavaScript a kód třetích stran, u CLS vždy uvádějte rozměry obrázků a rezervujte místo pro pozdě načítané prvky.
• Nestíháte? Ozvěte se expertům. S optimalizací i s interpretací dat pomůžeme v rámci našich služeb.
• Po opravě dejte Start Tracking. V reportech Core Web Vitals spusťte sledování a nechte Google opravu ověřit.