Kontrolní seznam pro nápravu Core Web Vitals

Kontrolní seznam: Náprava Core Web Vitals. Časový rámec: jeden pracovní den na potvrzení rozsahu a diagnózy; jeden až deset pracovních dnů na typickou opravu a vydání, v závislosti na tom, zda příčina spočívá v aktivu, sdílené šabloně, skriptu třetí strany, doméně nebo CDN. Ověření v terénu následuje po klouzavém 28denním datovém okně a je plánováno samostatně. Vlastník: odpovídá výkonnostní inženýr nebo senior front-end inženýr. Technický SEO lead vlastní kritéria přijetí z terénu; vlastníci platformy, designu, analytiky a produktu schvalují změny ve svých systémech.

Tento kontrolní seznam přemění diagnostikovaný výkonnostní nález na vydanou a v terénu ověřenou opravu. Core Web Vitals jsou metriky společnosti Google měřící načítání, odezvu a vizuální stabilitu u reálných uživatelů: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) a Cumulative Layout Shift (CLS). Time to First Byte (TTFB) a First Contentful Paint (FCP) jsou podpůrné diagnostické metriky. Jsou zahrnuty, protože pomalá odezva nebo prázdná obrazovka spotřebovává čas dostupný pro dosažení dobrého LCP.

Proč tento kontrolní seznam a proč právě zde

Tento kontrolní seznam zpracovává registr náprav z auditu výkonu a Core Web Vitals . Tato dřívější fáze identifikuje selhávající metriku, postiženou URL a šablonu, výchozí stav u reálných uživatelů, opakovatelný laboratorní stav, podezřelou příčinu, prioritu a vlastníka. Náprava začíná až poté, co tato pole existují. Jinak je vývojář požádán, aby „zrychlil web" a přirozeně změní to, co nástroj zvýrazní jako první, bez ohledu na to, zda to způsobuje selhání v terénu.

Diagnóza musí před akcí zúžit tři úrovně: která metrika, která šablona a který prvek nebo úloha. Selhání TTFB v celé doméně vyžaduje opravu platformy; LCP, které selhává pouze na článcích, může pocházet z jejich hero komponenty; INP po otevření produktového filtru může pocházet z jedné obsluhy události; CLS na promočních stránkách může pocházet z nevyhrazeného banneru. Řešení těchto problémů jako jednoho vede k rozsáhlým změnám a nejasnému vlastnictví.

Pořadí záleží uvnitř opravy. TTFB je nadřazené: dokud nepřijde první byte odpovědi, prohlížeč nemůže objevit běžné HTML zdroje ani vykreslit obsah stránky. Pokud je TTFB špatný, opravte generování odpovědi, caching, přesměrování a doručení na okraji sítě před kompresí LCP obrázku. Poté, co je doba odezvy v rámci rozpočtu, postupujte dále přes objevení zdrojů, stažení zdrojů, vykreslování, interakce a stabilitu rozvržení.

Přeskočení tohoto kontrolního seznamu zanechá audit jen jako zprávu. Jeho použití před diagnózou vede k honbě za příznaky: komprese obrázku, když dominuje pozdní objevení, nebo odložení skriptů, když je pomalá doména.

Vstupy a výstupy

Výstupy umožňují budoucímu vlastníkovi reprodukovat selhání, identifikovat, co bylo nasazeno, a rozlišit laboratorní přijetí od terénního potvrzení.

Kontrolní seznam

Dokončete položky 1–4 před změnou produkčního prostředí. Položky 5–8 implementují opravu seřazenou podle závislostí. Položky 9–11 oddělují okamžité přijetí vydání od ověření v terénu.

1. Uzamkněte selhávající metriku, šablonu a prvek

Co: zredukujte nález na jednu metriku, dotčenou sadu šablon a pojmenovaný prvek, požadavek, úlohu nebo serverový úsek. Proč: celostránkové skóre neidentifikuje nasaditelnou práci a dvě URL mohou selhávat z různých důvodů. Jak: spojte selhání p75 s trasováním a porovnejte postižené a nepostižené šablony; pojmenujte LCP element a zpoždění, INP interakci a úlohu, CLS element a spouštěč nebo cestu požadavku TTFB a stav cache. Nástroj: CrUX důkazy, trasování prohlížeče, waterfall, serverové timingy, inventář šablon a sledovač úkolů. Hotovo, když: důkazy podporují tvrzení „metrika X selhává na šabloně Y, protože Z vytváří zpoždění nebo pohyb za podmínky C."

2. Potvrďte rozsah pomocí reprezentativních stránek

Co: otestujte nález na typické a nejhorší URL pro každou zahrnutou šablonu a na jedné nepostižené kontrole. Proč: oprava jedné stránky může skrýt sdílenou chybu, zatímco globální změna může být zbytečná, pokud problém způsobuje jedna varianta obsahu. Jak: udržujte zařízení, síť, lokalitu, souhlas, přihlášení a stav cache konstantní; porovnejte použití komponent, váhu aktiv, časování odezvy, aktivitu třetích stran a délku obsahu. Nástroj: analytika, inventář šablon, nástroje pro výkon prohlížeče, monitor požadavků a testovací matice. Hotovo, když: každá šablona v rozsahu je označena jako postižená nebo kontrolní, každá má reprodukovatelný důkaz a rozsah vydání pojmenovává komponentu, cestu, rodinu aktiv nebo vrstvu platformy, která se musí změnit.

3. Nastavte rozpočet a chraňte požadované chování

Co: definujte číselný cíl, ochranná pravidla proti regresi a funkce, které musí přežít. Proč: „rychleji" nemá hranici přijetí a smazání správce souhlasu, analytické značky, chování přístupnosti pro fokus nebo produktové funkce může vytvořit klamavé splnění. Jak: nastavte cíl podle rozhodovací tabulky níže, přidejte přísnější interní rezervu tam, kde se opakované testy liší, a uveďte kritické cesty a necílové metriky k opětovnému testování. Nástroj: registr nálezů, produktové požadavky, plán analytiky, kontroly přístupnosti a rozpočet výkonu. Hotovo, když: ticket uvádí cílovou metriku a hodnotu, metodu laboratorního přijetí, metodu terénního přijetí, chráněná chování, povolené kompromisy, podmínku vrácení změn a jmenované schvalovatele.

4. Zkontrolujte TTFB před front-end prací

Co: změřte TTFB při studené a teplé cache z lokalit relevantních pro publikum. Proč: TTFB je zahrnuto do každého následujícího času vykreslení; front-end práce nemůže získat zpět čas již spotřebovaný čekáním na HTML. Jak: rozdělte požadavek na DNS, připojení, přesměrování, čekání na CDN, výpočet na doméně, čas databáze nebo API třetí strany a chování streamování tam, kde to instrumentace umožňuje. Porovnejte odpovědi při zásahu a minutí cache a potvrďte, že personalizace nebo cookies neočekávaně nevypínají caching. Nástroj: waterfall požadavku, serverové timingy, CDN a doménové logy, profilování aplikace a syntetické monitorování požadavků. Hotovo, když: TTFB je v rámci dohodnutého rozpočtu nebo je samostatný blokující nález na platformě vlastněn a naplánován. Nezačínejte s laděním LCP, dokud není špatné TTFB vysvětleno.

5. Nejprve odstraňte zpoždění serveru a doručení

Co: opravte pomalou odezvu domény, minutí cache, přesměrování nebo vzdálené doručení. Proč: tyto příčiny zpožďují každý prvek a často ovlivňují více šablon. Jak: odstraňte zbytečná přesměrování; cacheujte bezpečné HTML a data; snižte pomalou databázovou nebo API práci; přesuňte práci mimo kritickou cestu; vylaďte CDN směrování a cache klíče. Nikdy necacheujte soukromé odpovědi bez schváleného návrhu. Nástroj: profiler aplikace, trasování dotazů, konfigurace CDN, hlavičky odpovědí, monitoring a zátěžové testování. Hotovo, když: opakované testy se studenou a teplou cache splňují rozpočet, varianty cache zůstávají správné, chyby neregredovaly a prioritní URL vracejí zamýšlenou odpověď bez dalšího skoku.

6. Opravte zpoždění objevení, přenosu a vykreslení LCP

Co: zkraťte Largest Contentful Paint , když se vykreslí největší viditelný obrázek nebo textový blok. Proč: příliš velké hero prvky jsou běžné, ale dominovat může pozdní objevení, nízká priorita, blokující CSS, JavaScript nebo fonty. Jak: doručte správně veliký responzivní obrázek; nelazy-loaderujte LCP aktivum nad záhybem; vystavte jej v počátečním HTML; priorizujte nebo přednačítejte pouze s důkazy; odstraňte blokování vykreslení; používejte podmnožinové, cacheovatelné fonty s vhodnou fallback variantou. Nástroj: rozklad LCP, waterfall, kontrola obrázků, report pokrytí, trasování a vizuální porovnání. Hotovo, když: zamýšlený LCP element je konzistentní, jeho dominantní zpoždění kleslo, reprezentativní stránky splňují rozpočet a šířka pásma, viditelnost textu a vykreslení neregredovaly.

7. Opravte INP u odpovědné interakce

Co: snižte interakci zodpovědnou za špatné Interaction to Next Paint , metriku odezvy. Proč: mazání libovolného JavaScriptu se nemusí dotknout pomalé události. Jak: oddělte zpoždění vstupu, zpracování a prezentace; rozdělte dlouhé úlohy; odstraňte synchronní práci; odložte nepodstatné třetí strany; vyhněte se opakovanému rozvržení; snižte překreslování; a uvolněte pro vykreslení. Testujte na realistickém hardwaru s produkčními třetími stranami. Nástroj: trasování interakce, profil hlavního vlákna, záznamy dlouhých úloh, profiler frameworku a realistické zařízení. Hotovo, když: kritické interakce fungují, odpovědná úloha splňuje rozpočet opakovaného testu, terénní proxy je zdokumentován a chování analytiky, souhlasu, klávesnice a screen-readeru neregredovalo.

8. Opravte CLS rezervací konečného rozvržení

Co: zabraňte pohybu přispívajícímu k Cumulative Layout Shift , skóre vizuální nestability. Proč: obrázky, fonty, reklamy, bannery, vložené prvky a asynchronní komponenty mohou všechny posouvat rozhraní. Jak: nastavte intrinsické rozměry nebo aspect-ratio; vyhraďte sloty pro dynamické moduly; používejte kompatibilní fallbacky fontů; a animujte pomocí transformací. Nástroj: oblasti posunu rozvržení, trasování, filmstrip, vizuální regresní testy a throttlovaný prohlížeč. Hotovo, když: každý materiální shluk posunu má pojmenovaný zdroj, stránky splňují rozpočet CLS během načítání a kritických interakcí a vyhrazené místo nezakrývá žádný ovládací prvek.

9. Znovu otestujte celou sadu metrik a chráněné cesty

Co: porovnejte kandidáta na vydání se zmrazeným výchozím stavem za identických podmínek, poté testujte v produkci. Proč: zlepšení jedné metriky může poškodit jinou: odložení JavaScriptu může zlepšit LCP, ale zhoršit první interakci, zatímco agresivní změna fontu může zlepšit časování vykreslení, ale vytvořit posun rozvržení. Jak: spusťte několik kontrolovaných vzorků, porovnejte deklarovanou statistiku namísto nejlepšího běhu, prohlédněte trasování, otestujte chráněné cesty, ověřte správnost odpovědí a testujte postižené i kontrolní šablony. Nástroj: Lighthouse nebo ekvivalentní laboratorní nástroj, nástroje pro výkon prohlížeče, monitor požadavků, vizuální a funkční testy a kontrolní seznam vydání. Hotovo, když: cílová metrika splňuje svůj laboratorní rozpočet napříč deklarovanou metodou opakovaných běhů, TTFB/FCP/LCP/INP/CLS nevykazují kritickou regresi, chráněné chování prochází, produkce doručuje zamýšlenou změnu a vrácení změn není spuštěno.

10. Označte vydání a naplánujte terénní kontrolu

Co: zaznamenejte časové razítko nasazení, změněný rozsah, cílovou metriku, očekávaný směr a data terénní kontroly. Proč: CrUX používá klouzavé 28denní okno, takže zkušenosti z doby před vydáním zůstávají v hlášeném p75 i po nasazení. Bez anotace může tým považovat dobrou opravu za neúčinnou příliš brzy nebo pozdější pohyb připsat špatnému vydání. Jak: připojte produkční verzi k nálezu, okamžitě zkontrolujte chyby, zaznamenejte předběžné terénní hodnoty, aniž byste je považovali za konečné, a naplánujte vlastníka, aby zkontroloval dostatečně obnovené okno. Nástroj: log nasazení, sledovač úkolů, CrUX, AmICited Web Vitals a monitoring. Hotovo, když: ticket je označen jako Laboratorně přijato, anotace vydání a okamžité důkazy jsou připojeny a existuje jmenovaný vlastník a kalendářní datum pro terénní ověření.

11. Ověřte pomocí terénních dat a uzavřete nebo znovu otevřete

Co: porovnejte srovnatelná terénní data p75 poté, co se klouzavé okno dostatečně obnovilo. Proč: zařízení reálných uživatelů, sítě, geografie, chování cache, stavy souhlasu a interakce nelze reprezentovat jedním laboratorním během. Jak: použijte stejnou úroveň CrUX – URL nebo doménu – stejnou metriku a srovnatelný rozsah publika; zohledněte částečné nasazení a další vydání; kontrolujte zástupce šablon namísto spoléhání se pouze na agregát domény. Pokud výsledek chybí, porovnejte aktuální trasování s původním prohlášením o příčině a znovu otevřete diagnózu namísto hromadění nesouvisejících úprav. Nástroj: AmICited Web Vitals, historie CrUX, anotace vydání, segmenty analytiky a balíček důkazů. Hotovo, když: cíl splňuje dohodnutý práh p75 a rozsah se zaznamenanými omezeními, v tom okamžiku se status mění na Ověřeno v terénu; nebo je ticket explicitně znovu otevřen s novými důkazy, vlastníkem a další hypotézou.

Nástroje v AmICited

Otevřete AmICited Web Vitals pro zobrazení LCP, INP, CLS, FCP a TTFB z CrUX pro vaši doménu a sledované konkurenty. Použijte jej při diagnóze k zachycení terénního výchozího stavu a po nasazení k ověření klouzavého terénního výsledku. Prázdná hodnota znamená nedostatečná způsobilá terénní data, ne nulu a ne splnění. Produktový pohled podporuje verdikt; trasování, serverové timingy a profily prohlížeče stále identifikují příčinu.

Použijte Performance Impact k propojení důkazů o výkonu na úrovni stránky s pozicí citace a identifikaci cenných pomalých stránek. Tato asociace pomáhá priorizovat nápravu, ale nedokazuje, že výkon sám o sobě způsobil výsledek citace. Při interpretaci pohybu zohledněte relevantnost, obsah, autoritu a kontext vydání.

Pro produktový postup postupujte podle Jak zkontrolovat své Core Web Vitals v AmICited . Návod vysvětluje, kde se metriky zobrazují a jak funguje srovnání s konkurenty; tento kontrolní seznam řídí diagnózu, implementaci a přijetí.

Rozhodovací pravidla: jak vypadá špatný stav

Pro terénní rozhodnutí používejte 75. percentil, zkráceně p75: 75 % způsobilých zaznamenaných zkušeností je na této hodnotě nebo pod ní. Hraniční hodnota patří do lepšího pásma. LCP, INP a CLS určují status Core Web Vitals; TTFB a FCP jsou podpůrná měření používaná k seřazení a diagnostice práce.

Aplikujte tato pravidla v tomto pořadí:

1. Timeout, serverová chyba, nesprávná odpověď nebo přerušená kritická cesta blokují vydání bez ohledu na skóre metriky.
2. Špatné TTFB je nadřazeno LCP a je řešeno jako první. Netvrďte řešení pouze pomocí obrázků, zatímco server již spotřeboval většinu rozpočtu vykreslení.
3. Špatné terénní metriky mají přednost před metrikami vyžadujícími zlepšení. V rámci jednoho pásma priorizujte sdílené příčiny v šablonách, návštěvnost a obchodně kritické cesty.
4. Prázdná terénní hodnota na úrovni URL je neznámá. Použijte laboratorní důkazy a zdokumentovaný proxy, ale nepřejmenovávejte neznámé na dobré.
5. Jeden úspěšný laboratorní běh nestačí. Deklarujte profil zařízení/sítě a metodu opakovaných běhů před testováním.
6. Oprava je Laboratorně přijata, když nasazené chování a kontrolované testy procházejí. Je Ověřena v terénu až poté, co srovnatelná klouzavá terénní data splní dohodnutý práh.
7. Pokud data domény procházejí, ale vysoce navštěvovaná šablona selhává, výsledek šablony vyhrává pro daný rozsah. Agregace nesmí vymazat koncentrovaný problém uživatelů.

Výstup: balíček nápravy a ověření

Předejte jeden ticket nebo záznam v registru na jednu kořenovou příčinu, s dílčími rozsahy tam, kde příčina ovlivňuje několik šablon. Použijte tabulku, sledovač úkolů nebo inženýrský dokument, ale zachovejte tato pole:

ID nálezu a primární metrika:
Terénní zdroj: URL | Doména
Terénní p75, pásmo a 28denní okno:
Postižené šablony a reprezentativní URL:
Kontrolní šablona a URL:
Prvek, interakce, požadavek nebo serverový úsek:
Prohlášení o příčině a odkazy na důkazy:
Laboratorní profil a výchozí hodnota opakovaných běhů:
Cíl, ochranná pravidla a chráněné cesty:
Zvolená náprava a zamítnuté alternativy:
Inženýrský vlastník, schvalovatelé a závislosti:
ID vydání/verze a časové razítko nasazení:
Okamžité produkční a laboratorní výsledky:
Vlastník a datum terénní kontroly CrUX:
Srovnatelný terénní výsledek a omezení:
Práh monitoringu a pravidlo pro znovuotevření:
Status: Otevřeno | Implementuje se | Laboratorně přijato | Ověřeno v terénu | Znovu otevřeno | Akceptované riziko

Připojte trasování, waterfall, serverové úseky, nahrávky posunů, profily interakcí, výstupy testů a anotaci vydání. Akceptované riziko vyžaduje rozsah, důvod, schvalovatele, expiraci a spouštěč monitoringu; není to splnění.

Balíček je přijat, když jiný inženýr může reprodukovat původní problém, identifikovat, proč tato změna jej řeší, potvrdit, co se dostalo do produkce, a zopakovat terénní srovnání, aniž by se musel ptát původního vyšetřovatele na rekonstrukci práce.

Co se pokazí

Optimalizace před izolací příčiny. Generická komprese a mazání skriptů nahrazují diagnózu. Vyžadujte nejprve důkazy o metrikě-šabloně-prvku.

Komprese hero prvku, zatímco doména je pomalá. Menší obrázek se nemůže vykreslit dříve, než dorazí HTML. Změřte a řešte TTFB jako první, když je mimo rozpočet.

Oprava špatného posunu. CLS může pocházet z reklamy, banneru souhlasu, fontu, vloženého prvku nebo hydratované komponenty. Pojmenujte zdroj posunu.

Odkládání každého skriptu. Bez rozdílné odkládání může narušit pořadí souhlasů, analytiku, navigaci, formuláře nebo první interakci. Změňte odpovědnou cestu vykonání a otestujte regresi požadovaného chování.

Ověření jedné URL po vydání sdílené šablony. Vybraný příklad může projít, zatímco těžší varianta obsahu nebo jiná konfigurace komponenty stále selhává. Testujte typické, těžké a kontrolní stránky.

Čtení dat na úrovni domény jako splnění šablony. Zdravé stránky s vysokou návštěvností mohou maskovat slabou kategorii, článek nebo produktovou šablonu. Udržujte diagnózu a přijetí na nejužším spolehlivém rozsahu.

Uzavření v den nasazení. Okamžité testy stanovují laboratorní přijetí. Nenahrazují klouzavé terénní datové okno.

Čekání 28 dní na objevení rozbitého vydání. Terénní potvrzení vyžaduje čas, ale stavové kódy, chyby, cesty, vizuální stabilita a kontrolované metriky se kontrolují okamžitě. Klouzavá data nejsou výmluva pro přeskočení QA vydání.

Další fáze: průběžný monitoring a iterace

Předejte záznam o ověření v terénu, anotaci vydání, postižené šablony, omezení a prahy do průběžné obnovy a iterace . Ta potřebuje stabilní výchozí stav, aby pozdější změny obsahu, médií, šablon, kampaní a třetích stran mohly být porovnány, nikoli znovu objevovány jako nevysvětlený pohyb.

Další vlastník zaznamenává, kdo sleduje který práh, kde důkazy žijí, jak často jsou kontrolovány a co znovu otevírá nápravu. Nově špatná metrika, opakovaný trend vyžadující zlepšení v plně obnoveném okně, změněný LCP element, nová pomalá interakce nebo vydání šablony, které mění diagnostikovanou cestu, by měly znovu otevřít kontrolní seznam u položky 1. Neopakujte automaticky předchozí opravu: stejná metrika může selhávat kvůli jinému prvku po redesignu.

Předání je dokončeno, když je terénní status explicitní, každé přijaté omezení má vlastníka a datum kontroly a monitoring může propojit regresi se šablonou a vydáním. Pokud terénní ověření stále čeká, další vlastník obdrží naplánované datum kontroly a ticket zůstává ve stavu Laboratorně přijato, nikoli uzavřen.

FAQ

FAQ k nápravě Core Web Vitals