Pokud po zobrazení zeleného skóre rychlosti hledáte odpověď na dotaz „hodnocení Core Web Vitals nevyhovuje“, nejprve ověřte, jaká data jednotlivé výsledky popisují. PageSpeed Insights (PSI) kombinuje podklady ze skutečných návštěv se samostatným testem v řízených podmínkách. Než koupíte nástroj nebo požádáte o přestavbu webu, zaznamenejte adresu, zařízení, rozsah dat a metriku, která nesplnila požadavky.
Začínáme tímto záznamem, protože zadání „dostat skóre do zelené“ ponechává příliš mnoho nejasností. Vývojář potřebuje vědět, kterou část uživatelské zkušenosti je třeba zlepšit a jaké důkazy doloží užitečnou opravu.
Hodnocení Core Web Vitals nevyhovuje: co zpráva měřila?
Hodnocení popisuje zaznamenané zkušenosti návštěvníků, zatímco část Lighthouse provádí diagnostický test. Dokumentace Google k PageSpeed Insights vysvětluje, že data z reálného provozu pocházejí z Chrome User Experience Report neboli CrUX a pokrývají klouzavé období posledních 28 dnů. Nový diagnostický test a tato historie proto mohou ukazovat rozdílné výsledky.
Podmínky testu se liší. Jeden řízený test nemůže pokrýt všechna zařízení, připojení a úkony při skutečných návštěvách. Použijte jej ke zkoumání možné příčiny. Při rozhodování o tom, co zůstává nevyřešené, mějte vedle něj také data návštěvníků.
Výsledek může zahrnovat širší celek. Pokud pro konkrétní stránku není dost dat, PSI může použít údaje pro origin, tedy společný základ webových adres určený protokolem a názvem hostitele. Výsledek pro origin slučuje návštěvy napříč stránkami. Než jej považujete za důkaz o konkrétní produktové stránce či stránce služby, přečtěte si uvedený rozsah.
Období zahrnuje starší návštěvy. Dnešní změna nepřepisuje včerejší pozorování. Uložte datum nasazení, abyste mohli odlišit okamžitou kontrolu opravy od pozdějších podkladů o návštěvnících.
Toto rozlišení dává zprávám odlišné úlohy: data návštěvníků ukazují zkušenost, kterou je třeba prozkoumat; řízený test ji pomáhá zopakovat a posoudit.
Která metrika vyžaduje pozornost?
Před výběrem opravy posuďte LCP, INP a CLS jednotlivě. Doporučení Google k Web Vitals rozlišují načítání, odezvu a vizuální stabilitu. Následující tabulka uvádí hranice kategorie Dobré podle těchto doporučení, vyhodnocované na 75. percentilu pro příslušnou skupinu zařízení. Průvodce Google k prahovým hodnotám vysvětluje 75. percentil takto: alespoň 75 % měřených zobrazení stránky musí pro danou metriku splnit hranici kategorie Dobré. To se liší od průměru i celkového skóre Lighthouse.
| Metrika | Co popisuje | Hranice kategorie Dobré | Na co se zeptat správce webu |
|---|---|---|---|
| LCP, Largest Contentful Paint | Kdy se objeví největší viditelný prvek obsahu | Nejvýše 2,5 sekundy | Který prvek se zpožďuje a v jaké fázi načítání? |
| INP, Interaction to Next Paint | Jak pohotově stránka reaguje na interakce | Nejvýše 200 milisekund | Které klepnutí, kliknutí nebo stisk klávesy je za dotčených podmínek pomalý? |
| CLS, Cumulative Layout Shift | Neočekávané posuny rozložení stránky | Nejvýše 0,1 | Který prvek se pohybuje a v jakém okamžiku návštěvy? |
Pokud mají všechny tyto metriky dostatek dat, PSI pro vyhovující hodnocení vyžaduje, aby jejich hodnoty na 75. percentilu patřily do kategorie Dobré. Při nedostatku dat INP mohou dobré hodnoty LCP a CLS přesto vést k vyhovujícímu hodnocení. Pokud není dostatek dat LCP nebo CLS, PSI nemůže stránku ani origin vyhodnotit.
Chybějící data berte jako nejistotu. Metodika CrUX od Google vyžaduje návštěvy splňující podmínky měření a dostatečnou popularitu; nezveřejňuje univerzální minimální počet návštěvníků. Chybějící výsledek neříká, že na web nikdo nechodí, že je uživatelská zkušenost dobrá ani že oprava selhala.
Co můžete ověřit, než za práci zaplatíte?
Před výběrem nástroje uložte výchozí zprávu a na telefonu projděte stejnou cestu jako zákazník. Potřebujete jasný popis problému: stránku, data za upozorněním a chování, které dokážete zopakovat. Pokud jej nezopakujete, zaznamenejte toto omezení místo vyplnění mezery domněnkou.
- Otevřete v PSI konkrétní obchodně důležitou stránku. Uchovejte její adresu a datum zprávy. Zahrňte vstupní stránku nebo šablonu důležitou pro poptávku či nákup, který zkoumáte.
- Zaznamenejte mobil nebo počítač a rozsah dat. Opište, zda část s daty z reálného provozu představuje URL, origin, nebo nedostatek dat. Stejný výběr použijte při pozdějším porovnání.
- Pojmenujte metriku vyžadující pozornost. Vycházejte z jednotlivých výsledků Core Web Vitals, poté hledejte vodítka v diagnostické části. Chybějící vzorky ponechte výslovně uvedené.
- Proveďte na telefonu skutečný úkol. Otevřete menu, použijte příslušný filtr nebo vyplňte relevantní formulář. Zapište, co se načítá pozdě, reaguje pomalu nebo se nečekaně posouvá.
- Propojte vodítko s testem. Požádejte správce webu, aby zopakoval dotčenou činnost či zpoždění načítání a vysvětlil, co test dokáže zjistit.
Širší kontrolu obrázků, widgetů, mezipaměti a hostingu popisuje náš průvodce běžnými příčinami pomalého webu. Aktuální úkol soustřeďte na nevyhovující hodnocení a podklady potřebné k posouzení opravy.
Co by měla oprava zahrnovat?
Vyberte nejmenší změnu podloženou diagnózou a dohodněte, jak ji ověříte. Začněte se zprávami a funkcemi, které už máte. Technickou práci lze snáze posoudit, když správce uvede dotčenou stránku či šablonu, vysvětlí úzké místo a zachová srovnatelné podmínky před změnou i po ní.
- Přiřaďte návrh k metrice. Průvodce LCP na web.dev rozlišuje zpoždění odpovědi, nalezení zdroje, načítání a vykreslení největšího prvku. Průvodce INP zaměřuje šetření na pomalé interakce. Průvodce CLS zahrnuje posuny po počátečním načtení. Žádejte relevantní podklady místo obecného slibu, že se web zrychlí.
- Opravte zjištěnou příčinu a znovu otestujte chování. Cílená oprava zdroje nebo šablony může být součástí vývoje a údržby webu. Zaznamenejte, co a kdy se změnilo, a tam, kde je to možné, uveďte způsob návratu k předchozímu stavu.
- Ověřte, že zákaznický úkol stále funguje. Otestujte navigaci, formuláře a nákupní kroky relevantní pro stránku. Zachovejte funkční ovládání souhlasu; zkoumejte jeho chování a rozložení při zachování právně platného souhlasu.
- Rozhodněte, zda potřebujete další podklady. Pokud dostupné zprávy nedokážou určit dotčenou interakci nebo stránku, může pomoci další měření. Před přidáním placené služby se zeptejte, na jakou otázku navržené sledování odpoví.
Pokud technická priorita není jasná, technické SEO může začít diagnózou a seznamem prací, který lze posoudit. Redesign nebo optimalizační balíček vyžaduje vlastní zdůvodnění.
Můžete zkopírovat tuto kartu úkolu a neznámá pole ponechat prázdná:
Stránka a obchodní úkol:
Zařízení a rozsah dat z reálného provozu:
Metrika vyžadující pozornost:
Pozorované chování a podmínky testu:
Navržená příčina a změna:
Datum nasazení:
Srovnatelná kontrola po změně:
Pozdější pozorování z reálného provozu a přetrvávající nejistota:Jak ověříte, že práce pomohla?
Nejprve posuďte změněné chování a poté porovnejte pozdější data z reálného provozu ve stejném rozsahu. Podle své dokumentace PSI aktualizuje tato data denně a přitom zachovává klouzavé období sběru. Datum nasazení ponechte u záznamu. Toto období není slíbeným odpočtem do vyhovujícího hodnocení.
Porovnejte cílovou metriku a zákaznický úkol za podobných testovacích podmínek. Pokud příznak přetrvává, vraťte se k diagnóze. Jestliže se test zlepší, ale pozdější data z provozu změnu nepotvrdí, znovu prozkoumejte dotčené stránky a podmínky návštěvníků. Chybějící data z provozu musí zůstat výslovně uvedeným omezením.
Jak pomáháme my
Začínáme zprávou, důležitými stránkami a úkolem, který dokážeme zopakovat. Oddělujeme navrženou opravu, její ověření a pozdější podklady od návštěvníků, aby každé rozhodnutí mělo základ, který můžete posoudit. Zadání pro zlepšení výkonu webu může začít výše uvedenou kartou úkolu; neznámá pole ponechte viditelná.
