Prestanda- och Core Web Vitals-granskning

Fas P3 · Steg A — Förstå
Tidsram: 4–8 timmar för en representativ granskning; 2–5 arbetsdagar för en mallomfattande undersökning med teknikspårningar. 28-dagars fältvalideringen sker efter åtgärder och förlänger inte den initiala granskningstidsramen.
Ägare: den tekniska SEO-ansvariga äger omfattning och godkännande. En prestandaingenjör eller senior front-end-ingenjör ansvarar för diagnostik; plattforms-, CDN-, analys-, design- och produktägare bidrar där deras system skapar fördröjning eller instabilitet.

Denna fas omvandlar fältbevis från verkliga användare och repeterbara labbtester till en åtgärdsregister kopplat till webbadresser, mallar, mätvärden, ägare och godkännandevillkor – inte ett generiskt hastighetsresultat.

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

Prestanda hör hemma i Steg A eftersom en sida som timeoutar är ett crawlproblem innan det är ett användarupplevelseproblem. En crawler eller retriever-agent har en begränsad förfrågningsbudget. Om ursprungsservern stannar, omdirigerar upprepade gånger eller returnerar ett ofullständigt svar kan klienten överge sidan innan den kan utvärdera innehållet. Snabbare rubriker, bättre text och starkare schema kan inte hjälpa innehåll som inte hämtas tillförlitligt.

P3 använder kanoniska värdar, avsedda indexerbara mallar, prioriterade resor, statuskodsbevis och olösta infrastrukturfynd från den tekniska baslinjegranskningen . Den ordningen förhindrar falsk diagnostik. Till exempel är en femsekunders “sidladdning” orsakad av en omdirigeringsloop inte en biloptimeringsuppgift, och ett snabbt test av en cachad felsida är inte ett godkänt resultat. P2 fastställer att rätt URL kan begäras och väljas; P3 fastställer att den kan levereras och användas inom acceptabla tids- och stabilitetsgränser.

Att genomföra denna fas sent skapar omarbete. Ett innehållsteam kan publicera till en mall vars hjälte alltid är det långsammaste elementet, eller godkänna en kampanjplats som flyttar varje produktkort. Defekten multipliceras då över nya sidor.

Indata och utdata

Indata gör urvalet representativt. Utdata utgör kontraktet med nästa fas: exakt vilka sidor som är tillförlitligt tillgängliga, vilka förhållanden som fortfarande är svaga och vilka prestandabegränsningar som måste kvalificera senare mätningar.

Fältdata och labbdata är olika typer av bevis

Fältdata beskriver vad kvalificerade Chrome-användare faktiskt upplevde. Chrome User Experience Report, vanligtvis förkortat CrUX, sammanställer mätningar från verkliga besök och rapporterar den 75:e percentilen: värdet vid eller under vilket 75 % av de registrerade upplevelserna faller. Det inkluderar verklighetsbaserade variationer som enheter, nätverk, platser, cacheminnen, samtyckesverktyg, sessioner och interaktioner. Använd det för att avgöra om användare klarar de publicerade tröskelvärdena och om en utrullad förändring så småningom förbättrade populationen.

Labbdata beskriver en kontrollerad sidladdning eller interaktion under angivna förhållanden. Lighthouse är ett labbtest som tillämpar enhets- och nätverkssimulering, fångar en spårning och förklarar troliga orsaker. Använd det för att återskapa ett problem, jämföra två versioner under samma förhållanden, granska förfrågningskedjor och identifiera arbete. Ett labbresultat är användbart bevis, men det bevisar inte att verkliga användare klarar sig.

De två källorna kan visa olika resultat utan att någon av dem har fel. En snabb labbkörning kan använda en närliggande plats, varm CDN och ingen meningsfull interaktion, medan fältbesökare inkluderar äldre telefoner och avlägsna nätverk. Dokumentera avvikelsen och undersök dess förhållanden; genomsnitta aldrig värdena och välj inte det som ser bäst ut.

Checklistan

Utför dessa kontroller i ordning. Varje punkt anger åtgärd, anledning, metod, verktyg och godkännandevillkor så att den kan tilldelas och omtestas.

1. Frys den representativa URL- och villkorsmatrisen

Vad: definiera de webbadresser, mallar, enhetsprofiler, geografier, samtyckestillstånd och cachetillstånd som ska testas. Varför: en granskning som bara omfattar startsidan kan godkännas medan produkt-, artikel- eller kassamallen failar. Hur: kombinera P2-inventariet med trafik- och affärsprioritetsdata; välj typiska, tunga och konverteringskritiska exempel. Verktyg: analysverktyg, crawlinventarie, versionsregister och ett delat testblad. Godkänt när: varje prioriterad mall har ett ägargodkänt produktionsprov och varje test registrerar enhet, nätverk, plats, inloggning, samtycke och cacheantaganden.

2. Fånga CrUX-fältbaslinjen

Vad: registrera tillgängliga p75-fältmått på URL-nivå och separat på ursprungsnivå. Varför: ursprunget kan dölja en svag mall, medan en enskild lågtrafikerad URL kanske inte har publicerbar data. Hur: använd samma observationsdatum och 28-dagarsfönster, märk explicit URL respektive ursprung och registrera tomma värden som “otillräcklig data.” Verktyg: AmICited Web Vitals och CrUX. Godkänt när: varje provad URL har LCP-, INP-, CLS-, FCP- och TTFB-värden eller ett dokumenterat okänt tillstånd; källnivå och fönster är entydiga.

3. Verifiera svarets tillförlitlighet innan poängsättning av pixlar

Vad: upprepa förfrågningar och registrera status, omdirigeringar, Time to First Byte (TTFB), timeouts och inkonsekventa svar. TTFB är intervallet från förfrågningsstart tills den första svarsbyten anländer. Varför: en sida kan inte målas innan dess HTML börjar anlända, och ett intermittent fel är allvarligare än en kosmetisk försening. Hur: testa kallt och varmt cachebeteende från relevanta regioner, inspektera servertider och korrelera avvikelser med CDN- och ursprungsloggar. Verktyg: förfrågningsmonitor, webbläsarens nätverkspanel, CDN/ursprungsobserverbarhet och Lighthouse vattenfallsdiagram. Godkänt när: prioriterade webbadresser returnerar det avsedda 200-svaret utan oväntade hopp eller timeouts, och varje långsamt eller misslyckat svar har ett loggat fynd med en ägare.

4. Diagnostisera Largest Contentful Paint

Vad: identifiera Largest Contentful Paint -elementet (LCP) och dela upp dess tid i serverfördröjning, resursupptäckt, resursnedladdning och renderingsfördröjning. LCP mäter när det största synliga bild- eller textblocket är färdigrenderat. Varför: att komprimera en bild hjälper lite när webbläsaren upptäcker den sent, och frontend-ändringar kan inte radera en långsam väntan på ursprungsservern. Hur: inspektera spårningen och vattenfallet, jämför cachade och ocachade körningar, kontrollera förladdningsprioritet, responsiv bildstorlek, renderingsblockerande resurser, teckensnittsbeteende och klientrendering. Verktyg: Lighthouse, webbläsarens prestandaverktyg, förfrågningsvattenfall och bildinspektion. Godkänt när: det faktiska LCP-elementet och dominerande underdelen är namngivna för varje misslyckad mall, med en repeterbar före-mätning och en specifik åtgärdshypotes.

5. Diagnostisera Interaction to Next Paint

Vad: testa Interaction to Next Paint -vägen (INP) för verkliga åtgärder som menyöppning, filtrering, lägga i varukorg, formulärinmatning och avvisande av samtycke. INP mäter fördröjningen från en användarinteraktion tills webbläsaren visar nästa visuella uppdatering, med hjälp av en högfördröjningsinteraktion från besöket. Varför: en sida kan verka komplett men fortfarande ignorera användaren medan JavaScript upptar huvudtråden. Hur: återskapa viktiga åtgärder, inspektera långa uppgifter och händelsehanterare, testa tredjepartsskript och separera inmatningsfördröjning, bearbetningstid och presentationsfördröjning. Verktyg: CrUX, webbläsarens prestandaspårning, interaktionsprofilering och en realistisk enhet. Godkänt när: varje viktig interaktion har genomförts, den långsamma interaktionen och ansvariga uppgiften är identifierade för misslyckade mallar, och åtgärden har ett repeterbart interaktionstest.

6. Diagnostisera Cumulative Layout Shift

Vad: lokalisera oväntade rörelser som bidrar till Cumulative Layout Shift (CLS). CLS är en enhetslös poäng som representerar oväntade visuella rörelser under sidans livslängd. Varför: en sen banner, en bild utan storleksangivelse, ett bytt teckensnitt, en annons eller en hydrerad komponent kan flytta länken en användare är på väg att klicka på och kan förändra var automatisk extrahering hittar innehåll. Hur: använd layoutförskjutningsregioner och en filmremsa, testa fördröjda tillgångar och samtyckestillstånd och inspektera element utan reserverade dimensioner. Verktyg: CrUX, Lighthouse-spårning, webbläsarens renderingsdiagnostik och visuell regressionsfångst. Godkänt när: varje materiell förskjutning har ett källelement, utlösare och en åtgärd för reserverat utrymme eller rendering; förväntad rörelse som omedelbart orsakas av en användaråtgärd dokumenteras separat.

7. Använd FCP för att separera blank-skärmsfördröjning

Vad: mät First Contentful Paint (FCP), tiden tills webbläsaren renderar den första texten, bilden, canvas- eller SVG-innehållet. Varför: FCP särskiljer ett tidigt framstegstecken från en sida som förblir tom, även om det inte bevisar att huvudinnehållet är klart. Hur: jämför FCP med TTFB och LCP, inspektera blockerande CSS, teckensnitt, skript, serverrenderad markup och streamingbeteende. Verktyg: CrUX, Lighthouse och nätverks-/prestandaspårningen. Godkänt när: varje långsam FCP är hänförd till serverfördröjning, renderingsblockering, enbart klientrendering eller annan bevisad orsak, snarare än att bara beskrivas som “sidan känns långsam.”

8. Rangordna fynd efter allvarlighetsgrad, räckvidd och beroende

Vad: ordna backloggen efter felband, påverkad trafik och mallar, affärskritikalitet och uppströmsberoende. Varför: att åtgärda fem gula resultat kan konsumera sprinten medan ett rött TTFB-fel fördröjer varje sida på ursprungsservern. Hur: placera tillförlitlighetsfel först, sedan dåliga mätvärden före mätvärden som behöver förbättras; inom samma allvarlighetsgrad, åtgärda gemensamma plattformsorsaker och TTFB före nedströms LCP-arbete. Verktyg: fyndregister, analysverktyg, mallinventarie och teknisk uppskattning. Godkänt när: varje fynd har en allvarlighetsgrad, påverkat antal webbadresser eller mallomfattning, bevis, ägare, insats, beroende och explicit prioritet.

9. Validera implementationen i labbet

Vad: jämför den ändrade versionen med den registrerade baslinjen under identiska förhållanden. Varför: fältdata kan inte ge omedelbar återkoppling vid utrullning, och en icke-repeterbar “efter”-körning kan inte fastställa att kodändringen orsakade skillnaden. Hur: kör flera kontrollerade prover, jämför medianer snarare än den enskilt bästa körningen, inspektera spårningen av regressioner och testa kritiska interaktioner och layouter. Verktyg: Lighthouse, webbläsarens prestandaverktyg, staging eller kontrollerad produktionsutrullning och förfrågningsövervakning. Godkänt när: den avsedda orsaken är borttagen, det aktuella måttet klarar den överenskomna labbbudgeten över upprepade körningar, inget annat kritiskt mått har försämrats och bevis är bifogade till fyndet.

10. Notera utrullningen och vänta på fältbekräftelse

Vad: registrera driftsättningstid, omfattning, förväntat mått och valideringsdatum. Varför: CrUX är ett rullande 28-dagarsfönster, så besök före utrullningen förblir i den rapporterade percentilen efter att åtgärden har lanserats. Hur: övervaka fel omedelbart, kontrollera riktningsförändringar i fältdata allt eftersom ny data anländer och gör den slutliga jämförelsen först när tillräckligt många dagar efter utrullningen representerar fönstret. Verktyg: distributionslogg, AmICited Web Vitals, CrUX och övervakning. Godkänt när: omedelbara tekniska kontroller godkänns, utrullningsanteckningen är synlig och en namngiven ägare och datum finns för fältbekräftelse; fyndet markeras inte som “verifierat” enbart från labbdata.

Verktyg i AmICited

Öppna https://app.amicited.com/audit/web-vitals för att jämföra din domän med spårade konkurrenter med hjälp av verklig användardata från CrUX. Granskningen placerar LCP, INP, CLS, FCP och TTFB i en tabell, markerar din domän och gör saknad fältdata synlig istället för att omvandla den till en missvisande nolla. Använd jämförelsen för att besvara två frågor: om domänen klarar de publicerade tröskelvärdena och om en konkurrent som betjänar samma målgrupp har uppvisat ett markant bättre fältresultat.

Funktionen Performance Impact kopplar samman prestanda på sidnivå med citeringsposition och sannolikhet. Betrakta relationen som prioriteringsbevis, inte som bevis på att hastighet ensamt orsakade en citeringsförändring. Om en långsam citerad sida och en snabb ociterad sida skiljer sig i auktoritet, relevans eller innehåll, är prestanda bara en variabel. Den användbara signalen är att en påverkad sida är tillräckligt värdefull för att åtgärdas och övervakas.

För produktanvändning, följ Så här kontrollerar du dina Core Web Vitals i AmICited . Denna spelbok definierar granskningsomfattning, beslut och överlämning; handledningen täcker klick och avläsningar, så att duplicera det här skulle skapa två instruktioner som kan avvika från varandra.

Beslutsregler: hur dåligt ser ut

Bedöm Core Web Vitals från fältdata vid den 75:e percentilen. “Bra” innebär att p75-värdet är på eller under den goda gränsen. Ett värde på en gräns tillhör det bättre bandet; till exempel är LCP på exakt 2,5 sekunder bra. Stödjande FCP- och TTFB-tröskelvärden vägleder diagnostik och godkännande, men de ingår inte i den tremätbara Core Web Vitals-godkännandebedömningen.

Använd dessa prioriteringsregler:

1. Misslyckade förfrågningar, timeouts och ogiltiga svar väger tyngre än poäng. Tillförlitlighet är leveransgrinden.
2. Åtgärda dåliga band före band som behöver förbättras. Rött är en bevisad dålig upplevelse, inte ett poleringsprojekt.
3. Åtgärda TTFB före LCP när TTFB failar. LCP kan inte inträffa innan svaret börjar, så backend-fördröjning förbrukar LCP-budgeten innan webbläsaren kan rendera något.
4. Välj gemensamma orsaker framför isolerade symptom. En cachepolicyreparation över fyra mallar väger tyngre än fyra separata bildjusteringar med mindre räckvidd.
5. Använd trafik- och resvärde inom samma allvarlighetsgrad. En dålig INP i kassan eller LCP på en högtrafikerad artikel väger tyngre än ett lågtrafikerat arkiv i samma band.
6. Kalla inte ett tomt CrUX-värde för bra. Det är okänt. Använd repeterbara labbdata och en jämförbar mall tills fältvolym finns.
7. Lova inte omedelbar fältförändring. Validera utrullningen nu, låt sedan det rullande fönstret ersätta äldre upplevelser innan du accepterar eller avvisar fältresultatet.

Leverans: åtgärdsregistret för prestanda

Överlämna ett register plus dess bevisningsmapp till teknikteamet. Ett kalkylark, ärendehanteringssystem eller strukturerad projekttabell är acceptabelt om det bevarar dessa fält och möjliggör filtrering efter mall, allvarlighetsgrad, ägare och status:

ID och fynd:
Påverkade webbadresser och mallar:
Prioriterad resa och trafikkontext:
Mått och fältband:
CrUX-nivå, p75-värde och 28-dagarsfönster:
Labkonfiguration och upprepad baslinje:
Observerad orsak och bevisreferens:
Förväntat tillstånd och mål:
Rekommenderad ändring:
Allvarlighetsgrad och prioriteringsmotivering:
Ägare, beroende och insats:
Releasedatum och anteckning:
Omedelbart labbgodkännanderesultat:
Fältbekräftelsedatum och resultat:
Status: Öppen | Planerad | Labbgodkänd | Fältverifierad | Accepterad risk

Bifoga URL-matrisen, CrUX-export, labbspårningar, vattenfallsdiagram, filmremsor, interaktionsinspelningar, layoutförskjutningsbevis och versionsanteckningar. Deduplicera efter orsak: om samma ocachade ursprungsfråga skapar dålig TTFB över tre mallar, skapa ett överordnat fynd med tre påverkade omfattningar snarare än tre konkurrerande diagnoser.

“Accepterad risk” behöver en namngiven godkännare, anledning, påverkad omfattning, utgångs- eller granskningsdatum och övervakningsvillkor. Det är inte en ersättning för en ägare. Överlämningen är komplett när en ingenjör kan återskapa felet och ägaren av nästa fas kan identifiera vilka resultat som fortfarande begränsas av prestanda.

Vad kan gå fel

Att behandla Lighthouse som slutgiltigt omdöme. Ett resultat på 100 i en labbkörning åsidosätter inte dålig p75-fältdata. Bevara Lighthouse som diagnostiskt bevis och CrUX som populationsbevis.

Att bara testa startsidan. Ta prov på varje högvärdig mall plus ett tungt exempel, annars kommer malldefekter att undgå granskningen.

Att optimera LCP-bilden innan du kontrollerar TTFB. Tillgången kan vara liten medan ursprungsservern lägger två sekunder på att generera HTML. Dela upp LCP i dess komponenter och åtgärda uppströmstiden först.

Att använda den enskilt snabbaste körningen. Cachevärme, bakgrundsaktivitet och nätverksvariationer kan skapa en smickrande avvikelse. Håll konfigurationen fast och jämför medianer över upprepade körningar.

Att förklara seger dagen efter utrullning. Labbet kan bevisa att kod och leverans förändrades omedelbart; 28-dagarsfältfönstret kan inte. Notera utrullningen och schemalägg fältgodkännande.

Att markera saknad CrUX-data som noll. Ingen data innebär att behörighets- eller trafiktröskeln inte uppnåddes. Det säger inget om prestandakvalitet.

Att jaga sammansatt poäng istället för den misslyckade upplevelsen. En sammanfattningspoäng kan förbättras medan en kassainteraktion fortfarande hackar eller en hjälte fortfarande flyttar sig. Acceptera namngivna mätvärden och resor, inte kosmetisk poängförändring.

Att ta bort användbar funktionalitet för att vinna ett test. Att ta bort samtycke, personalisering, analys eller tillgänglighetsbeteende från labbvarianten producerar ett resultat som användarna aldrig får. Optimera produktionskravet eller fatta ett explicit produktbeslut.

Att ignorera regressioner utanför målmåttet. Att skjuta upp skript kan förbättra LCP men skapa dålig INP vid första interaktionen; att reservera fel dimensioner kan ersätta en laddningsfördröjning med CLS. Testa om alla fem måtten och den kritiska resan.

Nästa fas: AI-tillgänglighet och agentberedskap

Fasen AI-tillgänglighet och agentberedskap tar emot den representativa URL-matrisen, svars-tillförlitlighetsbevis, TTFB-fördelning, olösta prestandafynd och ett uttalande om vilket innehåll som finns i det initiala svaret. Dess ägare använder dessa bevis för att skilja en åtkomstpolicy-failure från en leveransfailure och för att återskapa de verkliga förhållanden under vilka en agent hämtar sidan.

Nästa fas kan fortsätta när kritiska webbadresser svarar tillförlitligt och inget olöst prestandaproblem gör att hämtningsbevis är otydbara. Den kan fortsätta med en skriftlig begränsning när ett mått som behöver förbättras påverkar användare men inte hindrar stabil åtkomst. Den bör pausa för påverkade mallar när förfrågningar timeoutar, returnerar intermittenta fel eller när huvudsvaret regelbundet överskrider den överenskomna kritiska tröskeln.

Överlämningen är komplett när nästa ägare vet vilka webbadresser som representerar varje mall, testförhållandena, de återstående leveransproblemen och om P3-bevis redan förklarar en långsam agenthämtning.

FAQ

Vanliga frågor