Tjekliste til udbedring af Core Web Vitals

Tjekliste: Udbedring af Core Web Vitals. Tidsramme: én arbejdsdag til at bekræfte omfang og diagnose; én til ti arbejdsdage til en typisk rettelse og udgivelse, afhængigt af om årsagen sidder i et aktiv, en delt skabelon, et tredjepartsscript, origin eller CDN. Feltverificering følger det rullende 28-dages datavindue og planlægges separat. Ejer: en præstationsingeniør eller senior frontend-ingeniør er ansvarlig. Den tekniske SEO-leder ejer feltacceptkriterierne; platform-, design-, analyse- og produktansvarlige godkender ændringer i deres systemer.

Denne tjekliste forvandler et diagnosticeret præstationsfund til en udgivet, feltverificeret rettelse. Core Web Vitals er Googles målinger af rigtige brugeres oplevelse af indlæsning, responsivitet og visuel 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 understøttende diagnosemålinger. De er inkluderet, fordi en langsom respons eller en tom skærm forbruger den tid, der er til rådighed for at opnå en god LCP.

Hvorfor denne tjekliste, og hvorfor her

Denne tjekliste forbruger udbedringsregistret fra præstations- og Core Web Vitals-gennemgangen . Den tidligere fase identificerer den fejlende metrik, berørt URL og skabelon, baseline for rigtige brugere, gentagelig laboratorietilstand, formodet årsag, prioritet og ejer. Udbedring påbegyndes først, efter at disse felter findes. Ellers bliver en udvikler bedt om at “gøre siden hurtigere” og vil naturligt ændre, hvad et værktøj fremhæver først, uanset om det forårsager feltfejlen.

Diagnose skal indsnævres til tre niveauer før handling: hvilken metrik, hvilken skabelon, og hvilket element eller hvilken opgave. En TTFB-fejl på origins-niveau kræver en platformrettelse; LCP der kun fejler på artikelsider kan komme fra deres hero-komponent; INP efter åbning af et produktfilter kan komme fra én event handler; CLS på kampagnesider kan komme fra et banner uden reserveret plads. At behandle disse som ét problem skaber brede ændringer og uklar ejerskab.

Rækkefølge betyder noget i rettelsen. TTFB er upstream: indtil den første responsbyte ankommer, kan browseren ikke opdage normale HTML-ressourcer eller male sideindhold. Hvis TTFB er dårlig, rettér da responsgenerering, caching, omdirigeringer og edge-levering før komprimering af LCP-billedet. Når responstiden er inden for budgettet, arbejd dig fremad gennem ressourceopdagelse, ressource-download, gengivelse, interaktioner og layoutstabilitet.

At springe denne tjekliste over efterlader gennemgangen som en rapport. At køre den før diagnosen inviterer til symptomjagt: komprimering af et billede når sen opdagelse dominerer, eller udsættelse af scripts når origin er langsom.

Inputs og outputs

Outputs gør det muligt for en fremtidig ejer at reproducere fejlen, identificere hvad der blev sendt, og skelne laboratorieaccept fra feltbekræftelse.

Tjeklisten

Gennemfør punkterne 1–4 før ændring af produktion. Punkterne 5–8 implementerer den afhængighedsordnede rettelse. Punkterne 9–11 adskiller umiddelbar udgivelsesaccept fra feltverificering.

1. Fastlås den fejlende metrik, skabelon og element

Hvad: reducér fundet til én metrik, berørt skabelonsæt og navngivet element, anmodning, opgave eller serverspænd. Hvorfor: en score på tværs af hele siden identificerer ikke udførbart arbejde, og to URL’er kan fejle af forskellige årsager. Hvordan: sammenhold p75-fejlen med spor og sammenlign berørte og upåvirkede skabeloner; navngiv LCP-elementet og forsinkelsen, INP-interaktionen og opgaven, CLS-elementet og udløseren, eller TTFB-anmodningsstien og cache-tilstanden. Værktøj: CrUX-dokumentation, browserspor, waterfall, server-timing, skabeloninventar og problemsporer. Udført når: dokumentation understøtter “metrik X fejler på skabelon Y fordi Z skaber forsinkelse eller bevægelse under betingelse C.”

2. Bekræft omfang med repræsentative sider

Hvad: test fundet på en typisk og en værste-fald URL for hver impliceret skabelon, plus en upåvirket kontrolside. Hvorfor: en rettelse på én side kan skjule en delt fejl, mens en global ændring kan være unødvendig når én indholdsvariant forårsager problemet. Hvordan: hold enhed, netværk, lokation, samtykke, login og cache-forhold konstante; sammenlign komponentbrug, aktivvægt, respons-timing, tredjepartsaktivitet og indholdslængde. Værktøj: analyse, skabeloninventar, browserpræstationsværktøjer, anmodningsmonitor og en testmatrix. Udført når: hver skabelon inden for omfanget er markeret som berørt eller kontrol, hver har reproducerbar dokumentation, og udgivelsesomfanget navngiver den komponent, rute, aktivfamilie eller platformslag, der skal ændres.

3. Sæt budget og beskyt påkrævet adfærd

Hvad: definér det numeriske mål, regressionssikringer og funktioner der skal overleve. Hvorfor: “hurtigere” har ingen acceptgrænse, og sletning af en samtykkehåndtering, analysetag, tilgængelighedsfokuseringsadfærd eller produktfunktion kan skabe en misvisende beståelse. Hvordan: sæt målet ud fra beslutningstabellen nedenfor, tilføj en strengere intern buffer hvor gentagne tests varierer, og liste kritiske brugerrejser og ikke-mål-metrikker der skal gentestes. Værktøj: fundregister, produktkrav, analyseplan, tilgængelighedstjek og præstationsbudget. Udført når: sagen angiver målmetrik og -værdi, laboratorieacceptmetode, feltacceptmetode, beskyttet adfærd, tilladte afvejninger, rollback-betingelse og navngivne godkendere.

4. Tjek TTFB før frontend-arbejde

Hvad: mål TTFB under kolde og varme cache-forhold fra målgrupperelevante lokationer. Hvorfor: TTFB er inkluderet i hver efterfølgende malingstid; frontend-arbejde kan ikke genvinde tid der allerede er brugt på at vente på HTML. Hvordan: opdel anmodningen i DNS, forbindelse, omdirigeringer, CDN-ventetid, origin-beregning, database- eller upstream API-tid og streaming-adfærd hvor instrumentering tillader det. Sammenlign cache-hit og cache-miss-svar, og bekræft at personalisering eller cookies ikke deaktiverer caching uventet. Værktøj: anmodnings-waterfall, server-timing, CDN- og origin-logfiler, applikationsprofilering og syntetisk anmodningsovervågning. Udført når: TTFB er inden for det aftalte budget, eller et separat blokerende platformsfund er ejet og planlagt. Påbegynd ikke LCP-polering mens en dårlig TTFB forbliver uforklaret.

5. Fjern server- og leveringsforsinkelse først

Hvad: korrigér langsom origin-respons, cache-miss, omdirigeringer eller fjern levering. Hvorfor: disse årsager forsinker hvert element og påvirker ofte flere skabeloner. Hvordan: fjern undgåelige omdirigeringer; cache sikker HTML og data; reducér langsom database- eller API-indsats; flyt arbejde væk fra den kritiske sti; justér CDN-routing og cache-nøgler. Cache aldrig private svar uden en godkendt design. Værktøj: applikationsprofilering, forespørgselsspor, CDN-konfiguration, responsoverskrifter, overvågning og belastningstest. Udført når: gentagne kolde og varme tests opfylder budgettet, cache-varianter forbliver korrekte, fejl forværres ikke, og prioritets-URL’er returnerer det tilsigtede svar uden ekstra hop.

6. Ret LCP-opdagelses-, overførsels- og gengivelsesforsinkelse

Hvad: forkort Largest Contentful Paint , når det største synlige billede eller tekstblok gengives. Hvorfor: overdimensionerede hero-elementer er almindelige, men sen opdagelse, lav prioritet, blokerende CSS, JavaScript eller skrifttyper kan dominere. Hvordan: tjen et korrekt dimensioneret responsivt billede; lazy-load ikke LCP-aktivet over folden; eksponér det i den indledende HTML; prioritér eller forudindlæs kun med dokumentation; fjern renderingsblokering; og brug undersæt-opdelte, cachebare skrifttyper med en passende reserve. Værktøj: LCP-opdeling, waterfall, billedinspektion, dækningsrapport, spor og visuel sammenligning. Udført når: det tilsigtede LCP-element er konsistent, dens dominerende forsinkelse falder, repræsentative sider opfylder budgettet, og båndbredde, tekstsynlighed og gengivelse forværres ikke.

7. Ret INP ved den ansvarlige interaktion

Hvad: reducér den interaktion, der er ansvarlig for dårlig Interaction to Next Paint , responsivitetsmålingen. Hvorfor: sletning af vilkårlig JavaScript rører måske ikke den langsomme hændelse. Hvordan: adskil input-, behandlings- og præsentationsforsinkelse; bryd lange opgaver; fjern synkront arbejde; udskyd ikke-essentielle tredjeparter; undgå gentaget layout; reducér gengengivelser; og giv slip til maling. Test på realistisk hardware med produktionstredjeparter. Værktøj: interaktionsspor, main-thread-profil, lange opgaveposter, framework-profiler og realistisk enhed. Udført når: kritiske interaktioner virker, den ansvarlige opgave opfylder budgettet for gentagne tests, feltproxyen er dokumenteret, og analyse-, samtykke-, tastatur- og skærmlæseradfærd forværres ikke.

8. Ret CLS ved at reservere det endelige layout

Hvad: forhindr bevægelse, der bidrager til Cumulative Layout Shift , scoren for visuel ustabilitet. Hvorfor: billeder, skrifttyper, annoncer, bannere, indlejringer og asynkrone komponenter kan alle flytte grænsefladen. Hvordan: sæt indre dimensioner eller aspect-ratio; reserver plads til dynamiske moduler; brug kompatible skrifttypereserver; og animér med transforms. Værktøj: layout-skift-regioner, spor, filmstrimmel, visuelle regressionstest og throttlet browser. Udført når: hvert væsentligt skiftklynge har en navngiven kilde, sider opfylder CLS-budgettet under indlæsning og kritiske interaktioner, og reserveret plads skjuler ingen kontrolelementer.

9. Gentest hele metriksættet og beskyttede brugerrejser

Hvad: sammenlign udgivelseskandidaten med den frosne baseline under identiske forhold, test derefter i produktion. Hvorfor: forbedring af én metrik kan skade en anden: udsættelse af JavaScript kan forbedre LCP men forværre den første interaktion, mens en aggressiv skrifttypeændring kan forbedre malingstidspunktet men skabe layoutskift. Hvordan: kør flere kontrollerede stikprøver, sammenlign en erklæret statistik frem for den bedste kørsel, inspicér spor, gennemgå beskyttede brugerrejser, verificér respons-korrekthed, og test berørte og kontrolskabeloner. Værktøj: Lighthouse eller tilsvarende laboratoriekører, browserpræstationsværktøjer, anmodningsmonitor, visuelle og funktionelle tests og udgivelsestjekliste. Udført når: målmetrikken opfylder sit laboratoriebudget på tværs af den erklærede gentagne kørselsmetode, TTFB/FCP/LCP/INP/CLS viser ingen kritisk regression, beskyttet adfærd består, produktion serverer den tilsigtede ændring, og rollback er ikke udløst.

10. Annotér udgivelsen og planlæg feltgennemgang

Hvad: registrér implementeringstidsstemplet, ændret omfang, målmetrik, forventet retning og datoer for feltgennemgang. Hvorfor: CrUX bruger et rullende 28-dages vindue, så oplevelser før udgivelse forbliver i den rapporterede p75 efter implementering. Uden en annotation kan teamet kalde en god rettelse ineffektiv for tidligt eller tilskrive senere bevægelse til den forkerte udgivelse. Hvordan: vedhæft produktionsversionen til fundet, tjek fejl umiddelbart, registrér tidlige feltaflæsninger uden at behandle dem som endelige, og planlæg en ejer til at gennemgå et tilstrækkeligt opfrisket vindue. Værktøj: implementeringslog, problemsporer, CrUX, AmICited Web Vitals og overvågning. Udført når: sagen er markeret som Laboratorieaccepteret, udgivelsesannotationen og umiddelbar dokumentation er vedhæftet, og en navngiven ejer og kalenderdato findes for feltverificering.

11. Verificér mod feltdata og luk eller genåbn

Hvad: sammenlign sammenlignelige p75-feltdata efter at det rullende vindue er tilstrækkeligt opfrisket. Hvorfor: rigtige brugeres enheder, netværk, geografi, cache-adfærd, samtykketilstande og interaktioner kan ikke repræsenteres af én laboratoriekørsel. Hvordan: brug samme CrUX-niveau — URL eller origin — samme metrik og et sammenligneligt målgruppeomfang; tag højde for delvis udrulning og andre udgivelser; inspicér skabelonrepræsentanter frem for kun at stole på et origins-aggregat. Hvis resultatet misser, sammenlign det aktuelle spor med den oprindelige årsagsforklaring og genåbn diagnosen i stedet for at stable urelaterede justeringer. Værktøj: AmICited Web Vitals, CrUX-historie, udgivelsesannotationer, analysesegmenter og dokumentationspakken. Udført når: målet opfylder den aftalte p75-tærskel og -omfang med registrerede begrænsninger, på hvilket tidspunkt status bliver Feltverificeret; eller sagen er udtrykkeligt genåbnet med ny dokumentation, ejer og næste hypotese.

Værktøjer i AmICited

Åbn AmICited Web Vitals for at se LCP, INP, CLS, FCP og TTFB fra CrUX for dit domæne og sporede konkurrenter. Brug det ved diagnose til at indfange feltbaseline og efter implementering til at verificere det rullende feltresultat. En blank værdi betyder utilstrækkelige kvalificerede feltdata, ikke nul og ikke en beståelse. Produktvisningen understøtter vurderingen; spor, server-timing og browserprofiler identificerer stadig årsagen.

Brug Performance Impact til at forbinde præstationsdokumentation på sideniveau med citationsposition og identificere værdifulde langsomme sider. Denne association hjælper med at prioritere udbedring, men beviser ikke at præstation alene forårsagede et citationsresultat. Bevar relevans, indhold, autoritet og udgivelseskontekst ved fortolkning af bevægelser.

For produktarbejdsgangen, følg Sådan tjekker du dine Core Web Vitals i AmICited . Vejledningen forklarer, hvor metrikkerne vises, og hvordan konkurrentsammenligninger fungerer; denne tjekliste styrer diagnose, implementering og accept.

Beslutningsregler: hvad dårligt ser ud

Brug 75. percentil, forkortet p75, til feltbeslutninger: 75% af kvalificerede registrerede oplevelser er på eller under den værdi. En grænseværdi tilhører den bedre kategori. LCP, INP og CLS bestemmer Core Web Vitals-status; TTFB og FCP er understøttende målinger, der bruges til at sekvensere og diagnosticere arbejdet.

Anvend disse regler i rækkefølge:

1. En timeout, serverfejl, forkert respons eller brudt kritisk brugerrejse blokerer udgivelse uanset metrikscore.
2. En dårlig TTFB er upstream af LCP og udbedres først. Hævd ikke en billede-only løsning mens serveren allerede har forbrugt det meste af malingsbudgettet.
3. Dårlige feltmetrikker overtrumfer metrikker med behov for forbedring. Inden for én kategori, prioritér delte skabelonårsager, trafik og forretningskritiske brugerrejser.
4. En blank feltværdi på URL-niveau er ukendt. Brug laboratoriedokumentation og en dokumenteret proxy, men omdøb ikke ukendt til godt.
5. Én bestået laboratoriekørsel er utilstrækkelig. Erklær enheds-/netværksprofilen og metoden for gentagne kørsler før test.
6. En rettelse er Laboratorieaccepteret når implementeret adfærd og kontrollerede tests består. Den er Feltverificeret kun efter at sammenlignelige rullende feltdata opfylder den aftalte tærskel.
7. Hvis origins-data består men en skabelon med høj trafik fejler, vinder skabelonresultatet for det omfang. Aggregering må ikke slette et koncentreret brugerproblem.

Leverance: udbedrings- og verifikationspakken

Overgiv én sag eller registerpost pr. rodårsag, med delomfang hvor en årsag påvirker flere skabeloner. Brug et regneark, problemsporer eller ingeniørdokument, men bevar disse felter:

Fund-ID og primær metrik:
Feltkilde: URL | Origin
Felt-p75, kategori og 28-dages vindue:
Berørte skabeloner og repræsentative URL'er:
Kontrolskabelon og URL:
Element, interaktion, anmodning eller serverspænd:
Årsagsforklaring og dokumentationslinks:
Laboratorieprofil og baseline for gentagne kørsler:
Mål, sikringer og beskyttede brugerrejser:
Valgt udbedring og forkastede alternativer:
Ingeniørejer, godkendere og afhængigheder:
Udgivelses-/versions-ID og implementeringstidsstempel:
Umiddelbare produktions- og laboratorieresultater:
CrUX-feltgennemgangsejer og -dato:
Sammenligneligt feltresultat og begrænsninger:
Overvågningstærskel og genåbningsregel:
Status: Åben | Implementering | Laboratorieaccepteret | Feltverificeret | Genåbnet | Accepteret risiko

Vedhæft spor, waterfalls, serverspænd, skiftoptagelser, interaktionsprofiler, testoutput og udgivelsesannotation. Accepteret risiko kræver omfang, begrundelse, godkender, udløbsdato og overvågningsudløser; det er ikke en beståelse.

Pakken er accepteret, når en anden ingeniør kan reproducere det oprindelige problem, identificere hvorfor denne ændring adresserer det, bekræfte hvad der nåede produktion, og gentage feltsammenligningen uden at bede den oprindelige efterforsker om at rekonstruere arbejdet.

Hvad går galt

Optimering før isolering af årsagen. Generisk komprimering og scriptsletning erstatter diagnose. Kræv metrik-skabelon-element-dokumentation først.

Komprimering af hero mens origin er langsom. Et mindre billede kan ikke gengives før HTML ankommer. Mål og udbedr TTFB først når det er uden for budgettet.

Rettelse af det forkerte skift. CLS kan komme fra en annonce, samtykkebanner, skrifttype, indlejring eller hydreret komponent. Navngiv skiftkilden.

Udsættelse af alle scripts. Uovervejet udsættelse kan bryde samtykke-rækkefølge, analyse, navigation, formularer eller den første interaktion. Ændr den ansvarlige eksekveringssti og regressionstest påkrævet adfærd.

Verificering af én URL efter en udgivelse på en delt skabelon. Det valgte eksempel kan bestå mens en tungere indholdsvariant eller en anden komponentkonfiguration stadig fejler. Test typiske, tunge og kontrolsider.

Aflæsning af origins-niveaudata som en skabelonbeståelse. Sunde sider med høj volumen kan maskere en svag kategori-, artikel- eller produkt-skabelon. Hold diagnose og accept på det snævrest mulige pålidelige omfang.

Lukning på implementeringsdagen. Umiddelbare tests etablerer laboratorieaccept. De erstatter ikke det rullende feltdatavindue.

Vent 28 dage på at opdage en brudt udgivelse. Feltbekræftelse tager tid, men statuskoder, fejl, brugerrejser, visuel stabilitet og kontrollerede metrikker tjekkes umiddelbart. Rullende data er ikke en undskyldning for at springe udgivelses-QA over.

Næste fase: kontinuerlig overvågning og iteration

Overgiv feltverificeringsposten, udgivelsesannotationen, berørte skabeloner, begrænsninger og tærskler til kontinuerlig opdatering og iteration . Den har brug for en stabil baseline, så senere indholds-, medie-, skabelon-, kampagne- og tredjepartsændringer kan sammenlignes frem for at blive genopdaget som uforklaret bevægelse.

Den næste ejer registrerer, hvem der overvåger hver tærskel, hvor dokumentationen bor, hvor ofte den gennemgås, og hvad der genåbner udbedring. En ny dårlig metrik, gentagen tendens til behov for forbedring på tværs af det fuldt opfriskede vindue, ændret LCP-element, ny langsom interaktion eller skabelonudgivelse der ændrer den diagnosticerede sti, bør genåbne tjeklisten ved punkt 1. Gentag ikke automatisk den forrige rettelse: den samme metrik kan fejle for et andet element efter et redesign.

Overdragelsen er komplet når feltstatus er eksplicit, enhver accepteret begrænsning har en ejer og gennemgangsdato, og overvågning kan forbinde en regression til en skabelon og udgivelse. Hvis feltverificering stadig er afventende, modtager den næste ejer den planlagte gennemgangsdato, og sagen forbliver Laboratorieaccepteret, ikke lukket.

FAQ

FAQ om udbedring af Core Web Vitals