Co v článku najdete
Barry Pollard, specialista na webový výkon a Developer Advocate pro Google Chrome, vysvětlil, jak najít skutečné příčiny špatného skóre LCP a jak je opravit.
Largest Contentful Paint (LCP)
LCP je metrika Core Web Vitals, která měří, jak dlouho trvá, než se ve viditelné části stránky (viewportu – tedy oblasti, kterou uživatel vidí v prohlížeči) zobrazí největší prvek obsahu. Tímto prvkem může být obrázek nebo text.
U LCP jsou největšími obsahovými prvky blokové HTML elementy, které zabírají největší prostor horizontálně, jako odstavce <p>, nadpisy (H1–H6) a obrázky <img> (v podstatě většina HTML prvků, které zabírají velkou šířku prostoru).
Vědět, na jaká data se díváte
Barry Pollard napsal, že běžnou chybou vydavatelů a SEO specialistů je, že po zjištění, že PageSpeed Insights (PSI) označuje stránku za špatné LCP skóre, začnou problém ladit v nástroji Lighthouse nebo v Chrome DevTools.
Pollard ale doporučuje zůstat u PSI, protože nabízí více vodítek pro pochopení problémů, které způsobují špatný výkon LCP.
Je důležité porozumět tomu, jaká data vám PSI poskytuje, zejména těm, která pocházejí z Chrome User Experience Reportu (CrUX), tedy z anonymizovaných výsledků skutečných uživatelů prohlížeče Chrome. Existují dva typy:
- Data na úrovni URL.
- Data na úrovni domény (Origin-Level Data).
Data na úrovni URL se vztahují ke konkrétní stránce, kterou ladíte. Data na úrovni domény jsou souhrnná skóre celého webu.
PSI zobrazí data na úrovni URL, pokud má konkrétní stránka dostatek naměřené návštěvnosti. V opačném případě zobrazí data na úrovni domény (souhrnná data za celý web).
Zkontrolujte skóre TTFB
Pollard doporučuje podívat se na skóre TTFB (Time to First Byte), protože, jak říká, „TTFB je první věc, která se na stránce stane“.
Byte je nejmenší jednotka digitálních dat pro reprezentaci textu, čísel nebo multimédií. TTFB ukazuje, kolik času trvá, než server odpoví prvním bytem dat – což odhalí, zda je pomalá odezva serveru příčinou špatného výkonu LCP.
Říká, že soustředění se pouze na optimalizaci webové stránky nikdy nevyřeší problém, který má svůj základ ve špatném skóre TTFB.
Barry Pollard píše:
„Pomalé TTFB v podstatě znamená jednu ze dvou věcí:
1) Odeslat požadavek na váš server trvá příliš dlouho.
2) Vašemu serveru příliš dlouho trvá, než odpoví.
Ale zjistit, která možnost to je (a proč!), může být složité – a pro každou z těchto kategorií existuje několik možných příčin.“
Pollard pokračoval svým přehledem ladění LCP s konkrétními testy, které jsou uvedeny níže.
Porovnejte TTFB s laboratorním testem Lighthouse
Pollard doporučuje otestovat stránku pomocí laboratorních testů Lighthouse, konkrétně auditu „Initial server response time“. Cílem je ověřit, zda je problém s TTFB opakovatelný, a tím vyloučit možnost, že hodnoty z PSI jsou rychlejší, než jaké ve skutečnosti vidí většina uživatelů.
Laboratorní výsledky jsou syntetické, tedy nejsou založené na skutečných návštěvách uživatelů. „Syntetické“ znamená, že jsou simulované algoritmem na základě návštěvy vyvolané testem Lighthouse.
Syntetické testy jsou užitečné, protože jsou opakovatelné a umožňují izolovat konkrétní příčinu problému.
Pokud laboratorní test Lighthouse problém nezopakuje, znamená to, že test neodhalil stejné problémy s TTFB, jaké zaznamenali skuteční uživatelé.
Poradil:
„Klíčové je ověřit, zda je pomalé TTFB opakovatelné. Projděte stránku a zkontrolujte, zda laboratorní test Lighthouse odpovídal pomalému TTFB skutečných uživatelů při testování stránky. Hledejte audit ‘Initial server response time’.
V tomto případě byl mnohem rychlejší – to je zajímavé!“
Tip od odborníka: Jak zkontrolovat, zda CDN skrývá problém
Pollard poskytl skvělý tip ohledně Content Delivery Networks (CDN), jako je Cloudflare. CDN uchovává kopii webové stránky ve svých datových centrech, což zrychluje doručení stránek, ale zároveň může zakrýt případné problémy na úrovni serveru.
CDN neuchovává kopii stránky ve všech datových centrech po celém světě. Když uživatel požaduje webovou stránku, CDN ji nejprve načte ze serveru a poté vytvoří kopii v datovém centru, které je uživateli nejblíže. První načtení je tedy vždy pomalejší, a pokud je server již zpočátku pomalý, toto první načtení bude ještě pomalejší než doručení stránky přímo ze serveru.
Pollard navrhuje následující triky, jak obejít cache CDN:
- Otestujte pomalou stránku přidáním parametru do URL (například přidáním ?XYZ na konec adresy).
- Otestujte stránku, která není často zobrazována.
Dále doporučuje nástroj, který umožňuje testovat konkrétní země:
„Můžete také zkontrolovat, zda jsou pomalé především určité země – zejména pokud nepoužíváte CDN.“
Pokud mají určité země pomalé TTFB, zkontrolujte, kolik návštěvnosti pochází z těchto zemí. Z důvodů ochrany soukromí CrUX nezobrazuje objemy návštěvnosti (kromě případů, kdy je návštěvnost dostatečná k zobrazení), takže pro tyto údaje budete muset nahlédnout do své analytiky.
Pokud jde o pomalé připojení z konkrétních geografických oblastí, je užitečné vědět, že pomalý výkon v některých rozvojových zemích může být způsoben populárností levných mobilních zařízení. A stojí za opakování, že CrUX přesně neukazuje, kolik návštěvnosti s nízkými skóre pochází z jednotlivých zemí. Navíc většina nástrojů ani tato omezená data o zemích z CrUX nezobrazuje.
Poradil:
„V případě problémů se serverem – je server poddimenzovaný?
Nebo je kód příliš složitý/inefektivní?
Nebo je potřeba ladění databáze?
U pomalých připojení z některých míst – potřebujete CDN?
Nebo zjistíte, proč odtud přichází tolik návštěvnosti (reklamní kampaň)?
Pokud nic z toho nevypadá jako hlavní příčina, může být problém v přesměrováních, zejména z reklam. Ta mohou přidat ~0,5 s k TTFB – na každé přesměrování!
Snažte se přesměrování minimalizovat co nejvíce:
– Používejte správnou finální URL, abyste se vyhnuli přesměrování na www nebo https.“
Barry Pollard z Google Chrome nabídl pět důležitých tipů:
- Data z PageSpeed Insights (PSI) mohou poskytnout vodítka pro ladění problémů s LCP, stejně jako další rozdíly diskutované v tomto článku, které pomáhají lépe porozumět datům.
- Data TTFB (Time to First Byte) z PSI mohou naznačit, proč má stránka špatné skóre LCP.
- Laboratorní testy Lighthouse jsou užitečné pro ladění, protože výsledky jsou opakovatelné. Opakovatelné výsledky jsou klíčové pro přesné určení zdroje problémů s LCP, což pak umožňuje aplikovat správná řešení.
- CDN mohou skrývat skutečnou příčinu problémů s LCP. Použijte Pollardův trik popsaný výše, abyste obešli CDN a získali skutečné laboratorní skóre, které může být užitečné pro ladění.
Pollard uvedl také šest možných příčin špatného skóre LCP:
- Výkon serveru.
- Přesměrování.
- Kód.
- Databáze.
- Pomalá připojení specifická pro určité geografické oblasti.
- Pomalá připojení z konkrétních míst způsobená specifickými důvody, například reklamními kampaněmi.
Zdroj: searchengineland.com, searchenginejournal.com, marketingland.com, facebook.com, cpcstrategy.com
Autor: Martina LeVeneur
Foto zdroj: AI, pixabay.com
