Audit výkonu a Core Web Vitals

Fáze P3 · Stupeň A — Porozumění
Časový rámec: 4–8 hodin pro reprezentativní audit; 2–5 pracovních dnů pro celošablonové vyšetřování s vývojářskými záznamy. 28denní terénní validace probíhá po opravách a neprodlužuje počáteční časový rámec auditu.
Vlastník: vedoucí technického SEO vlastní rozsah a akceptaci. Výkonnostní inženýr nebo senior front-end inženýr vlastní diagnostiku; vlastníci platformy, CDN, analytiky, designu a produktu přispívají tam, kde jejich systémy vytvářejí zpoždění nebo nestabilitu.

Tato fáze převádí terénní důkazy od skutečných uživatelů a opakovatelné laboratorní testy do registru nápravných opatření svázaného s URL, šablonami, metrikami, vlastníky a akceptačními testy – nikoli generického skóre rychlosti.

Proč tato fáze a proč právě zde

Výkon patří do stupně A, protože stránka, která vyprší, je problémem crawlování dříve, než je problémem uživatelské zkušenosti. Crawler nebo retrívní agent má omezený rozpočet na požadavky. Pokud zdroj zamrzne, opakovaně přesměrovává nebo vrací neúplnou odpověď, může klient stránku opustit dříve, než stihne vyhodnotit její obsah. Rychlejší nadpisy, lepší text a silnější schema nemohou pomoci obsahu, který není spolehlivě načten.

P3 spotřebovává kanonické hostitele, zamýšlené indexovatelné šablony, prioritní cesty, důkazy o stavových kódech a nevyřešená zjištění infrastruktury z technického výchozího auditu . Toto pořadí zabraňuje falešné diagnóze. Například pětisekundové „načtení stránky“ způsobené smyčkou přesměrování není úkolem na optimalizaci obrázků a rychlý test chybové stránky v mezipaměti není úspěch. P2 stanoví, že správnou URL lze vyžádat a vybrat; P3 stanoví, že ji lze doručit a používat v přijatelných časových a stabilních limitech.

Provedení této fáze pozdě vytváří přepracování. Obsahový tým může publikovat do šablony, jejíž hero prvek je vždy nejpomalejším prvkem, nebo schválit propagační slot, který posouvá každou kartu produktu. Vada se pak násobí napříč novými stránkami.

Vstupy a výstupy

Vstupy činí vzorek reprezentativním. Výstupy tvoří smlouvu pro další fázi: přesně které stránky jsou spolehlivě dostupné, které podmínky zůstávají slabé a která výkonnostní omezení musí omezit pozdější měření.

Terénní data a laboratorní data jsou různé důkazy

Terénní data popisují, co způsobilí uživatelé Chrome skutečně zažili. Chrome User Experience Report, obvykle zkracovaný jako CrUX, agreguje měření z reálných návštěv a reportuje 75. percentil: hodnotu, na nebo pod kterou spadá 75 % zaznamenaných zkušeností. Zahrnuje nepravidelnost skutečných zařízení, sítí, míst, mezipamětí, nástrojů pro souhlas, relací a interakcí. Použijte jej k rozhodnutí, zda uživatelé procházejí zveřejněnými prahovými hodnotami a zda odeslaná změna nakonec populaci zlepšila.

Laboratorní data popisují jedno kontrolované načtení stránky nebo interakci za deklarovaných podmínek. Lighthouse je laboratorní test, který aplikuje simulaci zařízení a sítě, zachycuje záznam a vysvětluje pravděpodobné příčiny. Použijte jej k reprodukování problému, porovnání dvou sestavení za stejných podmínek, prozkoumání řetězců požadavků a identifikaci práce. Laboratorní skóre je užitečný důkaz, ale neprokazuje, že skuteční uživatelé procházejí.

Oba zdroje se mohou rozcházet, aniž by jeden z nich byl špatně. Rychlý laboratorní běh může používat blízké umístění, zahřáté CDN a žádnou smysluplnou interakci, zatímco terénní návštěvníci zahrnují starší telefony a vzdálené sítě. Zaznamenejte rozpor a prošetřete jeho podmínky; nikdy hodnoty neprůměrujte ani nevybírejte ten, který vypadá zdravěji.

Kontrolní seznam

Dokončete tyto kontroly v pořadí. Každá položka uvádí akci, důvod, metodu, nástroj a akceptační podmínku, aby mohla být přiřazena a znovu otestována.

1. Zmrazte reprezentativní matici URL a podmínek

Co: definujte URL, šablony, profily zařízení, geografické oblasti, stavy souhlasu a stavy mezipaměti k testování. Proč: audit pouze domovské stránky může projít, zatímco produktová, článková nebo pokladní šablona selže. Jak: spojte inventář z P2 s daty o provozu a obchodní prioritě; vyberte typické, těžké a konverzně kritické příklady. Nástroj: analytika, inventář z crawlování, registr vydání a sdílený testovací list. Dokončeno, když: každá prioritní šablona má vlastníkem schválený produkční vzorek a každý test zaznamenává předpoklady o zařízení, síti, umístění, přihlášení, souhlasu a mezipaměti.

2. Zachyťte terénní základnu CrUX

Co: zaznamenejte dostupné p75 terénní metriky na úrovni URL a samostatně na úrovni zdroje. Proč: zdroj může skrýt slabou šablonu, zatímco jednotlivá URL s nízkým provozem nemusí mít publikovatelná data. Jak: použijte stejné datum pozorování a 28denní okno, explicitně označte URL versus zdroj a zaznamenejte prázdné hodnoty jako „nedostatek dat“. Nástroj: AmICited Web Vitals a CrUX. Dokončeno, když: každá vzorkovaná URL má hodnoty LCP, INP, CLS, FCP a TTFB nebo zdokumentovaný neznámý stav; úroveň zdroje a okno jsou jednoznačné.

3. Ověřte spolehlivost odezvy před hodnocením pixelů

Co: opakujte požadavky a zaznamenejte stav, přesměrování, Time to First Byte (TTFB), timeouty a nekonzistentní odpovědi. TTFB je interval od začátku požadavku do příchodu prvního bajtu odpovědi. Proč: stránka se nemůže vykreslit, dokud nezačne přicházet její HTML, a občasné selhání je závažnější než kosmetické zpomalení. Jak: testujte chování studené a teplé mezipaměti z relevantních regionů, prozkoumejte načasování serveru a korelujte anomálie s logy CDN a zdroje. Nástroj: monitorování požadavků, síťový panel prohlížeče, observabilita CDN/zdroje a vodopád Lighthouse. Dokončeno, když: prioritní URL vracejí zamýšlenou odpověď 200 bez neočekávaných skoků nebo timeoutů a každá pomalá nebo neúspěšná odpověď má zaznamenané zjištění s vlastníkem.

4. Diagnostikujte Largest Contentful Paint

Co: identifikujte prvek Largest Contentful Paint (LCP) a rozdělte jeho čas na zpoždění serveru, objevování zdroje, stahování zdroje a zpoždění renderování. LCP měří, kdy se největší viditelný obrázek nebo textový blok dokončí vykreslování. Proč: komprese obrázku pomáhá málo, když jej prohlížeč objeví pozdě, a změny na front-endu nemohou vymazat pomalé čekání na zdroj. Jak: prozkoumejte záznam a vodopád, porovnejte běhy s mezipamětí a bez ní, zkontrolujte prioritu přednačítání, responzivní velikost obrázků, blokující zdroje renderování, chování písem a vykreslování na straně klienta. Nástroj: Lighthouse, vývojářské nástroje prohlížeče, vodopád požadavků a inspekce obrázků. Dokončeno, když: skutečný LCP prvek a dominantní podčást jsou pojmenovány pro každou selhávající šablonu, s reprodukovatelným předchozím měřením a specifickou hypotézou opravy.

5. Diagnostikujte Interaction to Next Paint

Co: otestujte cestu Interaction to Next Paint (INP) pro skutečné akce, jako je otevření menu, filtrování, přidání do košíku, vstup do formuláře a odmítnutí souhlasu. INP měří zpoždění od uživatelské interakce do okamžiku, kdy prohlížeč zobrazí další vizuální aktualizaci, a to pomocí interakce s vysokou latencí z návštěvy. Proč: stránka může vypadat dokončená, ale stále ignorovat uživatele, zatímco JavaScript zabírá hlavní vlákno. Jak: reprodukujte důležité akce, prozkoumejte dlouhé úlohy a obsluhy událostí, otestujte skripty třetích stran a oddělte vstupní zpoždění, dobu zpracování a zpoždění prezentace. Nástroj: CrUX, záznam výkonu prohlížeče, profilování interakcí a realistické zařízení. Dokončeno, když: každá důležitá interakce byla vyzkoušena, pomalá interakce a odpovědná úloha jsou identifikovány pro selhávající šablony a oprava má opakovatelný interakční test.

6. Diagnostikujte Cumulative Layout Shift

Co: lokalizujte neočekávané pohyby přispívající k Cumulative Layout Shift (CLS). CLS je bezrozměrné skóre představující neočekávaný vizuální pohyb během životnosti stránky. Proč: pozdní banner, nevelikostně definovaný obrázek, vyměněné písmo, reklama nebo hydratovaná komponenta mohou posunout odkaz, na který uživatel právě kliká, a mohou změnit, kde automatická extrakce nachází obsah. Jak: použijte oblasti posunu rozvržení a filmový pás, testujte zpožděné assety a stavy souhlasu a prozkoumejte prvky bez vyhrazených rozměrů. Nástroj: CrUX, záznam Lighthouse, diagnostika renderování prohlížeče a vizuální regresní zachycení. Dokončeno, když: každý materiální posun má zdrojový prvek, spouštěč a opravu rezervovaného místa nebo renderování; očekávaný pohyb způsobený okamžitě uživatelskou akcí je zdokumentován samostatně.

7. Použijte FCP k oddělení zpoždění prázdné obrazovky

Co: změřte First Contentful Paint (FCP), čas do okamžiku, kdy prohlížeč vykreslí první text, obrázek, plátno nebo SVG obsah. Proč: FCP odlišuje časný známku pokroku od stránky, která zůstává prázdná, i když neprokazuje, že je hlavní obsah připraven. Jak: porovnejte FCP s TTFB a LCP, poté prozkoumejte blokující CSS, písma, skripty, serverem vykreslený kód a chování streamování. Nástroj: CrUX, Lighthouse a záznam sítě/výkonu. Dokončeno, když: každé pomalé FCP je přiřazeno zpoždění serveru, blokování renderování, vykreslování pouze na klientovi nebo jiné doložené příčině, namísto pouhého popisu „stránka je pomalá“.

8. Seřaďte zjištění podle závažnosti, dosahu a závislostí

Co: uspořádejte backlog podle pásma selhání, ovlivněného provozu a šablon, obchodní kritičnosti a upstreamové závislosti. Proč: oprava pěti žlutých skóre může spotřebovat sprint, zatímco jedno červené selhání TTFB zpožďuje každou stránku na zdroji. Jak: umístěte selhání spolehlivosti jako první, poté špatné metriky před metrikami vyžadujícími zlepšení; v rámci stejné závažnosti opravte sdílené příčiny platformy a TTFB před downstreamovou prací na LCP. Nástroj: registr zjištění, analytika, inventář šablon a inženýrský odhad. Dokončeno, když: každé zjištění má závažnost, počet ovlivněných URL nebo rozsah šablon, důkazy, vlastníka, úsilí, závislost a explicitní prioritu.

9. Validujte implementaci v laboratoři

Co: porovnejte změněné sestavení se zaznamenanou základnou za identických podmínek. Proč: terénní data nemohou poskytnout okamžitou zpětnou vazbu k vydání a neopakovatelný běh „po“ nemůže prokázat, že změna kódu způsobila rozdíl. Jak: spusťte více kontrolovaných vzorků, porovnejte mediány namísto jediného nejlepšího běhu, prozkoumejte záznam na regrese a otestujte kritické interakce a rozvržení. Nástroj: Lighthouse, vývojářské nástroje prohlížeče, stagingové nebo kontrolované produkční vydání a monitorování požadavků. Dokončeno, když: zamýšlená příčina je odstraněna, cílová metrika prochází dohodnutým laboratorním rozpočtem napříč opakovanými běhy, žádná jiná kritická metrika neregredovala a důkazy jsou připojeny ke zjištění.

10. Anotujte vydání a vyčkejte na terénní potvrzení

Co: zaznamenejte čas nasazení, rozsah, očekávanou metriku a validační data. Proč: CrUX je klouzavé 28denní okno, takže návštěvy před vydáním zůstávají v reportovaném percentilu i po odeslání opravy. Jak: monitorujte chyby okamžitě, kontrolujte směrový pohyb terénních dat s příchodem nových dat a proveďte finální srovnání až poté, co dostatek dnů po vydání reprezentuje okno. Nástroj: log nasazení, AmICited Web Vitals, CrUX a monitorování. Dokončeno, když: okamžité technické kontroly projdou, anotace vydání je viditelná a existuje jmenovaný vlastník a datum pro terénní potvrzení; zjištění není označeno jako „ověřeno“ pouze z laboratorních důkazů.

Nástroje v AmICited

Otevřete https://app.amicited.com/audit/web-vitals pro porovnání vaší domény se sledovanými konkurenty pomocí dat od skutečných uživatelů z CrUX. Audit umísťuje LCP, INP, CLS, FCP a TTFB do jedné tabulky, označuje vaši doménu a zpřehledňuje chybějící terénní data, namísto aby je proměnil v zavádějící nulu. Použijte srovnání k zodpovězení dvou otázek: zda doména prochází zveřejněnými prahovými hodnotami a zda konkurent obsluhující stejné publikum prokázal materiálně lepší terénní výsledek.

Funkce Performance Impact propojuje výkon na úrovni stránky s pozicí citace a pravděpodobností. Vnímejte vztah jako důkaz pro priorizaci, nikoli jako důkaz, že rychlost sama o sobě způsobila změnu citace. Pokud se pomalá citovaná stránka a rychlá necitovaná stránka liší v autoritě, relevanci nebo obsahu, je výkon pouze jednou proměnnou. Užitečným signálem je, že dotčená stránka je natolik hodnotná, aby stála za opravu a monitorování.

Pro provoz produktu postupujte podle Jak zkontrolovat Core Web Vitals v AmICited . Tento playbook definuje rozsah auditu, rozhodnutí a předání; výukový program pokrývá kliknutí a čtení, takže by jejich duplikace zde vytvořila dvě instrukce, které by se mohly rozcházet.

Rozhodovací pravidla: jak vypadá špatný stav

Posuzujte Core Web Vitals z terénních dat na 75. percentilu. „Dobrý“ znamená, že p75 hodnota je na nebo pod hranicí dobra. Hodnota na hranici patří do lepšího pásma; například LCP přesně 2,5 sekundy je dobré. Podpůrné prahové hodnoty FCP a TTFB vedou diagnostiku a akceptaci, ale nejsou součástí třímetrikového hodnocení úspěšnosti Core Web Vitals.

Použijte tato pravidla priority:

1. Neúspěšné požadavky, timeouty a neplatné odpovědi mají přednost před skóre. Spolehlivost je brána doručení.
2. Opravte špatná pásma před pásmy vyžadujícími zlepšení. Červená je prokázaná špatná zkušenost, nikoli příležitost k vyleštění.
3. Opravte TTFB před LCP, pokud TTFB selhává. LCP nemůže nastat dříve, než začne odpověď, takže backendové zpoždění spotřebovává rozpočet LCP dříve, než prohlížeč může cokoli vykreslit.
4. Upřednostněte sdílené příčiny před izolovanými symptomy. Jedna oprava politiky mezipaměti napříč čtyřmi šablonami má přednost před čtyřmi samostatnými úpravami obrázků s menším dosahem.
5. Použijte hodnotu provozu a cesty v rámci stejné závažnosti. Špatné INP u pokladny nebo LCP u článku s vysokým provozem má přednost před málo navštěvovaným archivem ve stejném pásmu.
6. Neoznačujte prázdnou CrUX hodnotu jako dobrou. Je neznámá. Použijte opakovatelné laboratorní důkazy a srovnatelnou šablonu, dokud nebude existovat dostatek terénních dat.
7. Neslibujte okamžitý pohyb v terénních datech. Validujte nasazení nyní, pak nechte klouzavé okno nahradit starší zkušenosti, než přijmete nebo odmítnete terénní výsledek.

Výstup: registr nápravy výkonu

Předejte inženýrům jeden registr plus jeho složku s důkazy. Tabulkový procesor, sledovač úkolů nebo strukturovaná projektová tabulka je přijatelná, pokud zachovává tato pole a umožňuje filtrování podle šablony, závažnosti, vlastníka a stavu:

ID a zjištění:
Ovlivněné URL a šablony:
Prioritní cesta a kontext provozu:
Metrika a terénní pásmo:
Úroveň CrUX, p75 hodnota a 28denní okno:
Laboratorní konfigurace a opakovaná základna:
Zjištěná příčina a odkaz na důkaz:
Očekávaný stav a cíl:
Doporučená změna:
Závažnost a zdůvodnění priority:
Vlastník, závislost a úsilí:
Datum vydání a anotace:
Okamžitý výsledek laboratorní akceptace:
Datum a výsledek terénního potvrzení:
Stav: Otevřeno | Naplánováno | Laboratorně akceptováno | Terénně ověřeno | Akceptované riziko

Připojte matici URL, export CrUX, laboratorní záznamy, vodopády, filmové pásy, nahrávky interakcí, důkazy o posunu rozvržení a anotace vydání. Deduplikujte podle příčiny: pokud stejný dotaz na zdroj bez mezipaměti vytváří špatné TTFB napříč třemi šablonami, vytvořte jedno nadřazené zjištění se třemi ovlivněnými rozsahy, nikoli tři konkurenční diagnózy.

„Akceptované riziko“ vyžaduje jmenovaného schvalovatele, důvod, ovlivněný rozsah, datum vypršení platnosti nebo přezkumu a podmínku monitorování. Nenahrazuje vlastníka. Předání je kompletní, když inženýr dokáže reprodukovat selhání a vlastník další fáze dokáže identifikovat, které výsledky zůstávají omezeny výkonem.

Co se pokazí

Považování Lighthouse za konečný verdikt. Skóre 100 v jednom laboratorním běhu nepřebíjí špatná p75 terénní data. Zachovejte Lighthouse jako diagnostický důkaz a CrUX jako populační důkaz.

Testování pouze domovské stránky. Vzorkujte každou hodnotnou šablonu plus těžký příklad, jinak vady šablon uniknou auditu.

Optimalizace LCP obrázku před kontrolou TTFB. Asset může být malý, zatímco zdroj stráví dvě sekundy generováním HTML. Rozdělte LCP na jeho komponenty a opravte nejprve upstream čas.

Použití jediného nejrychlejšího běhu. Zahřátí mezipaměti, aktivita na pozadí a kolísání sítě mohou vytvořit lichotivou odlehlou hodnotu. Udržujte konfiguraci pevnou a porovnávejte mediány z opakovaných běhů.

Vyhlášení vítězství den po vydání. Laboratoř může prokázat, že se kód a doručení okamžitě změnily; 28denní terénní okno nikoli. Anotujte vydání a naplánujte terénní akceptaci.

Označování chybějících CrUX dat jako nula. Žádná data znamenají, že nebyl splněn práh způsobilosti nebo provozu. Neříkají nic o kvalitě výkonu.

Honba za kompozitním skóre místo selhávající zkušenosti. Souhrnné skóre se může zlepšit, zatímco interakce u pokladny stále váhá nebo hero prvek se stále posouvá. Akceptujte pojmenované metriky a cesty, nikoli kosmetický pohyb skóre.

Odstranění užitečné funkcionality pro vítězství v testu. Smazání souhlasu, personalizace, analytiky nebo chování pro přístupnost z laboratorní varianty vytváří výsledek, který uživatelé nikdy neobdrží. Optimalizujte produkční požadavek nebo udělejte explicitní produktové rozhodnutí.

Ignorování regresí mimo cílovou metriku. Odložení skriptů může zlepšit LCP, ale vytvořit špatné INP při první interakci; rezervování špatných rozměrů může nahradit zpoždění načítání za CLS. Znovu otestujte všech pět metrik a kritickou cestu.

Další fáze: AI přístupnost a připravenost pro agenty

Fáze AI přístupnost a připravenost pro agenty přebírá reprezentativní matici URL, důkazy o spolehlivosti odezvy, distribuci TTFB, nevyřešená zjištění výkonu a prohlášení o tom, který obsah je přítomen v počáteční odpovědi. Její vlastník používá tyto důkazy k rozlišení selhání přístupové politiky od selhání doručení a k reprodukci reálných podmínek, za kterých agent načítá stránku.

Další fáze může pokračovat, když kritické URL reagují spolehlivě a žádná nevyřešená výkonnostní vada nečiní důkazy o načítání neinterpretovatelnými. Může pokračovat s písemným omezením, když metrika vyžadující zlepšení ovlivňuje uživatele, ale nebrání stabilnímu přístupu. Měla by se pozastavit pro ovlivněné šablony, když požadavky timeoutují, vracejí občasné chyby nebo hlavní odpověď pravidelně překračuje dohodnutý kritický práh.

Předání je kompletní, když další vlastník ví, které URL představují jednotlivé šablony, testovací podmínky, zbývající selhání doručení a zda důkazy z P3 již vysvětlují pomalé načítání agentem.

FAQ

Často kladené otázky