Performance- og Core Web Vitals-gennemgang

Fase P3 · Trin A — Forstå
Tidsramme: 4–8 timer for en repræsentativ gennemgang; 2–5 arbejdsdage for en skabelondækkende undersøgelse med udviklingsspor. 28-dages feltvalideringen sker efter rettelser og forlænger ikke den oprindelige tidsramme for gennemgangen.
Ejer: den tekniske SEO-leder ejer omfang og accept. En performanceingeniør eller senior frontend-ingeniør ejer diagnose; platform-, CDN-, analyse-, design- og produktansvarlige bidrager, hvor deres systemer skaber forsinkelse eller ustabilitet.

Denne fase omdanner feltdata fra rigtige brugere og reproducerbare laboratorietests til en afhjælpningsliste knyttet til URL’er, skabeloner, målinger, ejere og færdig-når-tests — ikke en generisk hastighedsscore.

Hvorfor denne fase, og hvorfor her

Performance hører til i trin A, fordi en side, der timeout’er, er et crawl-problem, før det er et brugeroplevelsesproblem. En crawler eller hentningsagent har et begrænset requestbudget. Hvis oprindelsen går i stå, omdirigerer gentagne gange eller returnerer et ufuldstændigt svar, kan klienten opgive siden, før den kan vurdere indholdet. Hurtigere overskrifter, bedre tekst og stærkere schema kan ikke hjælpe indhold, der ikke hentes pålideligt.

P3 forbruger de kanoniske værter, tilsigtede indekserbare skabeloner, prioritetsrejser, statuskodedokumentation og uafklarede infrastrukturfund fra den tekniske baseline-gennemgang . Denne rækkefølge forhindrer falsk diagnose. For eksempel er en fem-sekunders “sideindlæsning” forårsaget af en omdirigeringsløkke ikke en billedoptimeringsopgave, og en hurtig test af en cachelagret fejlside er ikke en beståelse. P2 etablerer, at den rigtige URL kan anmodes og udvælges; P3 etablerer, at den kan leveres og bruges inden for acceptable tids- og stabilitetsgrænser.

At gennemføre denne fase sent skaber efterarbejde. Et indholdsteam kan publicere ind i en skabelon, hvis hero-element altid er det langsomste element, eller godkende en reklameplads, der flytter hvert produktkort. Fejlen formerer sig derefter på tværs af nye sider.

Inputs og outputs

Inputs gør stikprøven repræsentativ. Outputs udgør kontrakten med næste fase: præcis hvilke sider der er pålideligt tilgængelige, hvilke forhold der forbliver svage, og hvilke performancebegrænsninger der må kvalificere senere målinger.

Feltdata og laboratoriedata er forskellig dokumentation

Feltdata beskriver, hvad kvalificerede Chrome-brugere faktisk oplevede. Chrome User Experience Report, ofte forkortet CrUX, samler målinger fra rigtige besøg og rapporterer 75. percentilen: den værdi, som 75 % af de registrerede oplevelser ligger på eller under. Det inkluderer rod fra rigtige enheder, netværk, lokationer, caches, samtykkeværktøjer, sessioner og interaktioner. Brug det til at afgøre, om brugere består de offentliggjorte tærskler, og om en udsendt ændring til sidst forbedrede populationen.

Laboratoriedata beskriver én kontrolleret sideindlæsning eller interaktion under erklærede forhold. Lighthouse er en laboratorietest, der anvender enheds- og netværkssimulering, optager et spor og forklarer sandsynlige årsager. Brug det til at reproducere et problem, sammenligne to builds under samme opsætning, inspicere requestkæder og identificere arbejde. En laboratorie-score er nyttig dokumentation, men beviser ikke, at rigtige brugere består.

De to kilder kan være uenige uden at nogen af dem tager fejl. En hurtig laboratoriekørsel kan bruge en nærliggende lokation, varm CDN og ingen meningsfuld interaktion, mens feltbesøgende inkluderer ældre telefoner og fjerne netværk. Registrér uenigheden og undersøg dens forhold; gennemsnit aldrig værdierne, og vælg ikke den, der ser sundest ud.

Tjeklisten

Gennemfør disse tjek i rækkefølge. Hvert punkt angiver handling, årsag, metode, værktøj og acceptbetingelse, så det kan tildeles og eftertestes.

1. Fastlås den repræsentative URL- og tilstandsmatrix

Hvad: definér de URL’er, skabeloner, enhedsprofiler, geografier, samtykketilstande og cache-tilstande, der skal testes. Hvorfor: en forside-only gennemgang kan bestå, mens produkt-, artikel- eller checkout-skabelonen fejler. Hvordan: sammenkobl P2-inventaret med trafik- og forretningsprioritetsdata; vælg typiske, tunge og konverteringskritiske eksempler. Værktøj: analyser, crawl-inventar, udgivelsesregister og et fælles testark. Færdig når: hver prioritetsskabelon har en ejergodkendt produktionsprøve, og hver test registrerer enheds-, netværks-, lokations-, login-, samtykke- og cache-antagelser.

2. Indfang CrUX-feltbaseline

Hvad: registrér tilgængelige p75-feltmålinger på URL-niveau og separat på oprindelsesniveau. Hvorfor: oprindelsen kan skjule en svag skabelon, mens en individuel URL med lav trafik muligvis ikke har offentliggørbare data. Hvordan: brug samme observationsdato og 28-dages vindue, mærk URL versus oprindelse eksplicit, og registrér tomme værdier som “utilstrækkelige data.” Værktøj: AmICited Web Vitals og CrUX. Færdig når: hver samplet URL har LCP-, INP-, CLS-, FCP- og TTFB-værdier eller en dokumenteret ukendt tilstand; kildeniveau og vindue er utvetydige.

3. Bekræft svarpålidelighed, før pixels scores

Hvad: gentag requests og registrér status, omdirigeringer, Time to First Byte (TTFB), timeouts og inkonsistente svar. TTFB er intervallet fra requeststart, indtil den første svarsbyte ankommer. Hvorfor: en side kan ikke male, før dens HTML begynder at ankomme, og en lejlighedsvis fejl er mere alvorlig end en kosmetisk opbremsning. Hvordan: test kold og varm cache-adfærd fra relevante regioner, inspicér servertiming, og korrelér anomalier med CDN- og oprindelseslogge. Værktøj: requestmonitor, browser-netværkspanel, CDN/oprindelses-observerbarhed og Lighthouse-vandfaldsdiagram. Færdig når: prioritets-URL’er returnerer det tilsigtede 200-svar uden uventede hop eller timeouts, og hvert langsomt eller fejlet svar har et logget fund med en ejer.

4. Diagnosticér Largest Contentful Paint

Hvad: identificér Largest Contentful Paint -elementet (LCP) og opdel dets tid i serverforsinkelse, ressourceopdagelse, ressourcehentning og renderingsforsinkelse. LCP måler, hvornår det største synlige billede eller tekstblok er færdig med at gengive. Hvorfor: komprimering af et billede hjælper lidt, når browseren opdager det sent, og frontend-ændringer kan ikke fjerne en langsom oprindelsesventetid. Hvordan: inspicér sporet og vandfaldsdiagrammet, sammenlign cachelagrede og ikke-cachelagrede kørsler, tjek preload-prioritet, responsiv billedstørrelse, render-blokerende ressourcer, skrifttypeadfærd og klient-side-rendering. Værktøj: Lighthouse, browser-performanceværktøjer, requestvandfaldsdiagram og billedinspektion. Færdig når: det faktiske LCP-element og dominerende underdel er navngivet for hver fejlende skabelon, med en reproducerbar før-måling og en specifik rettelseshypotese.

5. Diagnosticér Interaction to Next Paint

Hvad: test Interaction to Next Paint -stien (INP) for rigtige handlinger såsom menuåbning, filtrering, tilføjelse til kurv, formularinput og afvisning af samtykke. INP måler forsinkelsen fra en brugerinteraktion, indtil browseren viser den næste visuelle opdatering, ved hjælp af en høj-latens-interaktion fra besøget. Hvorfor: en side kan se færdig ud, men stadig ignorere brugeren, mens JavaScript optager hovedtråden. Hvordan: reproducér vigtige handlinger, inspicér lange opgaver og hændelseshåndteringer, test tredjepartsscripts, og adskil inputforsinkelse, behandlingstid og præsentationsforsinkelse. Værktøj: CrUX, browser-performance-spor, interaktionsprofilering og en realistisk enhed. Færdig når: hver vigtig interaktion er blevet udøvet, den langsomme interaktion og ansvarlige opgave er identificeret for fejlende skabeloner, og rettelsen har en reproducerbar interaktionstest.

6. Diagnosticér Cumulative Layout Shift

Hvad: lokalisér uventet bevægelse, der bidrager til Cumulative Layout Shift (CLS). CLS er en enhedsløs score, der repræsenterer uventet visuel bevægelse i løbet af sidens levetid. Hvorfor: et sent banner, et billede uden størrelsesangivelse, en byttet skrifttype, en annonce eller en hydreret komponent kan flytte linket, som brugeren er ved at klikke på, og kan ændre, hvor automatiseret ekstraktion finder indhold. Hvordan: brug layoutforskydningsområder og en filmstrimmel, test forsinkede aktiver og samtykketilstande, og inspicér elementer uden reserverede dimensioner. Værktøj: CrUX, Lighthouse-spor, browser-renderingsdiagnostik og visuel regressionsoptagelse. Færdig når: hver væsentlig forskydning har et kildeelement, en udløser og en pladsreserverings- eller renderingsrettelse; forventet bevægelse forårsaget umiddelbart af en brugerhandling dokumenteres separat.

7. Brug FCP til at adskille blank-skærm-forsinkelse

Hvad: mål First Contentful Paint (FCP), tiden indtil browseren gengiver det første tekst, billede, canvas eller SVG-indhold. Hvorfor: FCP adskiller et tidligt tegn på fremdrift fra en side, der forbliver tom, selvom det ikke beviser, at hovedindholdet er klar. Hvordan: sammenlign FCP med TTFB og LCP, og inspicér derefter blokerende CSS, skrifttyper, scripts, server-renderet markup og streaming-adfærd. Værktøj: CrUX, Lighthouse og netværks-/performancesporet. Færdig når: hver langsom FCP er tildelt serverforsinkelse, render-blokering, klient-only-rendering eller en anden dokumenteret årsag, snarere end blot beskrevet som “siden føles langsom.”

8. Rangér fund efter alvorlighed, rækkevidde og afhængighed

Hvad: ordn backloggen efter fejlbånd, påvirket trafik og skabeloner, forretningskritikalitet og upstream-afhængighed. Hvorfor: at rette fem gule scores kan forbruge sprinten, mens én rød TTFB-fejl forsinker hver side på oprindelsen. Hvordan: placér pålidelighedsfejl først, derefter dårlige målinger før målinger, der har brug for forbedring; inden for samme alvorlighed, ret delte platformårsager og TTFB før downstream-LCP-arbejde. Værktøj: fundregister, analyser, skabeloninventar og udviklingsestimat. Færdig når: hvert fund har en alvorlighed, påvirket URL-antal eller skabelonomfang, dokumentation, ejer, indsats, afhængighed og eksplicit prioritet.

9. Valider implementering i laboratoriet

Hvad: sammenlign det ændrede build med den registrerede baseline under identiske forhold. Hvorfor: feltdata kan ikke give øjeblikkelig udgivelsesfeedback, og en ikke-reproducerbar “efter”-kørsel kan ikke fastslå, at kodeændringen forårsagede forskellen. Hvordan: kør flere kontrollerede prøver, sammenlign medianer snarere end den enkelte bedste kørsel, inspicér sporet for regressioner, og test kritiske interaktioner og layouts. Værktøj: Lighthouse, browser-performanceværktøjer, staging eller kontrolleret produktionsudgivelse og requestovervågning. Færdig når: den tilsigtede årsag er fjernet, den målsatte måling består den aftalte laboratoriebudget på tværs af gentagne kørsler, ingen anden kritisk måling regresserer, og dokumentation er vedhæftet fundet.

10. Annotér udgivelsen og vent på feltbekræftelse

Hvad: registrér udrulningstidspunkt, omfang, forventet måling og valideringsdatoer. Hvorfor: CrUX er et rullende 28-dages vindue, så besøg før udgivelsen forbliver i den rapporterede percentil, efter rettelsen er sendt. Hvordan: overvåg fejl straks, tjek retningsbestemt feltbevægelse, efterhånden som nye data ankommer, og foretag den endelige sammenligning først, når nok dage efter udgivelsen repræsenterer vinduet. Værktøj: udrulningslog, AmICited Web Vitals, CrUX og overvågning. Færdig når: øjeblikkelige tekniske tjek består, udgivelsesannoteringen er synlig, og en navngiven ejer og dato findes for feltbekræftelse; fundet markeres ikke “bekræftet” alene fra laboratoriedokumentation.

Værktøjer i AmICited

Åbn https://app.amicited.com/audit/web-vitals for at sammenligne dit domæne med sporede konkurrenter ved hjælp af CrUX-data fra rigtige brugere. Gennemgangen placerer LCP, INP, CLS, FCP og TTFB i én tabel, markerer dit domæne og gør manglende feltdata synlige i stedet for at forvandle dem til et misvisende nul. Brug sammenligningen til at besvare to spørgsmål: om domænet består de offentliggjorte tærskler, og om en konkurrent, der betjener det samme publikum, har demonstreret et væsentligt bedre feltresultat.

Performance Impact -funktionen forbinder performance på sideniveau med citationsposition og -sandsynlighed. Behandl relationen som prioriteringsdokumentation, ikke bevis for, at hastighed alene forårsagede en citationsændring. Hvis en langsom citeret side og en hurtig ikke-citeret side adskiller sig i autoritet, relevans eller indhold, er performance kun én variabel. Det nyttige signal er, at en påvirket side er værdifuld nok til at rette og overvåge.

For produktdrift, følg Sådan tjekker du dine Core Web Vitals i AmICited . Denne playbook definerer gennemgangsomfang, beslutninger og overdragelse; vejledningen dækker klik og aflæsninger, så at duplikere det her ville skabe to instruktioner, der kan afvige.

Beslutningsregler: hvordan dårligt ser ud

Bedøm Core Web Vitals ud fra feltdata ved 75. percentil. “God” betyder, at p75-værdien er på eller under den gode grænse. En værdi på en grænse tilhører det bedre bånd; for eksempel er LCP på præcis 2,5 sekunder godt. Understøttende FCP- og TTFB-tærskler guider diagnose og accept, men de er ikke en del af den tre-målings Core Web Vitals-beståelsesvurdering.

| Måling | Hvad den repræsenterer | God | Trænger til forbedring | Dårlig | Standardrespons | |—|—:|—:|—:|—:| | TTFB | Første svarsbyte; upstream af enhver maling | ≤ 800 ms | > 800–1.800 ms | > 1.800 ms | Undersøg oprindelse, cache, CDN, omdirigeringer og geografi før LCP-renderingsarbejde. | | FCP | Første synlige indhold | ≤ 1,8 s | > 1,8–3,0 s | > 3,0 s | Fjern blank-skærm-forsinkelse, og identificér render-blokerende eller klient-only-levering. | | LCP | Hovedsynligt indhold gengivet | ≤ 2,5 s | > 2,5–4,0 s | > 4,0 s | Opdel i TTFB, opdagelse, hentning og renderingsforsinkelse; ret den dominerende del. | | INP | Reaktionsevne på tværs af brugerinteraktioner | ≤ 200 ms | > 200–500 ms | > 500 ms | Profilér den langsomme interaktion og reducer hovedtråds- eller renderingsarbejde. | | CLS | Uventet visuel bevægelse | ≤ 0,10 | > 0,10–0,25 | > 0,25 | Reservér plads og fjern sene skabelonforskydninger; test gennem hele besøget. |

Brug disse prioritetsregler:

1. Fejlslagne requests, timeouts og ugyldige svar overtrumfer scores. Pålidelighed er leveringsporten.
2. Ret dårlige bånd før bånd, der trænger til forbedring. Rød er en dokumenteret dårlig oplevelse, ikke en poleringsmulighed.
3. Ret TTFB før LCP, når TTFB fejler. LCP kan ikke forekomme, før svaret begynder, så backend-forsinkelse forbruger LCP-budgettet, før browseren kan gengive noget.
4. Foretræk delte årsager frem for isolerede symptomer. Én cache-politik-reparation på tværs af fire skabeloner overtrumfer fire separate billedjusteringer med mindre rækkevidde.
5. Brug trafik- og rejseværdi inden for samme alvorlighed. En dårlig checkout-INP eller en artikel-LCP med høj trafik overtrumfer et arkiv med lav trafik på samme bånd.
6. Kald ikke en blank CrUX-værdi for god. Den er ukendt. Brug reproducerbar laboratoriedokumentation og en sammenlignelig skabelon, indtil feltvolumen findes.
7. Lov ikke øjeblikkelig feltbevægelse. Valider udrulningen nu, og lad derefter det rullende vindue erstatte ældre oplevelser, før du accepterer eller afviser feltresultatet.

Leverance: performanceafhjælpningsregistret

Overdrag ét register plus dets dokumentationsmappe til udviklingsteamet. Et regneark, en opgave tracker eller en struktureret projektabel er acceptabel, hvis den bevarer disse felter og tillader filtrering efter skabelon, alvorlighed, ejer og status:

ID og fund:
Påvirkede URL'er og skabeloner:
Prioritetsrejse og trafik-kontekst:
Måling og feltbånd:
CrUX-niveau, p75-værdi og 28-dages vindue:
Laboratoriekonfiguration og gentaget baseline:
Observeret årsag og dokumentationsreference:
Forventet tilstand og mål:
Anbefalet ændring:
Alvorlighed og prioritetsbegrundelse:
Ejer, afhængighed og indsats:
Udgivelsesdato og annotation:
Øjeblikkeligt laboratorieacceptresultat:
Feltbekræftelsesdato og -resultat:
Status: Åben | Planlagt | Laboratorieaccepteret | Feltverificeret | Accepteret risiko

Vedhæft URL-matricen, CrUX-eksporten, laboratoriespor, vandfaldsdiagrammer, filmstrimler, interaktionsoptagelser, layoutforskydningsdokumentation og udgivelsesannoteringer. Dedupliker efter årsag: hvis den samme ikke-cachelagrede oprindelsesforespørgsel skaber dårlig TTFB på tværs af tre skabeloner, opret ét overordnet fund med tre påvirkede omfang i stedet for tre konkurrerende diagnoser.

“Accepteret risiko” kræver en navngiven godkender, årsag, påvirket omfang, udløbs- eller gennemgangsdato og overvågningsbetingelse. Det er ikke en erstatning for en ejer. Overdragelsen er fuldført, når en udvikler kan reproducere fejlen, og ejeren af næste fase kan identificere, hvilke resultater der fortsat er begrænset af performance.

Hvad går galt

At behandle Lighthouse som dommen. En score på 100 i én laboratoriekørsel tilsidesætter ikke dårlige p75-feltdata. Bevar Lighthouse som diagnostisk dokumentation og CrUX som populationsdokumentation.

At teste kun forsiden. Sample hver højværdi-skabelon plus et tungt eksempel, ellers vil skabelonfejl undslippe gennemgangen.

At optimere LCP-billedet før kontrol af TTFB. Aktivet kan være lille, mens oprindelsen bruger to sekunder på at generere HTML. Opdel LCP i dets komponenter, og ret upstream-tiden først.

At bruge den enkelte hurtigste kørsel. Cache-varme, baggrundsaktivitet og netværksvariation kan skabe en smigrende outlier. Hold konfigurationen fast, og sammenlign medianer fra gentagne kørsler.

At erklære sejr dagen efter udgivelsen. Laboratoriet kan bevise, at kode og levering ændrede sig straks; 28-dages feltvinduet kan ikke. Annotér udgivelsen, og planlæg feltaccept.

At markere manglende CrUX-data som nul. Ingen data betyder, at berettigelses- eller trafiktærsklen ikke blev opfyldt. Det siger intet om performancekvalitet.

At jagte den sammensatte score i stedet for den fejlende oplevelse. En opsummeringsscore kan forbedres, mens en checkout-interaktion stadig går i stå, eller et hero-element stadig flytter sig. Accepter navngivne målinger og rejser, ikke kosmetisk scorebevægelse.

At fjerne nyttig funktionalitet for at vinde en test. Sletning af samtykke, personalisering, analyser eller tilgængelighedsadfærd fra laboratorievarianten producerer et resultat, brugerne aldrig modtager. Optimér produktionskravet, eller træf en eksplicit produktbeslutning.

At ignorere regressioner uden for målmålingen. Udsættelse af scripts kan forbedre LCP, men skabe dårlig INP ved første interaktion; reservation af de forkerte dimensioner kan erstatte en indlæsningsforsinkelse med CLS. Eftertest alle fem målinger og den kritiske rejse.

Næste fase: AI-tilgængelighed og agentparathed

Fasen AI-tilgængelighed og agentparathed modtager den repræsentative URL-matrix, svarpålidelighedsdokumentation, TTFB-fordeling, uafklarede performancefund og en erklæring om, hvilket indhold der er til stede i det første svar. Dens ejer bruger den dokumentation til at skelne en adgangspolitikfejl fra en leveringsfejl og til at reproducere de reelle forhold, under hvilke en agent henter siden.

Næste fase kan fortsætte, når kritiske URL’er reagerer pålideligt, og intet uafklaret performanceproblem gør hentningsdokumentation ufortolkelig. Den kan fortsætte med en skriftlig begrænsning, når en trænger-til-forbedring-måling påvirker brugere, men ikke forhindrer stabil adgang. Den bør sætte påvirkede skabeloner på pause, når requests timeout’er, returnerer lejlighedsvise fejl, eller hovedsvaret regelmæssigt overstiger den aftalte kritiske tærskel.

Overdragelsen er fuldført, når næste ejer ved, hvilke URL’er der repræsenterer hver skabelon, testbetingelserne, de resterende leveringsfejl, og om P3-dokumentation allerede forklarer en langsom agenthentning.

Ofte stillede spørgsmål

Ofte stillede spørgsmål