Checklista för åtgärdande av Core Web Vitals

Checklista: Åtgärdande av Core Web Vitals. Tidsram: en arbetsdag för att bekräfta omfattning och diagnos; en till tio arbetsdagar för en typisk åtgärd och lansering, beroende på om orsaken finns i en tillgång, delad mall, tredjepartsskript, ursprung eller CDN. Fältverifiering följer det rullande 28-dagarsfönstret och schemaläggs separat. Ansvarig: en prestandaingenjör eller senior frontend-ingenjör är ansvarig. Den tekniska SEO-ansvarige äger fältgodkännandekriterierna; plattforms-, design-, analys- och produktägare godkänner ändringar i sina system.

Denna checklista förvandlar ett diagnostiserat prestandafynd till en lanserad, fältverifierad åtgärd. Core Web Vitals är Googles mått för verkliga användares upplevelse av laddning, responsivitet och visuell stabilitet: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) och Cumulative Layout Shift (CLS). Time to First Byte (TTFB) och First Contentful Paint (FCP) är stödjande diagnosmått. De ingår eftersom ett långsamt svar eller en tom skärm förbrukar den tid som finns tillgänglig för att uppnå ett bra LCP.

Varför denna checklista, och varför här

Denna checklista använder åtgärdsregistret från prestanda- och Core Web Vitals-granskningen . Den tidigare fasen identifierar det misslyckade måttet, påverkad webbadress och mall, verklig användarbaslinje, repeterbart labbvillkor, misstänkt orsak, prioritet och ägare. Åtgärder påbörjas först efter att dessa fält finns. Annars ombeds en utvecklare att “göra sidan snabbare” och kommer naturligtvis att ändra vad ett verktyg än lyfter fram först, oavsett om det orsakar fältfelet eller inte.

Diagnos måste begränsas till tre nivåer före åtgärd: vilket mått, vilken mall och vilket element eller vilken uppgift. Ett TTFB-problem på originsnivå kräver en plattformsåtgärd; LCP som bara misslyckas på artikelsidor kan komma från deras hero-komponent; INP efter att ha öppnat ett produktfilter kan komma från en enskild händelsehanterare; CLS på kampanjsidor kan komma från en ej reserverad banner. Att behandla dessa som ett problem leder till breda ändringar och otydligt ägande.

Ordningen spelar roll inom åtgärden. TTFB är överordnat: tills den första svarsbyten anländer kan webbläsaren inte upptäcka normala HTML-resurser eller rendera sidinnehåll. Om TTFB är dåligt, åtgärda svarsskapande, cachelagring, omdirigeringar och edge-leverans innan du komprimerar LCP-bilden. När svarstiden ligger inom budget, arbeta dig framåt genom resursupptäckt, resursnedladdning, rendering, interaktioner och layoutstabilitet.

Att hoppa över denna checklista lämnar granskningen som en rapport. Att köra den före diagnos inbjuder till symptomjakt: komprimera en bild när sen upptäckt dominerar eller skjuta upp skript när ursprunget är långsamt.

Indata och utdata

Utdatan gör det möjligt för en framtida ägare att återskapa felet, identifiera vad som levererades och skilja labbgodkännande från fältbekräftelse.

Checklistan

Genomför punkterna 1–4 innan du ändrar i produktion. Punkterna 5–8 implementerar den beroendeordnade åtgärden. Punkterna 9–11 separerar omedelbart lanseringsgodkännande från fältverifiering.

1. Lås fast det misslyckade måttet, mallen och elementet

Vad: reducera fyndet till ett mått, en uppsättning påverkade mallar och ett namngivet element, begäran, uppgift eller serverintervall. Varför: en webbplatsövergripande poäng identifierar inte konkret arbete, och två webbadresser kan misslyckas av olika anledningar. Hur: koppla samman p75-felet med spårningar och jämför påverkade och opåverkade mallar; namnge LCP-elementet och fördröjningen, INP-interaktionen och uppgiften, CLS-elementet och utlösaren, eller TTFB-begäransökvägen och cache-status. Verktyg: CrUX-bevis, webbläsarspårning, vattenfall, servertider, mallinventering och ärendehanterare. Klart när: bevis stöder “mått X misslyckas på mall Y eftersom Z skapar fördröjning eller rörelse under villkor C.”

2. Bekräfta omfattning med representativa sidor

Vad: testa fyndet på en typisk och en värsta webbadress för varje berörd mall, plus en opåverkad kontroll. Varför: en åtgärd på en sida kan dölja ett delat problem, medan en global ändring kan vara onödig när en innehållsvariant orsakar problemet. Hur: håll enhet, nätverk, plats, samtycke, inloggning och cachelagring konstanta; jämför komponentanvändning, tillgångsvikt, svarstid, tredjepartsaktivitet och innehållslängd. Verktyg: analys, mallinventering, webbläsarens prestandaverktyg, förfrågningsövervakare och en testmatris. Klart när: varje mall inom omfattningen är markerad som påverkad eller kontroll, var och en har repeterbara bevis och lanseringsomfattningen namnger den komponent, rutt, tillgångsfamilj eller plattform som måste ändras.

3. Sätt budgeten och skydda nödvändigt beteende

Vad: definiera det numeriska målet, regressionens skyddsräcken och funktioner som måste överleva. Varför: “snabbare” har ingen godkännandegräns, och att ta bort en samtyckeshanterare, analys-tagg, tillgänglighetsfokus eller produktfunktion kan skapa ett missvisande godkännande. Hur: sätt målet från beslutstabellen nedan, lägg till en striktare intern buffert där upprepade tester varierar, och lista kritiska användarresor och icke-målmått att testa om. Verktyg: fyndregister, produktkrav, analysplan, tillgänglighetskontroller och prestandabudget. Klart när: ärendet anger målmått och värde, labb-acceptansmetod, fält-acceptansmetod, skyddade beteenden, tillåtna avvägningar, rollback-villkor och namngivna godkännare.

4. Kontrollera TTFB före frontend-arbete

Vad: mät TTFB under kalla och varma cacheförhållanden från publikrelevanta platser. Varför: TTFB ingår i varje efterföljande målnings-tid; frontend-arbete kan inte återhämta tid som redan spenderats på att vänta på HTML. Hur: dela upp begäran i DNS, anslutning, omdirigeringar, CDN-väntetid, origin-beräkning, databas- eller uppströms-API-tid och strömmande beteende där instrumentering tillåter. Jämför cache-träff och cache-miss-svar och bekräfta att anpassning eller cookies inte inaktiverar cachelagring oväntat. Verktyg: begärans vattenfall, servertider, CDN- och origin-loggar, applikationsprofilering och syntetisk begäranövervakning. Klart när: TTFB ligger inom den överenskomna budgeten eller ett separat blockerande plattformsfynd är ägt och schemalagt. Påbörja inte LCP-förfining medan ett dåligt TTFB är oförklarat.

5. Ta bort server- och leveransfördröjning först

Vad: korrigera långsam origin-respons, cache-missar, omdirigeringar eller avlägsen leverans. Varför: dessa orsaker fördröjer varje element och påverkar ofta flera mallar. Hur: ta bort undvikbara omdirigeringar; cachelagra säker HTML och data; minska långsam databas- eller API-belastning; flytta arbete bort från den kritiska sökvägen; justera CDN-routning och cachenycklar. Cachelagra aldrig privata svar utan en godkänd design. Verktyg: applikationsprofilerare, frågespårningar, CDN-konfiguration, svarshuvuden, övervakning och belastningstestning. Klart när: upprepade kalla och varma tester möter budget, cache-varianter förblir korrekta, fel uppstår inte och prioriterade webbadresser returnerar det avsedda svaret utan extra hopp.

6. Åtgärda LCP-upptäckts-, överförings- och renderingsfördröjning

Vad: förkorta Largest Contentful Paint , när det största synliga bild- eller textblocket renderas. Varför: överdimensionerade hjältar är vanliga, men sen upptäckt, låg prioritet, blockerande CSS, JavaScript eller typsnitt kan dominera. Hur: servera en korrekt storleksanpassad responsiv bild; lazy-ladda inte LCP-tillgången ovanför vecket; exponera den i initial HTML; prioritera eller förladda endast med bevis; ta bort renderingsblockering; och använd trunkerade, cachelagringsbara typsnitt med lämplig reserv. Verktyg: LCP-nedbrytning, vattenfall, bildinspektion, täckningsrapport, spårning och visuell jämförelse. Klart när: det avsedda LCP-elementet är konsekvent, dess dominerande fördröjning minskar, representativa sidor möter budget och bandbredd, textsynlighet och rendering inte försämras.

7. Åtgärda INP vid den ansvariga interaktionen

Vad: minska interaktionen som orsakar dålig Interaction to Next Paint , responsivitetsmåttet. Varför: att ta bort godtycklig JavaScript kanske inte påverkar den långsamma händelsen. Hur: separera inmatnings-, bearbetnings- och presentationsfördröjning; bryt långa uppgifter; ta bort synkront arbete; skjut upp icke-nödvändiga tredjeparter; undvik upprepad layout; minska omrenderingar; och lämna utrymme för målning. Testa på realistisk hårdvara med produktions-tredjeparter. Verktyg: interaktionsspårning, huvudtrådsprofil, långa uppgiftsposter, ramverksprofilerare och realistisk enhet. Klart när: kritiska interaktioner fungerar, den ansvariga uppgiften möter det upprepade testets budget, fältproxy är dokumenterad och analys-, samtyckes-, tangentbords- och skärmläsarbeteende inte försämras.

8. Åtgärda CLS genom att reservera den slutliga layouten

Vad: förhindra rörelse som bidrar till Cumulative Layout Shift , poängen för visuell instabilitet. Varför: bilder, typsnitt, annonser, banners, inbäddningar och asynkrona komponenter kan alla förskjuta gränssnittet. Hur: sätt inneboende dimensioner eller aspect-ratio; reservera platser för dynamiska moduler; använd kompatibla typsnittsreserver; och animera med transformationer. Verktyg: layoutförskjutningsområden, spårning, filmremsa, visuella regressionstester och strypt webbläsare. Klart när: varje materiell förskjutningskluster har en namngiven källa, sidor möter CLS-budgeten genom laddning och kritiska interaktioner, och reserverat utrymme döljer ingen kontroll.

9. Testa om hela måttuppsättningen och skyddade användarresor

Vad: jämför lanseringskandidaten med den frusna baslinjen under identiska förhållanden, testa sedan i produktion. Varför: att förbättra ett mått kan skada ett annat: att skjuta upp JavaScript kan förbättra LCP men försämra den första interaktionen, medan en aggressiv typsnittsändring kan förbättra målnings-tiden men skapa layoutförskjutning. Hur: kör flera kontrollerade prover, jämför en deklarerad statistik snarare än den bästa körningen, inspektera spårningar, testa skyddade användarresor, verifiera svarskorrekthet och testa påverkade och kontrollmallar. Verktyg: Lighthouse eller motsvarande labbkörning, webbläsarens prestandaverktyg, förfrågningsövervakare, visuella och funktionella tester och lanseringschecklista. Klart när: målmåttet möter sin labbbudget enligt den deklarerade metoden för upprepade körningar, TTFB/FCP/LCP/INP/CLS visar ingen kritisk regression, skyddat beteende fungerar, produktion levererar den avsedda ändringen och rollback utlöses inte.

10. Anteckna lanseringen och schemalägg fältgranskning

Vad: registrera lanseringstidsstämpel, ändrad omfattning, målmått, förväntad riktning och datum för fältgranskning. Varför: CrUX använder ett rullande 28-dagarsfönster, så upplevelser före lansering finns kvar i den rapporterade p75 efter lansering. Utan en anteckning kan teamet avfärda en bra åtgärd som ineffektiv för tidigt eller tillskriva senare rörelse till fel lansering. Hur: bifoga produktionsversionen till fyndet, kontrollera fel omedelbart, registrera tidiga fältavläsningar utan att behandla dem som slutgiltiga och schemalägg en ägare att granska ett tillräckligt uppdaterat fönster. Verktyg: lanseringslogg, ärendehanterare, CrUX, AmICited Web Vitals och övervakning. Klart när: ärendet är markerat som Lab accepterat, lanseringsanteckningen och omedelbara bevis är bifogade, och en namngiven ägare och kalenderdatum finns för fältverifiering.

11. Verifiera mot fältdata och stäng eller återöppna

Vad: jämför likvärdig p75-fältdata efter att det rullande fönstret har uppdaterats tillräckligt. Varför: verkliga användares enheter, nätverk, geografi, cachebeteende, samtyckesstatus och interaktioner kan inte representeras av en enda labbkörning. Hur: använd samma CrUX-nivå—webbadress eller origin—samma mått och en jämförbar publikomfattning; ta hänsyn till partiell utrullning och andra lanseringar; inspektera mallrepresentanter istället för att endast förlita sig på en origin-aggregat. Om resultatet missar, jämför den aktuella spårningen med den ursprungliga orsaksbeskrivningen och återöppna diagnosen istället för att stapla orelaterade justeringar. Verktyg: AmICited Web Vitals, CrUX-historik, lanseringsanteckningar, analyssegment och bevispaketet. Klart när: målet uppfyller det överenskomna p75-tröskelvärdet och omfattningen med begränsningar dokumenterade, varpå status blir Fältverifierat; eller ärendet uttryckligen återöppnas med nya bevis, ägare och nästa hypotes.

Verktyg i AmICited

Öppna AmICited Web Vitals för att se LCP, INP, CLS, FCP och TTFB från CrUX för din domän och spårade konkurrenter. Använd det vid diagnos för att fånga fältbaslinjen och efter lansering för att verifiera det rullande fältresultatet. Ett tomt värde betyder otillräcklig kvalificerad fältdata, inte noll och inte godkänt. Produktvyn stöder slutsatsen; spårningar, servertider och webbläsarprofiler identifierar fortfarande orsaken.

Använd Performance Impact för att koppla sidnivåns prestandabevis med citeringsposition och identifiera värdefulla långsamma sidor. Den associationen hjälper till att prioritera åtgärder men bevisar inte att enbart prestanda orsakade ett citeringsresultat. Bevara relevans, innehåll, auktoritet och lanseringskontext när du tolkar rörelse.

För produktarbetsflödet, följ Hur du kontrollerar dina Core Web Vitals i AmICited . Handledningen förklarar var måtten visas och hur konkurrentjämförelser fungerar; denna checklista styr diagnos, implementering och godkännande.

Beslutsregler: vad dåligt innebär

Använd den 75:e percentilen, förkortat p75, för fältbeslut: 75 % av kvalificerade inspelade upplevelser ligger vid eller under det värdet. Ett gränsvärde tillhör den bättre kategorin. LCP, INP och CLS avgör Core Web Vitals-status; TTFB och FCP är stödjande mått som används för att sekvensera och diagnostisera arbetet.

Tillämpa dessa regler i ordning:

1. En timeout, serverfel, felaktigt svar eller bruten kritisk användarresa blockerar lansering oavsett måttpoäng.
2. Ett dåligt TTFB är överordnat LCP och åtgärdas först. Påstå inte en bild-enda-lösning medan servern redan har förbrukat större delen av målningsbudgeten.
3. Dåliga fältmått väger tyngre än mått som behöver förbättras. Inom samma kategori, prioritera delade mallorsaker, trafik och affärskritiska användarresor.
4. Ett tomt fältvärde på webbadressnivå är okänt. Använd labbbevis och en dokumenterad proxy, men omklassificera inte okänt som bra.
5. En enskild godkänd labbkörning är otillräcklig. Deklarera enhets-/nätverksprofil och metod för upprepade körningar innan testning.
6. En åtgärd är Lab accepterad när lanserat beteende och kontrollerade tester är godkända. Den är Fältverifierad först efter att jämförbar rullande fältdata uppfyller det överenskomna tröskelvärdet.
7. Om origin-data godkänns men en högtrafikerad mall misslyckas, vinner mallresultatet för den omfattningen. Aggregering får inte radera ett koncentrerat användarproblem.

Leverans: åtgärds- och verifieringspaketet

Överlämna ett ärende eller registerpost per grundorsak, med underordnade omfattningar där en orsak påverkar flera mallar. Använd ett kalkylark, ärendehanterare eller teknisk dokumentation, men bevara dessa fält:

Fynd-ID och primärt mått:
Fältkälla: Webbadress | Origin
Fält p75, kategori och 28-dagarsfönster:
Påverkade mallar och representativa webbadresser:
Kontrollmall och webbadress:
Element, interaktion, begäran eller serverintervall:
Orsaksbeskrivning och bevislänkar:
Labprofil och baslinje från upprepade körningar:
Mål, skyddsräcken och skyddade användarresor:
Vald åtgärd och förkastade alternativ:
Teknisk ägare, godkännare och beroenden:
Lanserings-/versions-ID och lanseringstidsstämpel:
Omedelbara produktions- och labbresultat:
CrUX-fältgranskningsägare och datum:
Jämförbart fältresultat och begränsningar:
Övervakningströskel och återöppningsregel:
Status: Öppen | Implementerar | Lab accepterad | Fältverifierad | Återöppnad | Accepterad risk

Bifoga spårningar, vattenfall, serverintervall, förskjutningsinspelningar, interaktionsprofiler, testutdata och lanseringsanteckning. Accepterad risk kräver omfattning, anledning, godkännare, utgångsdatum och övervakningsutlösare; det är inte ett godkännande.

Paketet är accepterat när en annan ingenjör kan återskapa det ursprungliga problemet, identifiera varför denna ändring åtgärdar det, bekräfta vad som nådde produktion och upprepa fältjämförelsen utan att behöva fråga den ursprungliga utredaren att rekonstruera arbetet.

Vad kan gå fel

Optimera innan orsaken isolerats. Generisk komprimering och borttagning av skript ersätter diagnos. Kräv bevis på mått-mall-element först.

Komprimera hjältebilden medan ursprunget är långsamt. En mindre bild kan inte renderas innan HTML anländer. Mät och åtgärda TTFB först när det ligger utanför budget.

Åtgärda fel förskjutning. CLS kan komma från en annons, samtyckesbanner, typsnitt, inbäddning eller hydrerad komponent. Namnge förskjutningskällan.

Skjuta upp vartenda skript. Urskillningslöst uppskjutande kan bryta samtyckesordning, analys, navigering, formulär eller den första interaktionen. Ändra den ansvariga exekveringssökvägen och regressionstesta nödvändigt beteende.

Verifiera en webbadress efter en lansering på delad mall. Det valda exemplet kan godkännas medan en tyngre innehållsvariant eller annan komponentkonfiguration fortfarande misslyckas. Testa typiska, tunga och kontrollsidor.

Avläsa origin-nivådata som ett mallgodkännande. Friska sidor med hög volym kan maskera en svag kategori-, artikel- eller produktmall. Håll diagnos och godkännande på den snävaste tillförlitliga omfattningen.

Avsluta på lanseringsdagen. Omedelbara tester etablerar labbgodkännande. De ersätter inte det rullande fältdatafönstret.

Vänta 28 dagar för att upptäcka en trasig lansering. Fältbekräftelse tar tid, men statuskoder, fel, användarresor, visuell stabilitet och kontrollerade mått kontrolleras omedelbart. Rullande data är inte en ursäkt för att hoppa över lanserings-QA.

Nästa fas: kontinuerlig övervakning och iteration

Överlämna fältverifieringsposten, lanseringsanteckningen, påverkade mallar, begränsningar och tröskelvärden till kontinuerlig uppdatering och iteration . Det behöver en stabil baslinje så att senare ändringar av innehåll, media, mallar, kampanjer och tredjeparter kan jämföras snarare än återupptäckas som oförklarad rörelse.

Nästa ägare dokumenterar vem som bevakar varje tröskel, var bevisen finns, hur ofta de granskas och vad som återöppnar åtgärden. Ett nyligen dåligt mått, upprepad trend av behov av förbättring över det fullt uppdaterade fönstret, ändrat LCP-element, ny långsam interaktion eller mallrelease som ändrar den diagnostiserade sökvägen bör återöppna checklistan vid punkt 1. Upprepa inte automatiskt den föregående åtgärden: samma mått kan misslyckas på grund av ett annat element efter en omdesign.

Överlämningen är komplett när fältstatus är explicit, varje accepterad begränsning har en ägare och granskningsdatum, och övervakning kan koppla en regression till en mall och lansering. Om fältverifiering fortfarande väntar, får nästa ägare det schemalagda granskningsdatumet och ärendet förblir Lab accepterat, inte stängt.

FAQ

Vanliga frågor om åtgärdande av Core Web Vitals