Sjekkliste for utbedring av Core Web Vitals

Sjekkliste: Utbedring av Core Web Vitals. Tidsramme: én arbeidsdag for å bekrefte omfang og diagnose; én til ti arbeidsdager for en typisk rettelse og utgivelse, avhengig av om årsaken ligger i en ressurs, delt mal, tredjepartsskript, opprinnelse eller CDN. Feltverifisering følger det rullende 28-dagers datavinduet og planlegges separat. Eier: en ytelsesingeniør eller senior frontend-ingeniør er ansvarlig. Den tekniske SEO-lederen eier feltgodkjenningskriteriene; plattform-, design-, analyse- og produkteiere godkjenner endringer i sine systemer.

Denne sjekklisten gjør et diagnostisert ytelsesfunn til en utgitt, feltverifisert rettelse. Core Web Vitals er Googles virkelige brukermålinger av lasting, responsivitet og visuell stabilitet: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) og Cumulative Layout Shift (CLS). Time to First Byte (TTFB) og First Contentful Paint (FCP) er støttende diagnosemålinger. De er inkludert fordi en treg respons eller tom skjerm forbruker tiden som er tilgjengelig for å oppnå en god LCP.

Hvorfor denne sjekklisten, og hvorfor her

Denne sjekklisten bruker utbedringsregisteret fra ytelses- og Core Web Vitals-revisjonen . Den tidligere fasen identifiserer den feilende måleparameteren, berørt nettadresse og mal, virkelig brukerbasislinje, repeterbar laboratorietilstand, mistenkt årsak, prioritet og eier. Utbedring begynner først etter at disse feltene finnes. Ellers blir en utvikler bedt om å “gjøre siden raskere” og vil naturligvis endre det et verktøy fremhever først, uavhengig av om det forårsaker feltfeilen.

Diagnose må smalne inn på tre nivåer før handling: hvilken måleparameter, hvilken mal, og hvilket element eller oppgave. En TTFB-feil på hele domenet trenger en plattformrettelse; LCP som feiler kun på artikkelsider kan komme fra deres hero-komponent; INP etter åpning av et produktfilter kan komme fra én hendelsesbehandler; CLS på reklamesider kan komme fra en banner uten reservert plass. Å behandle disse som ett problem gir brede endringer og uklart eierskap.

Rekkefølgen har betydning innad i rettelsen. TTFB er oppstrøms: før den første responsbyten ankommer, kan ikke nettleseren oppdage vanlige HTML-ressurser eller gjengi sideinnhold. Hvis TTFB er dårlig, fiks responsgenerering, caching, omdirigeringer og kantleveranse før du komprimerer LCP-bildet. Etter at responstiden er innenfor budsjett, arbeid deg fremover gjennom ressursgjenfinning, ressursnedlasting, gjengivelse, interaksjoner og layoutstabilitet.

Å hoppe over denne sjekklisten gjør revisjonen til en rapport. Å gjennomføre den før diagnose inviterer til symptomjakt: komprimering av et bilde når sen oppdagelse dominerer, eller utsettelse av skript når opprinnelsen er treg.

Inndata og utdata

Utdatene lar en fremtidig eier reprodusere feilen, identifisere hva som ble lansert, og skille laboratorie-godkjenning fra feltbekreftelse.

Sjekklisten

Fullfør punktene 1–4 før du endrer produksjonsmiljøet. Punktene 5–8 implementerer rettelsen i avhengighetsrekkefølge. Punktene 9–11 skiller umiddelbar utgivelsesgodkjenning fra feltverifisering.

1. Lås den feilende måleparameteren, malen og elementet

Hva: reduser funnet til én måleparameter, berørt malsett og navngitt element, forespørsel, oppgave eller serverintervall. Hvorfor: en skåre for hele nettstedet identifiserer ikke implementerbart arbeid, og to nettadresser kan feile av forskjellige grunner. Hvordan: sammenstill p75-feilen med spor og sammenlign berørte og upåvirkede maler; navngi LCP-elementet og forsinkelsen, INP-interaksjonen og oppgaven, CLS-elementet og utløseren, eller TTFB-forespørselsbanen og buffer-tilstanden. Verktøy: CrUX-bevis, nettleserspor, vannfall, servertiming, maloversikt og issuesporing. Ferdig når: bevis støtter “måleparameter X feiler på mal Y fordi Z skaper forsinkelse eller bevegelse under betingelse C.”

2. Bekreft omfang med representative sider

Hva: test funnet på en typisk og en worst-case nettadresse for hver berørt mal, samt én upåvirket kontroll. Hvorfor: en rettelse på én side kan skjule en delt feil, mens en global endring kan være unødvendig når én innholdsvariant forårsaker problemet. Hvordan: hold enhet, nettverk, lokasjon, samtykke, innlogging og bufferforhold konstante; sammenlign komponentbruk, ressursvekt, responstid, tredjepartsaktivitet og innholdslengde. Verktøy: analyseverktøy, maloversikt, nettleserens ytelsesverktøy, forespørselsmonitor og en testmatrise. Ferdig når: hver mal innenfor omfanget er merket som berørt eller kontroll, hver har reproduserbare bevis, og utgivelsesomfanget navngir komponenten, ruten, ressursfamilien eller plattformlaget som må endres.

3. Sett budsjettet og beskytt nødvendig atferd

Hva: definer det numeriske målet, regresjonssikringene og funksjonene som må overleve. Hvorfor: “raskere” har ingen godkjenningsgrense, og sletting av en samtykkeadministrator, analyse-tagg, tilgjengelig fokusatferd eller produktfunksjon kan skape en misvisende bestått. Hvordan: sett målet fra beslutningstabellen nedenfor, legg til en strengere intern buffer der gjentatte tester varierer, og list opp kritiske reiser og ikke-mål-måleparametere som skal testes på nytt. Verktøy: funnsregister, produktkrav, analyseplan, tilgjengelighetssjekker og ytelsesbudsjett. Ferdig når: saken oppgir mål-måleparameter og verdi, laboratorie-godkjenningsmetode, feltgodkjenningsmetode, beskyttet atferd, tillatte avveininger, rollback-betingelse og navngitte godkjennere.

4. Sjekk TTFB før frontend-arbeid

Hva: mål TTFB under kalde og varme bufferforhold fra målgrupperelevante lokasjoner. Hvorfor: TTFB er inkludert i hver påfølgende gjengivelsestid; frontend-arbeid kan ikke hente inn tid som allerede er brukt på å vente på HTML. Hvordan: del forespørselen inn i DNS, tilkobling, omdirigeringer, CDN-ventetid, opprinnelsesberegning, database- eller API-tid oppstrøms, og strømmeatferd der instrumentering tillater det. Sammenlign buffer-treff- og bom-svar og bekreft at personalisering eller informasjonskapsler ikke deaktiverer buffering uventet. Verktøy: forespørselsvannfall, servertiming, CDN- og opprinnelseslogger, applikasjonsprofilering og syntetisk forespørselsmonitorering. Ferdig når: TTFB er innenfor det avtalte budsjettet, eller et separat blokkerende plattformfunn er eid og planlagt. Ikke begynn LCP-pussing mens en dårlig TTFB forblir uforklart.

5. Fjern server- og leveringsforsinkelse først

Hva: korriger treg opprinnelsesrespons, buffer-bom, omdirigeringer eller fjern levering. Hvorfor: disse årsakene forsinker hvert element og påvirker ofte flere maler. Hvordan: fjern unødvendige omdirigeringer; buffer sikker HTML og data; reduser tregt database- eller API-arbeid; flytt arbeid ut av den kritiske stien; juster CDN-ruting og buffer-nøkler. Aldri buffer private responser uten en godkjent utforming. Verktøy: applikasjonsprofiler, databasespor, CDN-konfigurasjon, responsoverskrifter, overvåking og lasttesting. Ferdig når: gjentatte kalde og varme tester møter budsjettet, buffer-varianter forblir korrekte, feil øker ikke, og prioriterte nettadresser returnerer den tiltenkte responsen uten ekstra hopp.

6. Fiks LCP-oppdagelses-, overførings- og gjengivelsesforsinkelse

Hva: forkort Largest Contentful Paint , når det største synlige bildet eller tekstblokken gjengis. Hvorfor: overstore heltebilder er vanlig, men sen oppdagelse, lav prioritet, blokkerende CSS, JavaScript eller skrifttyper kan dominere. Hvordan: server et korrekt dimensjonert responsivt bilde; ikke lazy-load LCP-ressursen over folden; vis den i innledende HTML; prioriter eller forhåndslast kun med bevis; fjern gjengivelsesblokkering; og bruk undersettede, bufrebare skrifttyper med passende fallback. Verktøy: LCP-nedbrytning, vannfall, bildeinspeksjon, dekningsrapport, spor og visuell sammenligning. Ferdig når: det tiltenkte LCP-elementet er konsistent, den dominerende forsinkelsen faller, representative sider møter budsjettet, og båndbredde, tekstsynlighet og gjengivelse ikke forringes.

7. Fiks INP på den ansvarlige interaksjonen

Hva: reduser interaksjonen som er ansvarlig for dårlig Interaction to Next Paint , responsivitetsmåleparameteren. Hvorfor: sletting av vilkårlig JavaScript treffer kanskje ikke den trege hendelsen. Hvordan: separer inndata-, prosesserings- og presentasjonsforsinkelse; bryt opp lange oppgaver; fjern synkront arbeid; utsett ikke-essensielle tredjeparter; unngå gjentatt layout; reduser nye gjengivelser; og gi etter for maling. Test på realistisk maskinvare med produksjonstredjeparter. Verktøy: interaksjonsspor, hovedtrådprofil, lange oppgaveposter, rammeverksprofiler og realistisk enhet. Ferdig når: kritiske interaksjoner fungerer, den ansvarlige oppgaven møter det gjentatte testbudsjettet, feltproxyen er dokumentert, og analyse-, samtykke-, tastatur- og skjermleseratferd ikke forringes.

8. Fiks CLS ved å reservere den endelige layouten

Hva: forhindre bevegelse som bidrar til Cumulative Layout Shift , skåren for visuell ustabilitet. Hvorfor: bilder, skrifttyper, annonser, bannere, innebygde elementer og asynkrone komponenter kan alle flytte grensesnittet. Hvordan: sett innebygde dimensjoner eller aspect-ratio; reserver plasser for dynamiske moduler; bruk kompatible skrifttype-fallbacks; og animer med transforms. Verktøy: layout-skift-regioner, spor, filmstripe, visuelle regresjonstester og strupet nettleser. Ferdig når: hvert vesentlig skiftklynge har en navngitt kilde, sider møter CLS-budsjettet gjennom lasting og kritiske interaksjoner, og reservert plass skjuler ingen kontroller.

9. Test hele måleparametersettet og beskyttede reiser på nytt

Hva: sammenlign utgivelseskandidaten med den frosne basislinjen under identiske forhold, test deretter i produksjon. Hvorfor: å forbedre én måleparameter kan skade en annen: utsettelse av JavaScript kan forbedre LCP, men forverre den første interaksjonen, mens en aggressiv skrifttypeendring kan forbedre malingstiming, men skape layoutskift. Hvordan: kjør flere kontrollerte prøver, sammenlign en erklært statistikk i stedet for den beste kjøringen, inspiser spor, test beskyttede reiser, verifiser responskorrekthet, og test berørte og kontrollmaler. Verktøy: Lighthouse eller tilsvarende laboratorieverktøy, nettleserens ytelsesverktøy, forespørselsmonitor, visuelle og funksjonelle tester, og utgivelsessjekkliste. Ferdig når: mål-måleparameteren oppfyller laboratoriebudsjettet i henhold til den erklærte metoden for gjentatte kjøringer, TTFB/FCP/LCP/INP/CLS viser ingen kritisk regresjon, beskyttet atferd består, produksjon serverer den tiltenkte endringen, og rollback er ikke utløst.

10. Merk utgivelsen og planlegg feltgjennomgang

Hva: registrer distribusjonstidsstempel, endret omfang, mål-måleparameter, forventet retning og datoer for feltgjennomgang. Hvorfor: CrUX bruker et rullende 28-dagers vindu, så opplevelser før utgivelsen forblir i den rapporterte p75 etter distribusjon. Uten en merknad kan teamet kalle en god rettelse ineffektiv for tidlig, eller tilskrive senere bevegelse til feil utgivelse. Hvordan: fest produksjonsversjonen til funnet, sjekk feil umiddelbart, registrer tidlige feltavlesninger uten å behandle dem som endelige, og planlegg en eier til å gjennomgå et tilstrekkelig oppdatert vindu. Verktøy: distribusjonslogg, issuesporing, CrUX, AmICited Web Vitals og overvåking. Ferdig når: saken er merket Lab-godkjent, utgivelsesmerknaden og umiddelbare bevis er vedlagt, og en navngitt eier og kalenderdato finnes for feltverifisering.

11. Verifiser mot feltdata og lukk eller gjenåpne

Hva: sammenlign tilsvarende p75 feltdata etter at det rullende vinduet er tilstrekkelig oppdatert. Hvorfor: virkelige brukerenheter, nettverk, geografi, bufferatferd, samtykkestatuser og interaksjoner kan ikke representeres av én laboratoriekjøring. Hvordan: bruk samme CrUX-nivå — nettadresse eller domene — samme måleparameter og et sammenlignbart målgruppeomfang; ta hensyn til delvis utrulling og andre utgivelser; inspiser malrepresentanter i stedet for kun å stole på et aggregat på domenenivå. Hvis resultatet bommer, sammenlign gjeldende spor med den opprinnelige årsaksforklaringen og gjenåpne diagnosen i stedet for å stable urelaterte justeringer. Verktøy: AmICited Web Vitals, CrUX-historikk, utgivelsesmerknader, analyse-segmenter og bevispakken. Ferdig når: målet oppfyller den avtalte p75-terskelen og omfanget med begrensninger registrert, hvorpå status blir Feltverifisert; eller saken er eksplisitt gjenåpnet med nye bevis, eier og neste hypotese.

Verktøy i AmICited

Åpne AmICited Web Vitals for å se LCP, INP, CLS, FCP og TTFB fra CrUX for ditt domene og sporede konkurrenter. Bruk det ved diagnose for å fange feltbasislinjen og etter distribusjon for å verifisere det rullende feltresultatet. En tom verdi betyr utilstrekkelige kvalifiserende feltdata, ikke null og ikke bestått. Produktvisningen støtter konklusjonen; spor, servertiming og nettleserprofiler identifiserer fortsatt årsaken.

Bruk Performance Impact for å koble sideytelsesbevis med siteringsposisjon og identifisere verdifulle trege sider. Denne assosiasjonen hjelper med å prioritere utbedring, men beviser ikke at ytelse alene forårsaket et siteringsresultat. Bevar relevans, innhold, autoritet og utgivelseskontekst når du tolker bevegelse.

For produktarbeidsflyten, følg Slik sjekker du Core Web Vitals i AmICited . Veiledningen forklarer hvor måleparameterne vises og hvordan konkurrentsammenligninger fungerer; denne sjekklisten styrer diagnose, implementering og godkjenning.

Beslutningsregler: hvordan dårlig ser ut

Bruk 75. persentil, forkortet p75, for feltbeslutninger: 75 % av kvalifiserte registrerte opplevelser er på eller under den verdien. En grenseverdi tilhører den bedre kategorien. LCP, INP og CLS bestemmer Core Web Vitals-status; TTFB og FCP er støttende målinger som brukes til å sekvensiere og diagnostisere arbeidet.

Bruk disse reglene i rekkefølge:

1. En tidsavbrudd, serverfeil, ukorrekt respons eller brutt kritisk reise blokkerer utgivelse uavhengig av måleverdi.
2. En dårlig TTFB er oppstrøms for LCP og utbedres først. Ikke påstå en kun-bilde-løsning mens serveren allerede har forbrukt mesteparten av gjengivelsesbudsjettet.
3. Dårlige feltmålinger overstyrer trenger-forbedring-målinger. Innenfor én kategori, prioriter delte malårsaker, trafikk og forretningskritiske reiser.
4. En tom feltverdi på nettadressenivå er ukjent. Bruk laboratoriebevis og en dokumentert proxy, men ikke ommerk ukjent som god.
5. Én bestått laboratoriekjøring er utilstrekkelig. Erklær enhets-/nettverksprofilen og metoden for gjentatte kjøringer før testing.
6. En rettelse er Lab-godkjent når distribuert atferd og kontrollerte tester består. Den er Feltverifisert kun etter at sammenlignbare rullende feltdata oppfyller den avtalte terskelen.
7. Hvis data på domenenivå består, men en mal med høy trafikk feiler, vinner malresultatet for det omfanget. Aggregering må ikke viske ut et konsentrert brukerproblem.

Leveranse: utbedrings- og verifiseringspakken

Overlever én sak eller registeroppføring per rotårsak, med underomfang der én årsak påvirker flere maler. Bruk et regneark, issuesporing eller teknisk dokument, men bevar disse feltene:

Funn-ID og primær måleparameter:
Feltkilde: Nettadresse | Domene
Felt p75, kategori og 28-dagers vindu:
Berørte maler og representative nettadresser:
Kontrollmal og nettadresse:
Element, interaksjon, forespørsel eller serverintervall:
Årsaksforklaring og bevislenker:
Laboratorieprofil og basislinje for gjentatte kjøringer:
Mål, sikringer og beskyttede reiser:
Valgt utbedring og forkastede alternativer:
Utviklingseier, godkjennere og avhengigheter:
Utgivelses-/versjons-ID og distribusjonstidsstempel:
Umiddelbare produksjons- og laboratorieresultater:
CrUX feltgjennomgang-eier og dato:
Sammenlignbart feltresultat og begrensninger:
Overvåkingsterskel og gjenåpningsregel:
Status: Åpen | Implementerer | Lab-godkjent | Feltverifisert | Gjenåpnet | Akseptert risiko

Vedlegg spor, vannfall, serverintervaller, skiftregistreringer, interaksjonsprofiler, testresultater og utgivelsesmerknad. Akseptert risiko trenger omfang, årsak, godkjenner, utløpsdato og overvåkingsutløser; det er ikke en bestått.

Pakken er godkjent når en annen ingeniør kan reprodusere det opprinnelige problemet, identifisere hvorfor denne endringen adresserer det, bekrefte hva som nådde produksjon, og gjenta feltsammenligningen uten å spørre den opprinnelige etterforskeren om å rekonstruere arbeidet.

Hva går galt

Optimalisering før isolering av årsaken. Generisk komprimering og skriptsletting erstatter diagnose. Krev bevis på måleparameter-mal-element først.

Komprimering av heltebildet mens opprinnelsen er treg. Et mindre bilde kan ikke gjengis før HTML ankommer. Mål og utbedre TTFB først når det er utenfor budsjett.

Fiksing av feil skift. CLS kan komme fra en annonse, samtykkebanner, skrifttype, innebygd element eller hydrert komponent. Navngi skiftkilden.

Utsettelse av alle skript. Blind utsettelse kan bryte samtykkerekkefølge, analyse, navigasjon, skjemaer eller den første interaksjonen. Endre den ansvarlige utførelsesbanen og regressionstest nødvendig atferd.

Verifisering av én nettadresse etter en utgivelse på delt mal. Det valgte eksempelet kan bestå mens en tyngre innholdsvariant eller en annen komponentkonfigurasjon fortsatt feiler. Test typiske, tunge og kontrollsider.

Lesing av data på domenenivå som en mal-bestått. Friske høyvolum-sider kan skjule en svak kategori-, artikkel- eller produktmal. Hold diagnosen og godkjenningen på det smaleste pålitelige omfanget.

Lukking på distribusjonsdagen. Umiddelbare tester etablerer laboratorie-godkjenning. De erstatter ikke det rullende feltdatavinduet.

Å vente 28 dager før man oppdager en ødelagt utgivelse. Feltbekreftelse tar tid, men statuskoder, feil, reiser, visuell stabilitet og kontrollerte målinger sjekkes umiddelbart. Rullende data er ikke en unnskyldning for å hoppe over utgivelses-QA.

Neste fase: kontinuerlig overvåking og iterasjon

Overlever feltverifiseringsposten, utgivelsesmerknaden, berørte maler, begrensninger og terskler til kontinuerlig oppdatering og iterasjon . Det trenger en stabil basislinje slik at senere innholds-, medie-, mal-, kampanje- og tredjepartsendringer kan sammenlignes i stedet for å gjenoppdages som uforklarlig bevegelse.

Den neste eieren registrerer hvem som overvåker hver terskel, hvor bevisene finnes, hvor ofte det gjennomgås, og hva som gjenåpner utbedring. En ny dårlig måleparameter, gjentatt trenger-forbedring-trend over det fullt oppdaterte vinduet, endret LCP-element, ny treg interaksjon, eller malutgivelse som endrer den diagnostiserte banen, bør gjenåpne sjekklisten ved punkt 1. Ikke automatisk gjenta den forrige rettelsen: samme måleparameter kan feile for et annet element etter en redesign.

Overleveringen er fullført når feltstatus er eksplisitt, hver aksepterte begrensning har en eier og gjennomgangsdato, og overvåking kan koble en regresjon til en mal og utgivelse. Hvis feltverifisering fortsatt er ventende, mottar den neste eieren den planlagte gjennomgangsdatoen, og saken forblir Lab-godkjent, ikke lukket.

FAQ

Ofte stilte spørsmål om utbedring av Core Web Vitals