Audit výkonnosti a Core Web Vitals

Fáza P3 · Stupeň A — Pochopenie
Časový rámec: 4–8 hodín na reprezentatívny audit; 2–5 pracovných dní na celošablónové vyšetrovanie s engineeringovými trasami. 28-dňová field validácia prebieha po opravách a nepredlžuje počiatočný časový rámec auditu.
Vlastník: technický SEO líder vlastní rozsah a akceptáciu. Inžinier výkonnosti alebo senior front-end inžinier vlastní diagnostiku; vlastníci platformy, CDN, analytiky, dizajnu a produktu prispievajú tam, kde ich systémy spôsobujú oneskorenie alebo nestabilitu.

Táto fáza premieňa field dôkazy od reálnych používateľov a opakovateľné lab testy na register opráv naviazaný na URL, šablóny, metriky, vlastníkov a testy dokončenia – nie na všeobecné skóre rýchlosti.

Prečo táto fáza, a prečo práve tu

Výkonnosť patrí do stupňa A, pretože stránka, ktorá timeoutuje, je problémom crawlovania skôr, než problémom používateľskej skúsenosti. Crawler alebo retrieval agent má obmedzený rozpočet na požiadavky. Ak zdroj zlyháva, opakovane presmerováva alebo vracia neúplnú odpoveď, klient môže stránku opustiť skôr, ako vôbec vyhodnotí jej obsah. Rýchlejšie nadpisy, lepšie texty a silnejšia štruktúrovaná data nemôžu pomôcť obsahu, ktorý nie je spoľahlivo načítaný.

P3 nadväzuje na kanonické hostitele, zamýšľané indexovateľné šablóny, prioritné používateľské cesty, dôkazy o stavových kódoch a nevyriešené infraštruktúrne zistenia z technického baseline auditu . Toto poradie zabraňuje falošnej diagnostike. Napríklad päťsekundové „načítanie stránky“ spôsobené presmerovacou slučkou nie je úlohou na optimalizáciu obrázkov a rýchly test cacheovanej chybovej stránky nie je úspechom. P2 stanovuje, že správnu URL možno vyžiadať a vybrať; P3 stanovuje, že ju možno doručiť a používať v prijateľných časových a stabiltných limitoch.

Vykonanie tejto fázy neskôr vytvára prepracovanie. Obsahový tím môže publikovať do šablóny, ktorej hero prvok je vždy najpomalším elementom, alebo schváliť propagačné miesto, ktoré posúva každú produktovú kartu. Defekt sa potom znásobuje na nových stránkach.

Vstupy a výstupy

Vstupy robia vzorku reprezentatívnou. Výstupy tvoria zmluvu s ďalšou fázou: presne ktoré stránky sú spoľahlivo dostupné, ktoré podmienky zostávajú slabé a ktoré obmedzenia výkonnosti musia kvalifikovať neskoršie merania.

Field data a lab data sú rozdielne dôkazy

Field data opisujú, čo oprávnení Chrome používatelia skutočne zažili. Chrome User Experience Report, zvyčajne skracovaný ako CrUX, agreguje merania z reálnych návštev a reportuje 75. percentil: hodnotu, na alebo pod ktorou sa nachádza 75% zaznamenaných skúseností. Zahŕňa neporiadok reálnych zariadení, sietí, lokalít, cache, nástrojov na súhlas, relácií a interakcií. Použite ho na rozhodnutie, či používatelia prechádzajú publikovanými prahmi a či nasadená zmena časne zlepšila populáciu.

Lab data opisujú jedno kontrolované načítanie stránky alebo interakciu za deklarovaných podmienok. Lighthouse je lab test, ktorý aplikuje simuláciu zariadenia a siete, zachytáva trace a vysvetľuje pravdepodobné príčiny. Použite ho na reprodukovanie problému, porovnanie dvoch verzií pod rovnakým nastavením, kontrolu reťazcov požiadaviek a identifikáciu práce. Lab skóre je užitočný dôkaz, ale nedokazuje, že reálni používatelia prechádzajú.

Oba zdroje sa môžu rozchádzať bez toho, aby bol jeden nesprávny. Rýchly lab beh môže používať blízku lokalitu, teplú CDN a žiadnu zmysluplnú interakciu, zatiaľ čo field návštevníci zahŕňajú staršie telefóny a vzdialené siete. Zaznamenajte rozpor a preskúmajte jeho podmienky; nikdy nepriemerujte hodnoty ani nevyberajte tú, ktorá vyzerá zdravšie.

Kontrolný zoznam

Dokončite tieto kontroly v poradí. Každá položka uvádza akciu, dôvod, metódu, nástroj a akceptačnú podmienku, aby mohla byť priradená a znovu otestovaná.

1. Zmrazte reprezentatívnu URL a maticu podmienok

Čo: definujte URL, šablóny, profily zariadení, geografie, stavy súhlasu a stavy cache na testovanie. Prečo: audit len domovskej stránky môže uspieť, zatiaľ čo šablóna produktu, článku alebo pokladne zlyháva. Ako: spojte P2 inventár s údajmi o návštevnosti a obchodnej priorite; vyberte typické, ťažké a konverzne kritické príklady. Nástroj: analytika, crawl inventár, register vydaní a zdieľaný testovací hárok. Dokončené, keď: každá prioritná šablóna má vlastníkom schválenú produkčnú vzorku a každý test zaznamenáva predpoklady o zariadení, sieti, lokalite, prihlásení, súhlase a cache.

2. Zachyťte CrUX field baseline

Čo: zaznamenajte dostupné p75 field metriky na úrovni URL a samostatne na úrovni origin. Prečo: origin môže skryť slabú šablónu, zatiaľ čo individuálna URL s nízkou návštevnosťou nemusí mať publikovateľné dáta. Ako: použite rovnaký dátum pozorovania a 28-dňové okno, explicitne označte URL vs. origin a zaznamenajte prázdne hodnoty ako „nedostatok dát.“ Nástroj: AmICited Web Vitals a CrUX. Dokončené, keď: každá vzorkovaná URL má hodnoty LCP, INP, CLS, FCP a TTFB alebo zdokumentovaný neznámy stav; úroveň zdroja a okno sú jednoznačné.

3. Overte spoľahlivosť odpovede pred hodnotením pixelov

Čo: opakujte požiadavky a zaznamenajte stav, presmerovania, Time to First Byte (TTFB), time outy a nekonzistentné odpovede. TTFB je interval od začiatku požiadavky po príchod prvého bajtu odpovede. Prečo: stránka sa nemôže vykresliť skôr, než začne prichádzať jej HTML, a prerušované zlyhanie je závažnejšie než kozmetické spomalenie. Ako: testujte správanie studenej a teplej cache z relevantných regiónov, kontrolujte server timing a korelujte anomálie s CDN a origin logmi. Nástroj: monitor požiadaviek, browser network panel, CDN/origin observability a Lighthouse waterfall. Dokončené, keď: prioritné URL vracajú zamýšľanú 200 odpoveď bez neočakávaných skokov alebo timeoutov a každá pomalá alebo zlyhaná odpoveď má zaznamenané zistenie s vlastníkom.

4. Diagnostikujte Largest Contentful Paint

Čo: identifikujte Largest Contentful Paint (LCP) element a rozdeľte jeho čas na oneskorenie servera, objavenie zdroja, stiahnutie zdroja a oneskorenie renderovania. LCP meria, kedy sa dokončí vykreslenie najväčšieho viditeľného obrázka alebo textového bloku. Prečo: kompresia obrázka málo pomôže, keď ho browser objaví neskoro, a zmeny na front-ende nemôžu vymazať pomalé čakanie na zdroj. Ako: skontrolujte trace a waterfall, porovnajte cacheované a necacheované behy, skontrolujte prioritu preloadu, responzívne veľkosti obrázkov, render-blokujúce zdroje, správanie fontov a rendering na strane klienta. Nástroj: Lighthouse, browser performance tools, waterfall požiadaviek a kontrola obrázkov. Dokončené, keď: skutočný LCP element a dominantná podčasť sú pomenované pre každú zlyhávajúcu šablónu s reprodukovateľným pred meraním a špecifickou hypotézou opravy.

5. Diagnostikujte Interaction to Next Paint

Čo: otestujte cestu Interaction to Next Paint (INP) pre reálne akcie ako otvorenie menu, filtrovanie, pridanie do košíka, vstup do formulára a zatvorenie súhlasu. INP meria oneskorenie od používateľskej interakcie po zobrazenie nasledujúcej vizuálnej zmeny v prehliadači, pričom používa interakciu s vysokou latenciou z návštevy. Prečo: stránka môže vyzerať dokončená, ale stále ignorovať používateľa, kým JavaScript zamestnáva hlavné vlákno. Ako: reprodukujte dôležité akcie, kontrolujte dlhé úlohy a event handlery, testujte skripty tretích strán a oddeľte vstupné oneskorenie, čas spracovania a oneskorenie prezentácie. Nástroj: CrUX, browser performance trace, profilovanie interakcií a realistické zariadenie. Dokončené, keď: každá dôležitá interakcia bola vykonaná, pomalá interakcia a zodpovedná úloha sú identifikované pre zlyhávajúce šablóny a oprava má opakovateľný interakčný test.

6. Diagnostikujte Cumulative Layout Shift

Čo: lokalizujte neočakávané pohyby prispievajúce k Cumulative Layout Shift (CLS). CLS je bezrozmerné skóre predstavujúce neočakávaný vizuálny pohyb počas životnosti stránky. Prečo: neskorý banner, obrázok bez rozmerov, vymenený font, reklama alebo hydratovaná komponenta môžu posunúť odkaz, na ktorý sa používateľ chystá kliknúť, a môžu zmeniť miesto, kde automatická extrakcia nachádza obsah. Ako: použite layout-shift regióny a filmstrip, testujte oneskorené assety a stavy súhlasu a kontrolujte elementy bez rezervovaných rozmerov. Nástroj: CrUX, Lighthouse trace, browser rendering diagnostics a vizuálna regresná kontrola. Dokončené, keď: každý materiálny posun má zdrojový element, spúšťač a opravu rezervovaného miesta alebo renderovania; očakávaný pohyb spôsobený bezprostredne používateľskou akciou je zdokumentovaný samostatne.

7. Použite FCP na oddelenie oneskorenia prázdnej obrazovky

Čo: merajte First Contentful Paint (FCP), čas, kým browser vykreslí prvý text, obrázok, canvas alebo SVG obsah. Prečo: FCP rozlišuje medzi skorým znakom progresu a stránkou, ktorá zostáva prázdna, hoci nedokazuje, že hlavný obsah je pripravený. Ako: porovnajte FCP s TTFB a LCP, potom skontrolujte blokujúce CSS, fonty, skripty, serverom renderovaný markup a streaming správanie. Nástroj: CrUX, Lighthouse a sieťová/výkonnostná trace. Dokončené, keď: každé pomalé FCP je priradené oneskoreniu servera, blokovaniu renderovania, renderingu len na klientovi alebo inej dokázanej príčine, namiesto toho, aby bolo opísané iba ako „stránka je pomalá.“

8. Zoraďte zistenia podľa závažnosti, dosahu a závislostí

Čo: usporiadajte backlog podľa pásma zlyhania, ovplyvnenej návštevnosti a šablón, obchodnej kritickosti a upstream závislosti. Prečo: oprava piatich žltých skóre môže spotrebovať sprint, zatiaľ čo jedno červené zlyhanie TTFB oneskoruje každú stránku na zdroji. Ako: umiestnite zlyhania spoľahlivosti na prvé miesto, potom slabé metriky pred metrikami vyžadujúcimi zlepšenie; v rámci rovnakej závažnosti opravte zdieľané platformové príčiny a TTFB pred nadväzujúcou LPC prácou. Nástroj: register zistení, analytika, inventár šablón a engineering odhad. Dokončené, keď: každé zistenie má závažnosť, počet ovplyvnených URL alebo rozsah šablón, dôkaz, vlastníka, náročnosť, závislosť a explicitnú prioritu.

9. Validujte implementáciu v laboratóriu

Čo: porovnajte zmenenú verziu so zaznamenaným baseline za identických podmienok. Prečo: field data nemôžu poskytnúť okamžitú spätnú väzbu k vydaniu a neopakovateľný beh „po“ nemôže preukázať, že zmena kódu spôsobila rozdiel. Ako: spustite viacero kontrolovaných vzoriek, porovnajte mediány namiesto jediného najlepšieho behu, skontrolujte trace na regresie a otestujte kritické interakcie a rozloženia. Nástroj: Lighthouse, browser performance tools, staging alebo kontrolované produkčné vydanie a monitorovanie požiadaviek. Dokončené, keď: zamýšľaná príčina je odstránená, cieľová metrika prechádza dohodnutým lab rozpočtom naprieč opakovanými behmi, žiadna iná kritická metrika neregredovala a dôkaz je priložený k zisteniu.

10. Anotujte vydanie a počkajte na field potvrdenie

Čo: zaznamenajte čas nasadenia, rozsah, očakávanú metriku a dátumy validácie. Prečo: CrUX je kĺzavé 28-dňové okno, takže návštevy spred vydania zostávajú v reportovanom percentile aj po nasadení opravy. Ako: okamžite monitorujte chyby, kontrolujte smerový pohyb field údajov pri príchode nových dát a vykonajte finálne porovnanie až keď dostatok dní po vydaní reprezentuje okno. Nástroj: log nasadení, AmICited Web Vitals, CrUX a monitoring. Dokončené, keď: okamžité technické kontroly prechádzajú, anotácia vydania je viditeľná a existuje menovaný vlastník a dátum pre field potvrdenie; zistenie nie je označené ako „overené“ len na základe lab dôkazov.

Nástroje v AmICited

Otvorte https://app.amicited.com/audit/web-vitals na porovnanie vašej domény so sledovanými konkurentmi pomocou reálnych používateľských CrUX dát. Audit umiestňuje LCP, INP, CLS, FCP a TTFB do jednej tabuľky, označuje vašu doménu a zviditeľňuje chýbajúce field data namiesto toho, aby ich menil na zavádzajúcu nulu. Použite porovnanie na zodpovedanie dvoch otázok: či doména prechádza publikovanými prahmi a či konkurent obsluhujúci rovnaké publikum preukázal materiálne lepší field výsledok.

Funkcia Performance Impact prepája výkonnosť na úrovni stránky s pozíciou a pravdepodobnosťou citácie. Vnímajte tento vzťah ako dôkaz pre prioritizáciu, nie ako dôkaz, že rýchlosť sama o sebe spôsobila zmenu v citáciách. Ak sa pomalá citovaná stránka a rýchla necitovaná stránka líšia v autorite, relevantnosti alebo obsahu, výkonnosť je len jednou premennou. Užitočným signálom je, že ovplyvnená stránka je dostatočne hodnotná na to, aby bola opravená a monitorovaná.

Pre prevádzku produktu postupujte podľa How to Check Your Core Web Vitals in AmICited . Tento playbook definuje rozsah auditu, rozhodnutia a odovzdanie; tutoriál pokrýva kliknutia a čítania, takže duplikovať ho tu by vytvorilo dve inštrukcie, ktoré by sa mohli rozísť.

Rozhodovacie pravidlá: ako vyzerá zlý stav

Posudzujte Core Web Vitals z field dát na 75. percentile. „Dobrý“ znamená, že p75 hodnota je na alebo pod hranicou dobra. Hodnota na hranici patrí do lepšieho pásma; napríklad LCP presne 2,5 sekundy je dobrý. Podporné FCP a TTFB prahy usmerňujú diagnostiku a akceptáciu, ale nie sú súčasťou trojmetrikového hodnotenia Core Web Vitals.

Použite tieto pravidlá priority:

1. Zlyhané požiadavky, time outy a neplatné odpovede majú prednosť pred skóre. Spoľahlivosť je doručovacia brána.
2. Opravujte slabé pásma pred pásmami vyžadujúcimi zlepšenie. Červená je preukázaná zlá skúsenosť, nie príležitosť na vylepšenie.
3. Opravujte TTFB pred LCP, keď TTFB zlyháva. LCP nemôže nastať skôr, než začne odpoveď, takže backendové oneskorenie spotrebúva LCP rozpočet skôr, než browser vôbec čokoľvek vykreslí.
4. Uprednostňujte zdieľané príčiny pred izolovanými symptómami. Jedna oprava cache politiky naprieč štyrmi šablónami má prednosť pred štyrmi samostatnými úpravami obrázkov s menším dosahom.
5. Použite hodnotu návštevnosti a používateľskej cesty v rámci rovnakej závažnosti. Slabý INP na pokladni alebo LCP článku s vysokou návštevnosťou má prednosť pred nízkonávštevnostným archívom v rovnakom pásme.
6. Neoznačujte prázdnu CrUX hodnotu ako dobrú. Je neznáma. Použite opakovateľné lab dôkazy a porovnateľnú šablónu, kým nebude existovať dostatočný field objem.
7. Nesľubujte okamžitý field pohyb. Overte nasadenie teraz, potom nechajte kĺzavé okno nahradiť staršie skúsenosti pred prijatím alebo zamietnutím field výsledku.

Výstup: register opráv výkonnosti

Odovzdajte jeden register plus jeho priečinok s dôkazmi. Tabuľkový procesor, issue tracker alebo štruktúrovaná projektová tabuľka je prijateľná, ak zachováva tieto polia a umožňuje filtrovanie podľa šablóny, závažnosti, vlastníka a stavu:

ID a zistenie:
Ovplyvnené URL a šablóny:
Prioritná cesta a kontext návštevnosti:
Metrika a field pásmo:
CrUX úroveň, p75 hodnota a 28-dňové okno:
Lab konfigurácia a opakovaný baseline:
Pozorovaná príčina a odkaz na dôkaz:
Očakávaná podmienka a cieľ:
Odporúčaná zmena:
Závažnosť a zdôvodnenie priority:
Vlastník, závislosť a náročnosť:
Dátum vydania a anotácia:
Okamžitý lab akceptačný výsledok:
Dátum a výsledok field potvrdenia:
Stav: Otvorené | Naplánované | Lab akceptované | Field overené | Akceptované riziko

Priložte maticu URL, CrUX export, lab trace, waterfall, filmstripy, záznamy interakcií, dôkazy o posunoch rozloženia a anotácie vydaní. Deduplikujte podľa príčiny: ak rovnaký necacheovaný origin dotaz vytvára slabý TTFB naprieč tromi šablónami, vytvorte jedno rodičovské zistenie s tromi ovplyvnenými rozsahmi namiesto troch konkurenčných diagnóz.

„Akceptované riziko“ potrebuje menovaného schvaľovateľa, dôvod, ovplyvnený rozsah, dátum exspirácie alebo kontroly a podmienku monitorovania. Nie je náhradou za vlastníka. Odovzdanie je dokončené, keď inžinier dokáže reprodukovať zlyhanie a vlastník ďalšej fázy dokáže identifikovať, ktoré výsledky zostávajú obmedzené výkonnosťou.

Čo sa pokazí

Považovanie Lighthouse za verdikt. Skóre 100 v jednom lab behu neprepisuje slabé p75 field data. Zachovajte Lighthouse ako diagnostický dôkaz a CrUX ako populačný dôkaz.

Testovanie iba domovskej stránky. Vzorkujte každú vysoko hodnotnú šablónu plus ťažký príklad, inak defekty šablón uniknú z auditu.

Optimalizácia LCP obrázka pred kontrolou TTFB. Asset môže byť malý, zatiaľ čo zdroj strávi dve sekundy generovaním HTML. Rozdeľte LCP na jeho komponenty a najprv opravte upstream čas.

Použitie jediného najrýchlejšieho behu. Teplota cache, aktivita na pozadí a variabilita siete môžu vytvoriť lichotivú odľahlú hodnotu. Udržujte konfiguráciu fixnú a porovnávajte mediány opakovaných behov.

Vyhlásenie víťazstva deň po vydaní. Lab môže dokázať, že kód a doručovanie sa okamžite zmenili; 28-dňové field okno to nemôže. Anotujte vydanie a naplánujte field akceptáciu.

Označenie chýbajúcich CrUX dát ako nula. Žiadne dáta znamenajú, že nebola splnená podmienka oprávnenosti alebo prah návštevnosti. Nehovorí to nič o kvalite výkonnosti.

Hnanie sa za kompozitným skóre namiesto zlyhávajúcej skúsenosti. Súhrnné skóre sa môže zlepšiť, zatiaľ čo interakcia na pokladni stále zlyháva alebo hero prvok sa stále posúva. Akceptujte menované metriky a cesty, nie kozmetický pohyb skóre.

Odstránenie užitočnej funkcionality kvôli víťazstvu v teste. Vymazanie súhlasu, personalizácie, analytiky alebo správania prístupnosti z lab varianty vytvára výsledok, ktorý používatelia nikdy nedostanú. Optimalizujte produkčnú požiadavku alebo urobte explicitné produktové rozhodnutie.

Ignorovanie regresií mimo cieľovej metriky. Odloženie skriptov môže zlepšiť LCP, ale vytvoriť slabý INP pri prvej interakcii; rezervovanie nesprávnych rozmerov môže nahradiť oneskorenie načítania za CLS. Znovu otestujte všetkých päť metrík a kritickú používateľskú cestu.

Ďalšia fáza: AI prístupnosť a agent ready

Fáza AI accessibility and agent readiness dostáva reprezentatívnu maticu URL, dôkazy o spoľahlivosti odpovede, distribúciu TTFB, nevyriešené zistenia výkonnosti a vyhlásenie o tom, ktorý obsah je prítomný v počiatočnej odpovedi. Jej vlastník používa tieto dôkazy na rozlíšenie medzi zlyhaním prístupovej politiky a zlyhaním doručovania a na reprodukovanie reálnych podmienok, za ktorých agent načítava stránku.

Ďalšia fáza môže pokračovať, keď kritické URL spoľahlivo odpovedajú a žiadny nevyriešený defekt výkonnosti nerobí dôkazy o načítaní neinterpretovateľnými. Môže pokračovať s písomným obmedzením, keď metrika vyžadujúca zlepšenie ovplyvňuje používateľov, ale nebráni stabilnému prístupu. Mala by sa pozastaviť pre ovplyvnené šablóny, keď požiadavky timeoutujú, vracajú prerušované chyby alebo hlavná odpoveď pravidelne prekračuje dohodnutú kritickú hranicu.

Odovzdanie je dokončené, keď ďalší vlastník vie, ktoré URL reprezentujú každú šablónu, aké sú testovacie podmienky, aké sú zostávajúce zlyhania doručovania a či dôkazy z P3 už vysvetľujú pomalé načítanie agentom.

FAQ

Často kladené otázky