Søgte du efter »Core Web Vitals-vurderingen mislykkedes«, efter at du havde set en grøn hastighedsscore? Begynd med at tjekke, hvilke data de to resultater beskriver. PageSpeed Insights (PSI) kombinerer data fra faktiske besøg med en separat kontrolleret test. Notér adresse, enhed, datagrundlagets omfang og den måling, der ikke består, før du køber et værktøj eller beder nogen bygge siden om.
Vi begynder med de oplysninger, fordi »gør scoren grøn« lader for meget stå åbent. Udvikleren skal vide, hvilken brugeroplevelse der kræver opmærksomhed, og hvad der skal dokumentere, at en rettelse hjælper.
Core Web Vitals-vurderingen mislykkedes: hvad målte rapporten?
Vurderingen beskriver registrerede besøgsoplevelser, mens Lighthouse-afsnittet kører en diagnostisk test. Googles dokumentation til PageSpeed Insights forklarer, at feltdata kommer fra Chrome User Experience Report, eller CrUX, og dækker en bagudrettet indsamlingsperiode på 28 dage. En ny diagnostisk test og denne historik kan derfor vise forskellige resultater.
Testforholdene er forskellige. En kontrolleret test kan ikke dække alle enheder, forbindelser og handlinger ved faktiske besøg. Brug den til at undersøge en mulig årsag, og behold besøgsdataene ved siden af, når du vurderer, hvad der stadig er uafklaret.
Resultatet kan dække mere end siden. Hvis der er for få data for den præcise side, kan PSI falde tilbage på origin: overordnet set samme webadresse med protokol og værtsnavn. Et origin-resultat samler besøg på tværs af sider. Læs det viste omfang, før du bruger resultatet som dokumentation for en bestemt produkt- eller serviceside.
Perioden omfatter ældre besøg. En ændring i dag omskriver ikke gårsdagens observationer. Gem datoen for idriftsættelsen, så du kan skelne en umiddelbar kontrol af rettelsen fra senere data om besøgende.
Forskellene giver rapporterne hver sin opgave: besøgsdata viser en oplevelse, der skal undersøges; en kontrolleret test hjælper med at genskabe og undersøge den.
Hvilken måling kræver opmærksomhed?
Se på LCP, INP og CLS hver for sig, før du vælger en rettelse. Googles Web Vitals-vejledning skelner mellem indlæsning, reaktionsevne og visuel stabilitet. Tabellen viser vejledningens grænser for kategorien God, vurderet ved den 75. percentil for den relevante enhedsgruppe. Googles vejledning om grænseværdier forklarer den 75. percentil sådan: mindst 75 % af de målte sidevisninger skal opfylde grænsen for God for den pågældende måling. Det er noget andet end et gennemsnit eller den samlede Lighthouse-score.
| Måling | Hvad den beskriver | Grænse for God | Hvad du skal spørge den ansvarlige udvikler om |
|---|---|---|---|
| LCP, Largest Contentful Paint | Hvornår det største synlige indholdselement vises | Højst 2,5 sekunder | Hvilket element er forsinket, og hvor i indlæsningsforløbet? |
| INP, Interaction to Next Paint | Hvor hurtigt siden reagerer på interaktioner | Højst 200 millisekunder | Hvilket tryk, klik eller tastetryk er langsomt under de berørte forhold? |
| CLS, Cumulative Layout Shift | Uventede forskydninger i layoutet | Højst 0,1 | Hvilket element flytter sig, og hvornår under besøget? |
Når der er tilstrækkelige data for alle disse målinger, kræver PSI, at deres værdier ved den 75. percentil er gode, for at vurderingen kan bestås. Er INP-data utilstrækkelige, kan gode LCP- og CLS-værdier stadig give en bestået vurdering. Er data for enten LCP eller CLS utilstrækkelige, kan PSI ikke vurdere siden eller dens origin.
Behandl manglende data som usikkerhed. Googles CrUX-metode kræver besøg, der opfylder datakravene, og tilstrækkelig popularitet; den angiver ikke ét universelt mindsteantal besøgende. Et manglende resultat fortæller ikke, at ingen besøger siden, at oplevelsen er god, eller at en rettelse er mislykkedes.
Hvad kan du tjekke, før du betaler for arbejdet?
Gem en rapport som udgangspunkt, og gennemfør samme kunderejse på en telefon, før du vælger et værktøj. Du har brug for en klar beskrivelse af problemet: siden, dataene bag advarslen og den adfærd, du kan genskabe. Kan du ikke genskabe den, så notér begrænsningen i stedet for at udfylde hullet med et gæt.
- Åbn den præcise forretningsside i PSI. Gem adressen og rapportens dato. Medtag den landingsside eller skabelon, der har betydning for den henvendelse eller det køb, du undersøger.
- Notér mobil eller computer samt datagrundlagets omfang. Skriv, om feltafsnittet viser URL, origin eller utilstrækkelige data. Brug samme valg ved senere sammenligninger.
- Angiv den måling, der kræver opmærksomhed. Brug de enkelte Core Web Vitals-resultater, og læs derefter det diagnostiske afsnit efter spor. Lad det fremgå, hvor datagrundlaget mangler.
- Gennemfør en virkelig opgave på en telefon. Åbn menuen, brug det relevante filter, eller udfyld den relevante formular. Notér, hvad der indlæses sent, reagerer langsomt eller flytter sig uventet.
- Knyt et spor til en test. Bed udvikleren genskabe den berørte handling eller indlæsningsforsinkelse og forklare, hvad testen kan påvise.
Til bredere tjek af billeder, widgets, cache og hosting kan du bruge vores guide til typiske årsager til en langsom hjemmeside. Hold den aktuelle opgave fokuseret på den mislykkede vurdering og de oplysninger, der skal til for at kontrollere en rettelse.
Hvad skal rettelsen omfatte?
Vælg den mindste ændring, som diagnosen underbygger, og aftal så, hvordan den skal kontrolleres. Begynd med de rapporter og funktioner, du allerede har. Det tekniske arbejde bliver lettere at vurdere, når udvikleren angiver den berørte side eller skabelon, forklarer flaskehalsen og holder forholdene før og efter sammenlignelige.
- Knyt forslaget til målingen. LCP-vejledningen på web.dev skelner mellem forsinkelser i svar, opdagelse, indlæsning og rendering af det største element. INP-vejledningen fokuserer undersøgelsen på langsomme interaktioner. CLS-vejledningen omfatter forskydninger efter den første indlæsning. Bed om relevant dokumentation frem for et generelt løfte om bedre hastighed.
- Ret den fundne årsag, og test adfærden igen. En målrettet rettelse af en ressource eller skabelon kan indgå i udvikling og vedligeholdelse af hjemmesider. Notér, hvad der blev ændret og hvornår, samt hvordan ændringen om muligt kan rulles tilbage.
- Kontrollér, at kundens opgave stadig kan løses. Test sidens relevante navigation, formularer og købstrin. Bevar fungerende samtykkekontroller; undersøg deres adfærd og layout, samtidig med at lovligt samtykke opretholdes.
- Vurdér, om der mangler mere dokumentation. Hvis de tilgængelige rapporter ikke kan udpege den berørte interaktion eller side, kan yderligere målinger hjælpe. Spørg, hvilket spørgsmål den foreslåede overvågning besvarer, før du tilføjer en betalt tjeneste.
Hvis den tekniske prioritering er uklar, kan teknisk SEO-arbejde begynde med en diagnose og en opgaveliste, som du kan gennemgå. Et redesign eller en optimeringspakke kræver sin egen begrundelse.
Du kan kopiere dette opgavekort og lade ukendte felter stå tomme:
Side og forretningsopgave:
Enhed og feltdataenes omfang:
Måling, der kræver opmærksomhed:
Observeret adfærd og testforhold:
Foreslået årsag og ændring:
Dato for idriftsættelse:
Sammenlignelig kontrol efter ændringen:
Senere feltobservation og resterende usikkerhed:Hvordan tjekker du, om arbejdet har hjulpet?
Gennemgå først den ændrede adfærd, og sammenlign derefter senere feltdata inden for samme omfang. Ifølge dokumentationen opdaterer PSI sine feltdata dagligt, men bevarer et bagudrettet indsamlingsvindue. Gem datoen for idriftsættelsen sammen med oplysningerne. Vinduet er ikke en lovet nedtælling til en bestået vurdering.
Sammenlign den berørte måling og kundens opgave under lignende testforhold. Hvis symptomet fortsætter, skal diagnosen genåbnes. Hvis testen forbedres, men senere feltdata ikke underbygger ændringen, skal de berørte sider og de besøgendes forhold undersøges igen. Manglende feltdata skal fortsat stå som en udtrykkelig begrænsning.
Sådan hjælper vi
Vi begynder med rapporten, de vigtige sider og en opgave, som vi kan genskabe. Vi skelner mellem den foreslåede rettelse, kontrollen af den og senere data fra besøgende, så hver beslutning har et grundlag, du kan gennemgå. En brief om hjemmesidens ydeevne kan tage udgangspunkt i opgavekortet ovenfor; lad de ukendte felter stå synligt åbne.
