Tre mål for brugeroplevelsen
Core Web Vitals måler indlæsning, reaktion på brugerens handlinger og visuel stabilitet. De tre aktuelle mål er LCP, INP og CLS. Googles anbefalede grænser for en god oplevelse er:
- LCP: højst 2,5 sekunder. Hvornår vises det største indholdselement i det første skærmbillede?
- INP: højst 200 millisekunder. Hvor hurtigt bliver siden visuelt opdateret efter brugerens interaktion?
- CLS: højst 0,1. Hvor meget flytter synligt indhold sig uventet?
Vurderingen sker ved 75-percentilen, opdelt på mobil og desktop. Det betyder, at mindst 75 procent af observationerne skal ligge på eller under grænsen. Alle tre mål skal opfylde grænserne for en samlet god vurdering. Googles definitioner af Web Vitals.
Ældre vejledninger kan nævne FID. Det er erstattet af INP som Core Web Vital og beskriver ikke samme måling. Brug de aktuelle mål og datakilden i rapporten frem for at sammenligne gamle FID-tal direkte med INP.
Brugerdata og laboratorietest besvarer forskellige spørgsmål
Brugerdata beskriver oplevelser fra faktiske besøg. En laboratorietest undersøger siden under bestemte testforhold. En almindelig Lighthouse-indlæsning måler ikke INP, fordi testen ikke indeholder brugerinteraktioner; Total Blocking Time kan bruges som et diagnostisk signal. En laboratoriescore erstatter derfor ikke vurderingen af faktiske brugeroplevelser. Google om måling af Web Vitals.
Jeg anbefaler at mærke hver måling med datakilde, periode, enhed og URL. Notér også, om rapporten viser den konkrete side eller et samlet niveau. Hvis du mangler brugerdata, skal rapporten sige det direkte. “Ingen data” er hverken en godkendelse eller en dårlig måling.
Et nyttigt førnotat kan eksempelvis være: “Produktskabelon A, mobil, laboratorietest, tre gentagelser med samme indstillinger. Brugerdata for den enkelte URL er ikke tilgængelige.” Det er mere anvendeligt end en løs grøn eller rød score.
Dårlig LCP: find ventetiden omkring hovedindholdet
LCP kan blive forsinket, før serveren svarer, før ressourcen bliver hentet, under selve overførslen eller før browseren viser elementet. Identificér først det målte element. Hvis det er et billede, er en mindre fil ikke nødvendigvis hele løsningen; det kan også blive opdaget sent eller holdt skjult. Googles vejledning til LCP.
Bed om en rettelse, der nævner både årsag og element. “Hovedbilledet opdages sent på produktsider” giver en konkret undersøgelse. “Alle billeder skal optimeres” kan føre til meget arbejde uden at ramme ventetiden.
Lazy loading er ikke en generel kur mod dårlig LCP. Hvis hovedbilledet i det første skærmbillede udskydes, kan det forsinke visningen. Undersøg billedets størrelse, opdagelse og prioritering sammen. Caching eller en anden hostingløsning bør tilsvarende begrundes i den målte ventetid, ikke vælges som en automatisk første rettelse.
Dårlig INP: genskab den langsomme handling
Ved INP skal du undersøge konkrete interaktioner. En optaget performanceprofil kan vise, om andet arbejde blokerer handlingen, om selve hændelseshåndteringen tager lang tid, eller om den efterfølgende visning er dyr. Store JavaScript-opgaver kan forsinke responsen. Googles vejledning til INP.
Skriv handlingen som en lille test: “Åbn produktfilteret, vælg farve og luk panelet.” Notér, om problemet opstår ved første brug, efter flere valg eller på en bestemt enhed. Kontrollér efter rettelsen, at filteret både reagerer hurtigere og stadig viser de rigtige produkter.
Dårlig CLS: registrér det, der flytter indholdet
Billeder uden reserveret plads, indhold der indsættes sent, og skrifter der ændrer tekstens størrelse kan give layoutforskydninger. Reservér relevant plads, og undersøg forløbet gennem hele sidebesøget. Problemet kan opstå efter den første indlæsning. Googles vejledning til CLS.
Et tænkt eksempel er en anmeldelsesboks, som dukker op over købsknappen. Kunden bevæger fingeren mod knappen, men boksen skubber den ned. Test derfor tidspunktet og placeringen sammen med resten af produktsiden; et pænt slutbillede afslører ikke bevægelsen undervejs.
Reservering af plads skal stadig fungere responsivt. Faste dimensioner på alle elementer er ikke en universel løsning. Kontrollér tekstombrydning, billedforhold og dynamiske komponenter på de relevante skærmbredder.
Prioritér efter berørte sider og brugeropgaver
Jeg ville normalt samle ens fejl på tværs af skabeloner, før jeg opretter en opgave for hver URL. En fælles komponent kan være årsag til problemet på mange sider. Vælg derefter et repræsentativt eksempel til fejlsøgning og flere sider til efterkontrol.
En praktisk opgaveliste bør for hver rettelse vise:
- Berørt skabelon og et eksempel på problemet.
- Det mål og den brugerhandling, der skal forbedres.
- Ansvarlig person og forventede afhængigheder.
- Før- og eftermåling under sammenlignelige forhold.
- Funktioner, som skal kontrolleres ved godkendelsen.
For platformspecifikke eksempler kan du fortsætte til Shopify-hastighed eller WordPress-hastighed. En SEO-analyse kan sætte performanceproblemerne ind i en bredere prioritering af hjemmesiden.
FAQ
Gode målinger er en del af en brugbar oplevelse, men dokumenterer ikke i sig selv bedre salg eller placeringer. Google om Core Web Vitals og søgeresultater.
Giver gode Core Web Vitals automatisk bedre placeringer?
Nej. Google bruger Core Web Vitals i sine rankingsystemer, men gode målinger garanterer ikke topplaceringer. Relevans og andre signaler spiller også ind.
Kan jeg sammenligne en lokal test med brugerdata fra den aktive side?
Ikke som samme type måling. En lokal test er nyttig til fejlsøgning, men beskriver andre forhold. Rapportér kilderne hver for sig.
Skal alle sider testes manuelt?
Start med repræsentative skabeloner og vigtige brugerforløb. Udvid kontrollen, når en side har særlige komponenter eller afviger fra de øvrige.
Skal hovedbilledet have lazy loading?
Ikke som en automatisk regel. Et hovedbillede i det første skærmbillede kan blive vist senere, hvis hentningen udskydes. Undersøg det målte LCP-element og dets indlæsningsforløb.
Få prioriteret de konkrete rettelser
Kontakt mig med berørte sider og målinger. Den generelle guide til hastighedsoptimering kan hjælpe med at afgrænse opgaven.