Gjennomgang av ytelse og Core Web Vitals

Fase P3 · Stadie A — Forstå
Tidsramme: 4–8 timer for en representativ gjennomgang; 2–5 arbeidsdager for en malsomfattende undersøkelse med tekniske sporinger. 28-dagers feltvalidering skjer etter rettinger og forlenger ikke den opprinnelige tidsrammen for gjennomgangen.
Eier: den tekniske SEO-lederen eier omfang og aksept. En ytelsesingeniør eller senior frontend-ingeniør eier diagnose; plattform-, CDN-, analyse-, design- og produkteiere bidrar der deres systemer skaper forsinkelse eller ustabilitet.

Denne fasen omdanner feltbevis fra reelle brukere og repeterbare laboratorietester til en utbedringsliste knyttet til URL-er, maler, målinger, eiere og ferdig-når-tester — ikke en generisk hastighetspoengsum.

Hvorfor denne fasen, og hvorfor her

Ytelse hører hjemme i Stadie A fordi en side som tar timeout er et gjennomsøkingsproblem før det er et brukeropplevelsesproblem. En crawler eller hentingsagent har et begrenset forespørselsbudsjett. Hvis opprinnelsesserveren stopper, omdirigerer gjentatte ganger, eller returnerer et ufullstendig svar, kan klienten forlate siden før den kan vurdere innholdet. Raskere overskrifter, bedre kopi og sterkere skjema kan ikke hjelpe innhold som ikke hentes pålitelig.

P3 bruker de kanoniske vertene, tiltenkte indekserbare maler, prioriterte brukerreiser, statuskodebevis og uløste infrastrukturfunn fra den tekniske basisgjennomgangen . Den rekkefølgen forhindrer feildiagnostisering. For eksempel er en fem sekunders «sidelasting» forårsaket av en omdirigeringssløyfe ikke en bildeoptimaliseringsoppgave, og en rask test av en bufret feilside er ikke en bestått test. P2 etablerer at riktig URL kan forespørres og velges; P3 etablerer at den kan leveres og brukes innenfor akseptable tids- og stabilitetsgrenser.

Å kjøre denne fasen sent skaper omarbeid. Et innholdsteam kan publisere inn i en mal der heltebildet alltid er det tregeste elementet, eller godkjenne en reklameplass som flytter på hvert produktkort. Feilen multipliseres da på tvers av nye sider.

Inndata og utdata

Inndata gjør utvalget representativt. Utdata danner kontrakten med neste fase: nøyaktig hvilke sider som er pålitelig tilgjengelige, hvilke forhold som fortsatt er svake, og hvilke ytelsesbegrensninger som må kvalifisere senere målinger.

Feltdata og laboratoriedata er forskjellige bevis

Feltdata beskriver hva kvalifiserte Chrome-brukere faktisk opplevde. Chrome User Experience Report, vanligvis forkortet til CrUX, samler målinger fra virkelige besøk og rapporterer 75. persentil: verdien som 75 % av registrerte opplevelser ligger på eller under. Det inkluderer rotet fra virkelige enheter, nettverk, lokasjoner, bufring, samtykkeverktøy, økter og interaksjoner. Bruk det til å avgjøre om brukere passerer de publiserte tersklene og om en levert endring til slutt forbedret populasjonen.

Laboratoriedata beskriver én kontrollert sidelasting eller interaksjon under deklarerte forhold. Lighthouse er en laboratorietest som bruker enhets- og nettverkssimulering, fanger en sporing og forklarer sannsynlige årsaker. Bruk det til å reprodusere et problem, sammenligne to versjoner under samme oppsett, inspisere forespørselskjeder og identifisere arbeid. En laboratoriepoengsum er nyttig bevis, men den beviser ikke at reelle brukere består.

De to kildene kan være uenige uten at noen av dem tar feil. En rask laboratoriekjøring kan bruke en nærliggende lokasjon, varm CDN og ingen meningsfylt interaksjon, mens feltbesøkere inkluderer eldre telefoner og fjerne nettverk. Registrer uenigheten og undersøk forholdene; gjennomsnittlig aldri verdiene eller velg den som ser sunnest ut.

Sjekklisten

Utfør disse kontrollene i rekkefølge. Hvert element angir handling, grunn, metode, verktøy og akseptvilkår slik at det kan tildeles og testes på nytt.

1. Frys den representative URL- og tilstandsmatrisen

Hva: definer URL-ene, malene, enhetsprofilene, geografiene, samtykketilstandene og bufringstilstandene som skal testes. Hvorfor: en gjennomgang kun av startsiden kan bestå mens produkt-, artikkel- eller betalingsmalen feiler. Hvordan: kombiner P2-oversikten med trafikk- og forretningsprioritetsdata; velg typiske, tunge og konverteringskritiske eksempler. Verktøy: analyseverktøy, gjennomsøkingsoversikt, utgivelsesregister og et felles testark. Ferdig når: hver prioriterte mal har et eiergodkjent produksjonseksempel og hver test registrerer enhet, nettverk, lokasjon, innlogging, samtykke og bufringsforutsetninger.

2. Fange CrUX-feltbaselineen

Hva: registrer tilgjengelige p75-feltmålinger på URL-nivå og separat på domenenivå. Hvorfor: domenet kan skjule en svak mal, mens en individuell URL med lav trafikk kan mangle publiserbare data. Hvordan: bruk samme observasjonsdato og 28-dagers vindu, merk URL versus domene eksplisitt, og registrer tomme verdier som «utilstrekkelig data». Verktøy: AmICited Web Vitals og CrUX. Ferdig når: hver samplede URL har LCP-, INP-, CLS-, FCP- og TTFB-verdier eller en dokumentert ukjent tilstand; kildenivå og vindu er utvetydige.

3. Bekreft svarpålitelighet før poengsetting av piksler

Hva: gjenta forespørsler og registrer status, omdirigeringer, Time to First Byte (TTFB), timeouts og inkonsistente svar. TTFB er intervallet fra forespørselsstart til den første svarbiten ankommer. Hvorfor: en side kan ikke male før HTML-en begynner å ankomme, og en periodisk feil er mer alvorlig enn en kosmetisk nedbremsing. Hvordan: test kald og varm bufringsatferd fra relevante regioner, inspiser server-timing, og korreler avvik med CDN- og opprinnelseslogger. Verktøy: forespørselsovervåker, nettleserens nettverkspanel, CDN/opprinnelsesobservabilitet og Lighthouse-vannfall. Ferdig når: prioriterte URL-er returnerer tiltenkt 200-svar uten uventede hopp eller timeouts, og hvert trege eller mislykkede svar har et logget funn med en eier.

4. Diagnostiser Largest Contentful Paint

Hva: identifiser Largest Contentful Paint (LCP)-elementet og del tiden inn i serverforsinkelse, ressursgjenfinning, ressursnedlasting og gjengivelsesforsinkelse. LCP måler når det største synlige bildet eller tekstblokken er ferdig gjengitt. Hvorfor: å komprimere et bilde hjelper lite når nettleseren oppdager det sent, og frontend-endringer kan ikke slette en treg opprinnelsesserver-ventetid. Hvordan: inspiser sporingen og vannfallet, sammenlign bufrede og ubufrede kjøringer, sjekk forhåndslastingsprioritet, responsiv bildestørrelse, renderingsblokkerende ressurser, skriftatferd og klientside-rendering. Verktøy: Lighthouse, nettleserens ytelsesverktøy, forespørselsvannfall og bildeinspeksjon. Ferdig når: det faktiske LCP-elementet og dominante underdelen er navngitt for hver feilende mal, med en reproduserbar før-måling og en spesifikk fikshypotese.

5. Diagnostiser Interaction to Next Paint

Hva: test Interaction to Next Paint (INP)-stien for reelle handlinger som menyåpning, filtrering, legg-i-handlekurv, skjemainntasting og samtykkeavvisning. INP måler forsinkelsen fra en brukerinteraksjon til nettleseren viser den neste visuelle oppdateringen, ved å bruke en interaksjon med høy latens fra besøket. Hvorfor: en side kan se komplett ut, men fortsatt ignorere brukeren mens JavaScript opptar hovedtråden. Hvordan: reproduser viktige handlinger, inspiser lange oppgaver og hendelsesbehandlere, test tredjepartsskript, og separer inndataforsinkelse, behandlingstid og presentasjonsforsinkelse. Verktøy: CrUX, nettleserens ytelsessporing, interaksjonsprofilering og en realistisk enhet. Ferdig når: hver viktig interaksjon er utført, den trege interaksjonen og ansvarlig oppgave er identifisert for feilende maler, og rettingen har en repeterbar interaksjonstest.

6. Diagnostiser Cumulative Layout Shift

Hva: lokaliser uventet bevegelse som bidrar til Cumulative Layout Shift (CLS). CLS er en enhetsløs poengsum som representerer uventet visuell bevegelse i løpet av sidens levetid. Hvorfor: en sen banner, et bilde uten størrelsesattributter, en byttet skrift, annonse eller hydrert komponent kan flytte lenken brukeren er i ferd med å klikke på, og kan endre hvor automatisert uttrekk finner innhold. Hvordan: bruk layoutendringsregioner og en filmstrimmel, test forsinkede ressurser og samtykketilstander, og inspiser elementer uten reserverte dimensjoner. Verktøy: CrUX, Lighthouse-sporing, nettleserens renderingsdiagnostikk og visuell regresjonsfangst. Ferdig når: hver vesentlig endring har et kildeelement, utløser, og en reservert-plass- eller renderingsretting; forventet bevegelse forårsaket umiddelbart av en brukerhandling dokumenteres separat.

7. Bruk FCP til å skille tom-skjerm-forsinkelse

Hva: mål First Contentful Paint (FCP), tiden til nettleseren gjengir det første teksten, bildet, canvas- eller SVG-innholdet. Hvorfor: FCP skiller en tidlig fremgangsindikator fra en side som forblir tom, selv om det ikke beviser at hovedinnholdet er klart. Hvordan: sammenlign FCP med TTFB og LCP, inspiser deretter blokkerende CSS, skrifter, skript, server-gjengitt markup og strømmeatferd. Verktøy: CrUX, Lighthouse og nettverks-/ytelsessporingen. Ferdig når: hver treg FCP er tilordnet serverforsinkelse, renderingsblokkering, kun-klient-rendering eller en annen dokumentert årsak, i stedet for bare å bli beskrevet som «siden føles treg».

8. Ranger funn etter alvorlighetsgrad, rekkevidde og avhengigheter

Hva: ordne oppgavelisten etter feilkategori, berørt trafikk og maler, forretningskritikalitet og oppstrømsavhengigheter. Hvorfor: å fikse fem gule poengsummer kan forbruke sprinten mens én rød TTFB-feil forsinker hver side på opprinnelsesserveren. Hvordan: plasser pålitelighetsfeil først, deretter dårlige målinger før målinger som trenger forbedring; innenfor samme alvorlighetsgrad, fiks delte plattformårsaker og TTFB før nedstrøms LCP-arbeid. Verktøy: funnregister, analyseverktøy, maloversikt og utviklingsestimat. Ferdig når: hvert funn har en alvorlighetsgrad, berørt URL-telling eller malomfang, bevis, eier, innsats, avhengighet og eksplisitt prioritet.

9. Valider implementering i laboratoriet

Hva: sammenlign den endrede versjonen med den registrerte baselinen under identiske forhold. Hvorfor: feltdata kan ikke gi umiddelbar tilbakemelding ved utgivelse, og en ikke-reproducerbar «etter»-kjøring kan ikke fastslå at kodeendringen forårsaket forskjellen. Hvordan: kjør flere kontrollerte prøver, sammenlign medianer i stedet for den enkelte beste kjøringen, inspiser sporingen for regresjoner, og test kritiske interaksjoner og layout. Verktøy: Lighthouse, nettleserens ytelsesverktøy, staging eller kontrollert produksjonsutgivelse, og forespørselsovervåking. Ferdig når: den tiltenkte årsaken er fjernet, målmetrikken består den avtalte laboratoriebudsjettet på tvers av gjentatte kjøringer, ingen annen kritisk metrikk regresserer, og bevis er vedlagt funnet.

10. Annoter utgivelsen og vent på feltbekreftelse

Hva: registrer distribusjonstidspunkt, omfang, forventet metrikk og valideringsdatoer. Hvorfor: CrUX er et rullerende 28-dagers vindu, så besøk før utrulling forblir i den rapporterte persentilen etter at rettingen er lansert. Hvordan: overvåk feil umiddelbart, sjekk retningsmessig feltbevegelse etter hvert som nye data ankommer, og utfør den endelige sammenligningen først når nok dager etter utrulling representerer vinduet. Verktøy: distribusjonslogg, AmICited Web Vitals, CrUX og overvåking. Ferdig når: umiddelbare tekniske kontroller består, utgivelsesannoteringen er synlig, og en navngitt eier og dato finnes for feltbekreftelse; funnet er ikke merket «verifisert» basert på laboratoriebevis alene.

Verktøy i AmICited

Åpne https://app.amicited.com/audit/web-vitals for å sammenligne ditt domene med sporede konkurrenter ved hjelp av reelle brukerdata fra CrUX. Gjennomgangen plasserer LCP, INP, CLS, FCP og TTFB i én tabell, markerer ditt domene, og gjør manglende feltdata synlige i stedet for å gjøre dem om til en misvisende null. Bruk sammenligningen til å svare på to spørsmål: om domenet består de publiserte tersklene, og om en konkurrent som betjener samme målgruppe har demonstrert et vesentlig bedre feltresultat.

Ytelsespåvirkningsfunksjonen Performance Impact kobler sideytelse med siteringsposisjon og -sannsynlighet. Betrakt forholdet som prioriteringsbevis, ikke et bevis på at hastighet alene forårsaket en sitatsendring. Hvis en treg sitert side og en rask ikke-sitert side skiller seg i autoritet, relevans eller innhold, er ytelse bare én variabel. Det nyttige signalet er at en berørt side er verdifull nok til å fikse og overvåke.

For produktdrift, følg Slik sjekker du dine Core Web Vitals i AmICited . Denne spilleboken definerer gjennomgangens omfang, beslutninger og overlevering; opplæringen dekker klikkene og avlesningene, så å duplisere det her ville skape to instruksjoner som kan skli fra hverandre.

Beslutningsregler: hvordan dårlig ser ut

Vurder Core Web Vitals basert på feltdata på 75. persentil. «God» betyr at p75-verdien er på eller under god-grensen. En verdi på en grense tilhører den bedre kategorien; for eksempel er LCP på nøyaktig 2,5 sekunder god. Støttende FCP- og TTFB-terskler veileder diagnose og aksept, men de er ikke en del av den tre-metriske Core Web Vitals-beståttvurderingen.

Bruk disse prioriteringsreglene:

1. Mislykkede forespørsler, timeouts og ugyldige svar rangerer over poengsummer. Pålitelighet er leveringsporten.
2. Fiks dårlige kategorier før kategorier som trenger forbedring. Rød er en dokumentert dårlig opplevelse, ikke en poleringsmulighet.
3. Fiks TTFB før LCP når TTFB feiler. LCP kan ikke skje før svaret begynner, så backend-forsinkelse forbruker LCP-budsjettet før nettleseren kan gjengi noe.
4. Foretrekk delte årsaker fremfor isolerte symptomer. Én cache-policy-reparasjon på tvers av fire maler rangerer over fire separate bildetilpasninger med mindre rekkevidde.
5. Bruk trafikk og reiseverdi innenfor samme alvorlighetsgrad. En dårlig betalings-INP eller høy-trafikk-artikkel-LCP rangerer over et lav-trafikk-arkiv på samme nivå.
6. Ikke kall en tom CrUX-verdi for god. Den er ukjent. Bruk repeterbart laboratoriebevis og en sammenlignbar mal til feltvolum eksisterer.
7. Ikke lov umiddelbar feltbevegelse. Valider utrullingen nå, la deretter det rullerende vinduet erstatte eldre opplevelser før du aksepterer eller avviser feltresultatet.

Leveranse: ytelsesutbedringsregisteret

Overlever utvikling ett register pluss tilhørende bevisperm. Et regneark, oppgavebehandler eller strukturert prosjekttabell er akseptabelt hvis det bevarer disse feltene og tillater filtrering etter mal, alvorlighetsgrad, eier og status:

ID og funn:
Berørte URL-er og maler:
Prioritert reise og trafikkontekst:
Metrikk og feltkategori:
CrUX-nivå, p75-verdi og 28-dagers vindu:
Laboratoriekonfigurasjon og gjentatt baseline:
Observert årsak og bevisreferanse:
Forventet tilstand og mål:
Anbefalt endring:
Alvorlighetsgrad og prioriteringsbegrunnelse:
Eier, avhengighet og innsats:
Utgivelsesdato og annotering:
Umiddelbart laboratorieakseptresultat:
Feltbekreftelsesdato og resultat:
Status: Åpen | Planlagt | Lab akseptert | Felt verifisert | Akseptert risiko

Vedlegg URL-matrisen, CrUX-eksporten, laboratorisporinger, vannfall, filmstrimler, interaksjonsopptak, layoutendringsbevis og utgivelsesannoteringer. Dedupliser etter årsak: hvis den samme ubufrede opprinnelsesspørringen skaper dårlig TTFB på tvers av tre maler, opprett ett overordnet funn med tre berørte omfang i stedet for tre konkurrerende diagnoser.

«Akseptert risiko» trenger en navngitt godkjenner, grunn, berørt omfang, utløps- eller gjennomgangsdato og overvåkingsbetingelse. Det er ikke en erstatning for en eier. Overleveringen er fullført når en utvikler kan reprodusere feilen og eieren av neste fase kan identifisere hvilke resultater som fortsatt er begrenset av ytelse.

Hva går galt

Å behandle Lighthouse som fasit. En poengsum på 100 i én laboratoriekjøring overstyrer ikke dårlige p75-feltdata. Behold Lighthouse som diagnostisk bevis og CrUX som populasjonsbevis.

Å teste bare startsiden. Sample hver høyverdi-mal pluss et tungt eksempel, ellers vil maldefekter unnslippe gjennomgangen.

Å optimalisere LCP-bildet før du sjekker TTFB. Ressursen kan være liten mens opprinnelsesserveren bruker to sekunder på å generere HTML. Del LCP inn i komponentene og fiks oppstrømstid først.

Å bruke den enkelt raskeste kjøringen. Bufringsvarme, bakgrunnsaktivitet og nettverksvariasjon kan skape en flatterende avviksverdi. Hold konfigurasjonen fast og sammenlign medianer fra gjentatte kjøringer.

Å erklære seier dagen etter utgivelse. Laboratoriet kan bevise at kode og levering endret seg umiddelbart; det 28-dagers feltvinduet kan ikke. Annoter utgivelsen og planlegg feltaksept.

Å markere manglende CrUX-data som null. Ingen data betyr at kvalifikasjons- eller trafikkterskelen ikke ble nådd. Det sier ingenting om ytelseskvalitet.

Å jage sammensatt poengsum i stedet for den feilende opplevelsen. En oppsummeringspoengsum kan forbedres mens en betalingsinteraksjon fortsatt stopper opp eller et heltebilde fortsatt flytter seg. Godta navngitte målinger og reiser, ikke kosmetisk poengsumbevegelse.

Å fjerne nyttig funksjonalitet for å vinne en test. Å slette samtykke, personalisering, analyseverktøy eller tilgjengelighetsatferd fra laboratorievarianten produserer et resultat brukere aldri får. Optimaliser produksjonskravet eller ta en eksplisitt produktbeslutning.

Å ignorere regresjoner utenfor målmetrikken. Utsettelse av skript kan forbedre LCP, men skape dårlig INP ved første interaksjon; å reservere feil dimensjoner kan erstatte en lasteforsinkelse med CLS. Test alle fem målingene og den kritiske reisen.

Neste fase: AI-tilgjengelighet og agentberedskap

Fasen AI-tilgjengelighet og agentberedskap mottar den representative URL-matrisen, svarpålitelighetsbevis, TTFB-fordeling, uløste ytelsesfunn og en uttalelse om hvilket innhold som finnes i det første svaret. Dens eier bruker disse bevisene til å skille en tilgangspolicyfeil fra en leveringsfeil og til å reprodusere de virkelige forholdene under hvilke en agent henter siden.

Neste fase kan fortsette når kritiske URL-er svarer pålitelig og ingen uløst ytelsesdefekt gjør hentingsbevis utolkbart. Den kan fortsette med en skriftlig begrensning når en trenger-forbedring-metrikk påvirker brukere, men ikke hindrer stabil tilgang. Den bør pause for berørte maler når forespørsler tar timeout, returnerer periodiske feil, eller hovedsvaret regelmessig overskrider den avtalte kritiske terskelen.

Overleveringen er fullført når neste eier vet hvilke URL-er som representerer hver mal, testforholdene, de gjenværende leveringsfeilene, og om P3-bevis allerede forklarer en treg agenthenting.

FAQ

Ofte stilte spørsmål