Kontrolný zoznam nápravy Core Web Vitals

Kontrolný zoznam: Náprava Core Web Vitals. Časový rámec: jeden pracovný deň na potvrdenie rozsahu a diagnózy; jeden až desať pracovných dní na typickú opravu a vydanie, v závislosti od toho, či príčina spočíva v assete, zdieľanej šablóne, skripte tretej strany, doméne alebo CDN. Overenie v teréne nasleduje po priebežnom 28-dňovom okne údajov a je naplánované samostatne. Vlastník: zodpovedá výkonnostný inžinier alebo senior front-end inžinier. Technický SEO lead vlastní kritériá prijatia v teréne; vlastníci platformy, dizajnu, analytiky a produktu schvaľujú zmeny vo svojich systémoch.

Tento kontrolný zoznam mení diagnostikovaný výkonnostný nález na vydanú opravu overenú v teréne. Core Web Vitals sú metrike Google merajúce načítanie, odozvu a vizuálnu stabilitu u reálnych používateľov: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) a Cumulative Layout Shift (CLS). Time to First Byte (TTFB) a First Contentful Paint (FCP) sú podporné diagnostické metriky. Sú zahrnuté, pretože pomalá odpoveď alebo prázdna obrazovka spotrebúva čas dostupný na dosiahnutie dobrého LCP.

Prečo tento kontrolný zoznam a prečo práve tu

Tento kontrolný zoznam spotrebúva register náprav z auditu výkonu a Core Web Vitals . Táto predchádzajúca fáza identifikuje zlyhávajúcu metriku, dotknutú URL a šablónu, základnú hodnotu u reálnych používateľov, opakovateľné laboratórne podmienky, podozrivú príčinu, prioritu a vlastníka. Náprava začína až po existencii týchto polí. V opačnom prípade je vývojár požiadaný, aby „urobil stránku rýchlejšou" a prirodzene zmení to, čo nástroj zvýrazní ako prvé, bez ohľadu na to, či to spôsobuje zlyhanie v teréne.

Diagnostika musí pred akciou zúžiť tri úrovne: ktorá metrika, ktorá šablóna a ktorý prvok alebo úloha. Zlyhanie TTFB v celej doméne vyžaduje opravu platformy; LCP, ktoré zlyháva len na článkových stránkach, môže pochádzať z ich hero komponentu; INP po otvorení produktového filtra môže pochádzať z jedného obsluhovača udalosti; CLS na propagačných stránkach môže pochádzať z nerezervovaného banneru. Zaobchádzanie s týmito ako s jedným problémom vedie k širokým zmenám a nejasnému vlastníctvu.

Poradie záleží pri oprave. TTFB je upstream: kým nepríde prvý bajt odpovede, prehliadač nemôže objaviť normálne HTML zdroje ani vykresliť obsah stránky. Ak je TTFB slabý, opravte generovanie odpovede, cache, presmerovania a doručenie na okraji siete pred kompresiou LCP obrázka. Keď je čas odozvy v rámci rozpočtu, pracujte ďalej cez objavovanie zdrojov, sťahovanie zdrojov, vykresľovanie, interakcie a stabilitu rozloženia.

Vynechanie tohto kontrolného zoznamu zanechá audit ako správu. Jeho vykonanie pred diagnózou pozýva na naháňanie symptómov: kompresia obrázka, keď dominuje neskoré objavenie, alebo odkladanie skriptov, keď je doména pomalá.

Vstupy a výstupy

Výstupy umožňujú budúcemu vlastníkovi reprodukovať zlyhanie, identifikovať, čo bolo vydané, a rozlíšiť laboratórne prijatie od potvrdenia v teréne.

Kontrolný zoznam

Položky 1–4 dokončite pred zmenou produkcie. Položky 5–8 implementujú opravu zoradenú podľa závislostí. Položky 9–11 oddeľujú okamžité prijatie vydania od overenia v teréne.

1. Uzamknite zlyhávajúcu metriku, šablónu a prvok

Čo: zredukujte nález na jednu metriku, dotknutú množinu šablón a pomenovaný prvok, požiadavku, úlohu alebo serverový span. Prečo: celostránkové skóre neidentifikuje realizovateľnú prácu a dve URL môžu zlyhávať z rôznych dôvodov. Ako: pripojte p75 zlyhanie k trasám a porovnajte dotknuté a nedotknuté šablóny; pomenujte LCP prvok a oneskorenie, INP interakciu a úlohu, CLS prvok a spúšťač alebo cestu požiadavky TTFB a stav cache. Nástroj: CrUX dôkazy, trasovanie prehliadača, waterfall, serverové časovanie, inventár šablón a sledovač problémov. Hotovo, keď: dôkazy podporujú „metrika X zlyháva na šablóne Y, pretože Z vytvára oneskorenie alebo pohyb za podmienky C."

2. Potvrďte rozsah pomocou reprezentatívnych stránok

Čo: otestujte nález na typickej a najhoršej URL pre každú dotknutú šablónu plus jednu nedotknutú kontrolu. Prečo: oprava jednej stránky môže skryť zdieľanú chybu, zatiaľ čo globálna zmena môže byť zbytočná, keď problém spôsobuje jedna variant obsahu. Ako: udržujte konštantné podmienky zariadenia, siete, lokality, súhlasu, prihlásenia a cache; porovnajte použitie komponentov, hmotnosť assetov, časovanie odpovedí, aktivitu tretích strán a dĺžku obsahu. Nástroj: analytika, inventár šablón, nástroje výkonu prehliadača, monitor požiadaviek a testovacia matica. Hotovo, keď: každá šablóna v rozsahu je označená ako dotknutá alebo kontrolná, každá má reprodukovateľný dôkaz a rozsah vydania pomenúva komponent, cestu, rodinu assetov alebo vrstvu platformy, ktorá sa musí zmeniť.

3. Stanovte rozpočet a chráňte požadované správanie

Čo: definujte číselný cieľ, regresné zábradlia a funkcie, ktoré musia prežiť. Prečo: „rýchlejšie" nemá hranicu prijatia a odstránenie správcu súhlasov, analytickej značky, správania prístupnosti pre zameranie alebo produktovej funkcie môže vytvoriť zavádzajúce úspešné prejdenie. Ako: stanovte cieľ z rozhodovacej tabuľky nižšie, pridajte prísnejšiu internú rezervu tam, kde sa opakované testy líšia, a uveďte kritické cesty a necieľové metriky na opätovné testovanie. Nástroj: register nálezov, produktové požiadavky, plán analytiky, kontroly prístupnosti a rozpočet výkonu. Hotovo, keď: ticket uvádza cieľovú metriku a hodnotu, metódu laboratórneho prijatia, metódu prijatia v teréne, chránené správania, povolené kompromisy, podmienku rollbacku a menovaných schvaľovateľov.

4. Skontrolujte TTFB pred prácou na front-ende

Čo: zmerajte TTFB pri studenej a teplej cache z miest relevantných pre publikum. Prečo: TTFB je zahrnutý v každom nasledujúcom čase vykreslenia; front-endová práca nemôže nahradiť čas už strávený čakaním na HTML. Ako: rozdeľte požiadavku na DNS, pripojenie, presmerovania, čakanie na CDN, výpočet na doméne, čas databázy alebo upstream API a streamingové správanie tam, kde to inštrumentácia umožňuje. Porovnajte odpovede pri zásahu a nezasahnutí cache a potvrďte, že personalizácia alebo cookies neočakávane nevypínajú cache. Nástroj: waterfall požiadaviek, serverové časovanie, CDN a doménové logy, profilovanie aplikácie a syntetické monitorovanie požiadaviek. Hotovo, keď: TTFB je v rámci dohodnutého rozpočtu alebo je samostatný blokujúci nález platformy vlastnený a naplánovaný. Nezačnite LCP vylepšovanie, kým slabé TTFB zostáva nevysvetlené.

5. Najprv odstráňte oneskorenie servera a doručenia

Čo: opravte pomalú odpoveď domény, nezasahovanie cache, presmerovania alebo vzdialené doručenie. Prečo: tieto príčiny oneskorujú každý prvok a často ovplyvňujú viacero šablón. Ako: odstráňte vyhnuteľné presmerovania; cacheujte bezpečné HTML a dáta; zredukujte pomalú prácu databázy alebo API; presuňte prácu mimo kritickej cesty; vylaďte smerovanie CDN a kľúče cache. Nikdy neukladajte do cache súkromné odpovede bez schváleného dizajnu. Nástroj: profiler aplikácie, trasovanie dotazov, konfigurácia CDN, hlavičky odpovedí, monitorovanie a záťažové testovanie. Hotovo, keď: opakované studené a teplé testy spĺňajú rozpočet, varianty cache zostávajú správne, chyby neregredovali a prioritné URL vracajú zamýšľanú odpoveď bez dodatočného skoku.

6. Opravte oneskorenie objavenia, prenosu a vykreslenia LCP

Čo: skráťte Largest Contentful Paint , keď sa vykreslí najväčší viditeľný obrázok alebo textový blok. Prečo: príliš veľké hero prvky sú bežné, ale neskoré objavenie, nízka priorita, blokujúce CSS, JavaScript alebo fonty môžu dominovať. Ako: doručte správne dimenzovaný responzívny obrázok; nenačítavajte lenivo LCP asset nad záhybom; vystavte ho v počiatočnom HTML; prioritizujte alebo prednačítavajte len s dôkazmi; odstráňte blokovanie vykreslenia; a používajte podmnožinové, cacheovateľné fonty s vhodnou náhradou. Nástroj: rozpad LCP, waterfall, kontrola obrázkov, správa o pokrytí, trasovanie a vizuálne porovnanie. Hotovo, keď: zamýšľaný LCP prvok je konzistentný, jeho dominantné oneskorenie kleslo, reprezentatívne stránky spĺňajú rozpočet a šírka pásma, viditeľnosť textu a vykreslenie neregredovali.

7. Opravte INP pri zodpovednej interakcii

Čo: zredukujte interakciu zodpovednú za slabé Interaction to Next Paint , metriku odozvy. Prečo: odstránenie ľubovoľného JavaScriptu nemusí zasiahnuť pomalú udalosť. Ako: oddeľte oneskorenie vstupu, spracovania a prezentácie; rozbite dlhé úlohy; odstráňte synchronizovanú prácu; odložte nepodstatné tretie strany; vyhnite sa opakovanému rozloženiu; zredukujte opätovné vykreslenia; a uvoľnite priestor pre vykreslenie. Testujte na realistickom hardvéri s produkčnými tretími stranami. Nástroj: trasovanie interakcie, profil hlavného vlákna, záznamy dlhých úloh, profiler frameworku a realistické zariadenie. Hotovo, keď: kritické interakcie fungujú, zodpovedná úloha spĺňa rozpočet opakovaného testu, terénny proxy je zdokumentovaný a správanie analytiky, súhlasu, klávesnice a čítačky obrazovky neregredovalo.

8. Opravte CLS rezerváciou konečného rozloženia

Čo: zabráňte pohybu prispievajúcemu k Cumulative Layout Shift , skóre vizuálnej nestability. Prečo: obrázky, fonty, reklamy, bannery, vložené prvky a asynchrónne komponenty môžu posunúť rozhranie. Ako: nastavte vnútorné rozmery alebo aspect-ratio; rezervujte sloty pre dynamické moduly; používajte kompatibilné náhrady fontov; a animujte s transformáciami. Nástroj: oblasti posunu rozloženia, trasovanie, filmový pás, vizuálne regresné testy a obmedzený prehliadač. Hotovo, keď: každý významný zhluk posunu má pomenovaný zdroj, stránky spĺňajú rozpočet CLS počas načítania a kritických interakcií a rezervované miesto nezahaľuje žiadne ovládacie prvky.

9. Znovu otestujte celú sadu metrík a chránené cesty

Čo: porovnajte kandidáta na vydanie so zmrazenou základnou hodnotou za identických podmienok, potom otestujte produkciu. Prečo: zlepšenie jednej metriky môže poškodiť inú: odloženie JavaScriptu môže zlepšiť LCP, ale zhoršiť prvú interakciu, zatiaľ čo agresívna zmena fontu môže zlepšiť časovanie vykreslenia, ale vytvoriť posun rozloženia. Ako: spustite niekoľko kontrolovaných vzoriek, porovnajte deklarovanú štatistiku namiesto najlepšieho behu, skontrolujte trasovania, otestujte chránené cesty, overte správnosť odpovedí a otestujte dotknuté aj kontrolné šablóny. Nástroj: Lighthouse alebo ekvivalentný laboratórny nástroj, nástroje výkonu prehliadača, monitor požiadaviek, vizuálne a funkčné testy a kontrolný zoznam vydania. Hotovo, keď: cieľová metrika spĺňa svoj laboratórny rozpočet naprieč deklarovanou metódou opakovaného behu, TTFB/FCP/LCP/INP/CLS nevykazujú žiadnu kritickú regresiu, chránené správanie prechádza, produkcia obsluhuje zamýšľanú zmenu a rollback nie je spustený.

10. Anotujte vydanie a naplánujte kontrolu v teréne

Čo: zaznamenajte časovú pečiatku nasadenia, zmenený rozsah, cieľovú metriku, očakávaný smer a dátumy kontroly v teréne. Prečo: CrUX používa priebežné 28-dňové okno, takže skúsenosti spred vydania zostávajú v hlásenom p75 aj po nasadení. Bez anotácie môže tím označiť dobrú opravu za neúčinnú príliš skoro alebo neskorší pohyb pripísať nesprávnemu vydaniu. Ako: pripojte produkčnú verziu k nálezu, okamžite skontrolujte chyby, zaznamenajte skoré terénne hodnoty bez toho, aby ste ich považovali za konečné, a naplánujte vlastníkovi kontrolu dostatočne obnoveného okna. Nástroj: denník nasadenia, sledovač problémov, CrUX, AmICited Web Vitals a monitorovanie. Hotovo, keď: ticket je označený ako Lab accepted, anotácia vydania a okamžitý dôkaz sú priložené a existuje menovaný vlastník a kalendárny dátum pre overenie v teréne.

11. Overte pomocou terénnych dát a uzavrite alebo znovu otvorte

Čo: porovnajte porovnateľné terénne dáta p75 po dostatočnom obnovení priebežného okna. Prečo: zariadenia, siete, geografia, správanie cache, stavy súhlasu a interakcie reálnych používateľov nemôžu byť reprezentované jedným laboratórnym behom. Ako: použite rovnakú úroveň CrUX – URL alebo doménu – rovnakú metriku a porovnateľný rozsah publika; zohľadnite čiastočné nasadenie a iné vydania; skontrolujte reprezentantov šablón namiesto spoliehania sa len na agregát domény. Ak výsledok chýba, porovnajte aktuálnu trasu s pôvodným vyhlásením príčiny a znovu otvorte diagnostiku namiesto hromadenia nesúvisiacich úprav. Nástroj: AmICited Web Vitals, história CrUX, anotácie vydaní, segmenty analytiky a balík dôkazov. Hotovo, keď: cieľ spĺňa dohodnutý prah p75 a rozsah so zaznamenanými obmedzeniami, vtedy sa stav mení na Field verified; alebo je ticket explicitne znovu otvorený s novými dôkazmi, vlastníkom a ďalšou hypotézou.

Nástroje v AmICited

Otvorte AmICited Web Vitals na zobrazenie LCP, INP, CLS, FCP a TTFB z CrUX pre vašu doménu a sledovaných konkurentov. Použite ho pri diagnostike na zachytenie základnej hodnoty v teréne a po nasadení na overenie priebežného terénneho výsledku. Prázdna hodnota znamená nedostatok oprávnených terénnych dát, nie nulu a nie úspešné prejdenie. Produktové zobrazenie podporuje rozhodnutie; trasy, serverové časovanie a profily prehliadača stále identifikujú príčinu.

Použite Performance Impact na prepojenie dôkazov o výkone na úrovni stránky s pozíciou citácie a identifikáciu cenných pomalých stránok. Táto asociácia pomáha stanoviť priority nápravy, ale nedokazuje, že samotný výkon spôsobil výsledok citácie. Pri interpretácii pohybu zachovajte kontext relevantnosti, obsahu, autority a vydania.

Pre produktový pracovný postup postupujte podľa Ako skontrolovať svoje Core Web Vitals v AmICited . Návod vysvetľuje, kde sa metriky zobrazujú a ako fungujú porovnania s konkurentmi; tento kontrolný zoznam riadi diagnostiku, implementáciu a prijatie.

Rozhodovacie pravidlá: čo znamená zlý stav

Pre rozhodnutia v teréne používajte 75. percentil, skrátene p75: 75 % oprávnených zaznamenaných skúseností je na alebo pod touto hodnotou. Hraničná hodnota patrí do lepšieho pásma. LCP, INP a CLS určujú stav Core Web Vitals; TTFB a FCP sú podporné ukazovatele používané na zoradenie a diagnostiku práce.

Aplikujte tieto pravidlá v poradí:

1. Timeout, chyba servera, nesprávna odpoveď alebo prerušená kritická cesta blokujú vydanie bez ohľadu na skóre metriky.
2. Slabý TTFB je upstream LCP a je riešený ako prvý. Netvrdte, že ide o riešenie len pomocou obrázkov, keď server už spotreboval väčšinu rozpočtu na vykreslenie.
3. Slabé terénne metriky majú prednosť pred metrikami vyžadujúcimi zlepšenie. V rámci jedného pásma uprednostnite zdieľané príčiny šablón, návštevnosť a obchodne kritické cesty.
4. Prázdna hodnota na úrovni URL v teréne je neznáma. Použite laboratórny dôkaz a zdokumentovaný proxy, ale nepremenujte neznáme na dobré.
5. Jeden úspešný laboratórny beh nestačí. Deklarujte profil zariadenia/siete a metódu opakovaného behu pred testovaním.
6. Oprava je Lab accepted, keď nasadené správanie a kontrolované testy prechádzajú. Je Field verified až po tom, čo porovnateľné priebežné terénne dáta spĺňajú dohodnutý prah.
7. Ak doménové dáta prechádzajú, ale šablóna s vysokou návštevnosťou zlyháva, výsledok šablóny víťazí pre tento rozsah. Agregácia nesmie vymazať koncentrovaný problém používateľov.

Odovzdanie: balík nápravy a overenia

Odovzdajte jeden ticket alebo záznam v registri na každú koreňovú príčinu s podradenými rozsahmi tam, kde príčina ovplyvňuje viacero šablón. Použite tabuľku, sledovač problémov alebo technický dokument, ale zachovajte tieto polia:

ID nálezu a primárna metrika:
Terénny zdroj: URL | Doména
Terénne p75, pásmo a 28-dňové okno:
Dotknuté šablóny a reprezentatívne URL:
Kontrolná šablóna a URL:
Prvok, interakcia, požiadavka alebo serverový span:
Vyhlásenie príčiny a odkazy na dôkazy:
Laboratórny profil a základná hodnota opakovaného behu:
Cieľ, zábradlia a chránené cesty:
Zvolená náprava a zamietnuté alternatívy:
Vlastník z inžinieringu, schvaľovatelia a závislosti:
ID vydania/verzie a časová pečiatka nasadenia:
Okamžité produkčné a laboratórne výsledky:
Vlastník a dátum kontroly CrUX v teréne:
Porovnateľný terénny výsledok a obmedzenia:
Prah monitorovania a pravidlo znovuotvorenia:
Stav: Otvorené | Implementuje sa | Lab accepted | Field verified | Znovu otvorené | Akceptované riziko

Priložte trasy, waterfally, serverové spany, nahrávky posunov, profily interakcií, testovacie výstupy a anotáciu vydania. Akceptované riziko vyžaduje rozsah, dôvod, schvaľovateľa, dátum exspirácie a spúšťač monitorovania; nie je to úspešné prejdenie.

Balík je prijatý, keď iný inžinier dokáže reprodukovať pôvodný problém, identifikovať, prečo táto zmena ho rieši, potvrdiť, čo sa dostalo do produkcie, a zopakovať porovnanie v teréne bez toho, aby sa musel pýtať pôvodného vyšetrovateľa na rekonštrukciu práce.

Čo sa pokazí

Optimalizácia pred izoláciou príčiny. Generická kompresia a mazanie skriptov nahrádzajú diagnostiku. Vyžadujte najprv dôkaz metrika-šablóna-prvok.

Kompresia hero prvku, keď je doména pomalá. Menší obrázok sa nedá vykresliť skôr, než príde HTML. Najprv zmerajte a riešte TTFB, keď je mimo rozpočtu.

Oprava nesprávneho posunu. CLS môže pochádzať z reklamy, banneru súhlasu, fontu, vloženého prvku alebo hydratovaného komponentu. Pomenujte zdroj posunu.

Odkladanie každého skriptu. Nerozlišujúce odkladanie môže narušiť poradie súhlasov, analytiku, navigáciu, formuláre alebo prvú interakciu. Zmeňte zodpovednú vykonávaciu cestu a otestujte regresiu požadovaného správania.

Overenie jednej URL po vydaní zdieľanej šablóny. Vybraný príklad môže prejsť, zatiaľ čo ťažšia variant obsahu alebo iná konfigurácia komponentu stále zlyháva. Testujte typické, ťažké a kontrolné stránky.

Čítanie doménových údajov ako úspechu šablóny. Zdravé stránky s vysokou návštevnosťou môžu maskovať slabú kategóriu, článok alebo produktovú šablónu. Udržujte diagnostiku a prijatie na najužšom spoľahlivom rozsahu.

Uzavretie v deň nasadenia. Okamžité testy stanovujú laboratórne prijatie. Nenahrádzajú priebežné okno terénnych dát.

Čakanie 28 dní na objavenie pokazeného vydania. Potvrdenie v teréne vyžaduje čas, ale stavové kódy, chyby, cesty, vizuálna stabilita a kontrolované metriky sa kontrolujú okamžite. Priebežné dáta nie sú výhovorkou na preskočenie QA vydania.

Ďalšia fáza: priebežné monitorovanie a iterácia

Odovzdajte záznam overenia v teréne, anotáciu vydania, dotknuté šablóny, obmedzenia a prahy do priebežnej obnovy a iterácie . Potrebuje stabilnú základnú hodnotu, aby neskoršie zmeny obsahu, médií, šablón, kampaní a tretích strán mohli byť porovnávané, nie znovuobjavované ako nevysvetlený pohyb.

Ďalší vlastník zaznamenáva, kto sleduje ktorý prah, kde žijú dôkazy, ako často sú kontrolované a čo znovu otvára nápravu. Nová slabá metrika, opakovaný trend vyžadujúci zlepšenie v plne obnovenom okne, zmenený LCP prvok, nová pomalá interakcia alebo vydanie šablóny, ktoré mení diagnostikovanú cestu, by mali znovu otvoriť kontrolný zoznam pri položke 1. Neopakujte automaticky predchádzajúcu opravu: rovnaká metrika môže zlyhať pre iný prvok po redizajne.

Odovzdanie je dokončené, keď je stav v teréne explicitný, každé akceptované obmedzenie má vlastníka a dátum kontroly a monitorovanie môže spojiť regresiu so šablónou a vydaním. Ak overenie v teréne zostáva nevyriešené, ďalší vlastník dostane naplánovaný dátum kontroly a ticket zostáva v stave Lab accepted, nie uzavretý.

FAQ

FAQ k náprave Core Web Vitals