Core Web Vitals i et klart sprog: hvad skal du rette først

Hvad er de tre Core Web Vitals?

Google indførte Core Web Vitals for at sætte tal på oplevelsen af at bruge en side. Der er tre, og hver af dem svarer på et spørgsmål, en besøgende ville stille uden at kende fagudtrykkene.

INP afløste en ældre måling, First Input Delay, i marts 2024. Hvis en gammel rapport eller et plugin stadig taler om FID, er rådene forældede. Mellem “god” og “dårlig” ligger et mellembånd, som Google kalder “skal forbedres”.

En side består, når alle tre målinger er gode for mindst 75 procent af de rigtige besøg. Den 75. percentil betyder noget. Din egen telefon på kontorets wifi i København er ikke den besøgende med en tre år gammel Android i toget mellem Odense og Aarhus.

Hvorfor ændrer mine testresultater sig hele tiden?

Der findes to slags målinger, og når man blander dem sammen, opstår det meste af frustrationen omkring sidehastighed.

• Feltdata kommer fra rigtige Chrome-brugere og indsamles i Chrome User Experience Report over løbende 28 dage. Det er dem, Google bruger. Du ser dem øverst i PageSpeed Insights og i rapporten om Core Web Vitals i Search Console, forudsat at dit site har trafik nok.
• Labdata er en enkelt simuleret test, som regel Lighthouse, kørt på en enhed med neddroslet hastighed. De er nyttige til at finde fejl, men varierer fra kørsel til kørsel og måler ikke INP direkte.

Den praktiske konsekvens: Jagt feltdataene, brug labdataene til at finde årsagerne, og regn med, at en rettelse kan tage op til fire uger om at slå fuldt igennem i felttallene. En Lighthouse-score på 100 er rar, men ikke målet. Mindre danske sites har ofte for lidt trafik til feltdata på sideniveau, og så falder Google tilbage på at gruppere lignende sider eller hele domænet.

Ret først: hvorfor indlæses hovedindholdet langsomt?

LCP er den måling, flest sites dumper i, og årsagen er som regel én fra en kort liste. Find først dit LCP-element. PageSpeed Insights navngiver det, og på de fleste virksomhedssites er det det store foto eller den store overskrift øverst på siden.

1. Gør topbilledet mindre. Server det i AVIF eller WebP i den størrelse, det vises i, med responsivt srcset, så telefoner får en fil i telefonstørrelse. Et foto på 3 MB direkte fra kameraet er det mest almindelige problem, vi ser.
2. Lad være med at lazy-loade det. Lazy loading er rigtigt til billeder længere nede, men på topbilledet forsinker det netop det, LCP måler. Giv i stedet topbilledet fetchpriority="high".
3. Gør serveren hurtigere. Hvis Time to First Byte er over cirka 800 millisekunder, kan ingen justering i frontenden redde dig. Sidecaching, bedre hosting eller et CDN med et europæisk edge-punkt hjælper som regel mere end noget andet.
4. Fjern filer, der blokerer renderingen. Store stylesheets og scripts i sidens head får browseren til at vente. Indlejr den kritiske CSS, og udskyd resten.
5. Tjek slidere og karruseller. De indlæser ofte flere store billeder og et script, før det første slide vises.

På WordPress-sites står et tungt page builder-tema kombineret med billig delt hosting for en stor del af den dårlige LCP. Nogle gange er den ærlige løsning et lettere tema frem for endnu et optimeringsplugin. Vores arbejde med hastighed og Core Web Vitals starter netop med den diagnose.

Ret dernæst: hvorfor hopper min side, mens den indlæses?

Layoutskift er det mest irriterende problem for besøgende og ofte det billigste at rette. Noget indlæses sent og skubber alt andet ned, så den besøgende trykker på det forkerte link eller mister sin plads.

• Billeder og videoer uden dimensioner. Angiv altid attributterne width og height eller et CSS-billedformat, så browseren reserverer pladsen.
• Cookiebannere. I Danmark har næsten alle sites et. Et banner, der skubber indholdet ned i stedet for at ligge ovenpå, tæller som et skift. Brug et overlay, eller reservér pladsen.
• Indlejringer og annoncer. Kort, bookingwidgets, opslag fra sociale medier og videoafspillere indlæses sent. Giv deres containere en fast minimumshøjde.
• Webfonte. Når en speciel font skiftes ind, kan teksten flytte sig. Forudindlæs de vigtigste fontfiler, og vælg en reservefont med lignende proportioner.
• Indhold, der skydes ind fra toppen. Meddelelsesbjælker og strimler med “gratis fragt”, som et script tilføjer efter indlæsningen, er en klassisk årsag.

Ret til sidst: hvorfor føles siden langsom til at reagere?

INP måler forsinkelsen mellem en interaktion, som et tryk på en menu eller et klik på “læg i kurv”, og den næste visuelle opdatering. Når den er dårlig, er årsagen næsten altid JavaScript, der holder browseren beskæftiget.

• Gennemgå tredjepartsscripts. Tag managers samler trackingkoder op gennem årene. Fjern alt, hvad ingen bruger, og sæt spørgsmålstegn ved chatwidgets, heatmaps og anmeldelsesbadges, der indlæses på hver side.
• Se på samtykkeværktøjet. Nogle samtykkeplatforme er tunge og udfører arbejde ved hvert klik. Test med og uden.
• Del lange opgaver op. Ethvert script, der kører i mere end 50 millisekunder, blokerer input. Udviklere kan dele arbejdet op i mindre bidder eller flytte det væk fra hovedtråden.
• Forenkl menuer og filtre. Megamenuer og produktfiltre, der bygger store dele af siden om ved hvert tryk, er hyppige syndere i webshops.

INP-problemer viser sig tydeligst på mellemklassetelefoner, hvilket er endnu en grund til at teste på rigtige enheder. At bygge mobilen først fra starten undgår mange af dem, fordi tunge desktopfunktioner aldrig kommer med i løsningen.

Hvor meget påvirker Core Web Vitals placeringen i Google?

Ærligt talt mindre, end mange værktøjsleverandører antyder. Google har sagt, at Core Web Vitals er en del af signalerne for sideoplevelse, og at relevant, nyttigt indhold stadig betyder mere. En langsom side med det bedste svar kan ligge over en hurtig side med et svagt svar.

Det stærkeste argument for at rette dem er kommercielt. Besøgende forlader langsomme sider, og de mest berørte er på mobilen, ofte på vej ind fra betalte annoncer, du allerede har betalt for. En hurtigere landingsside kan forbedre konverteringsraten og, i Google Ads, landingssideoplevelsen i Kvalitetsresultatet.

Ret pr. skabelon, ikke pr. URL. De fleste sites har en håndfuld sidetyper: forsiden, ydelsessider, artikler, produktsider og checkout. Search Console grupperer URL’er med lignende problemer, og en rettelse i skabelonen reparerer alle sider bygget på den på én gang. Start med de skabeloner, der bærer mest trafik og flest henvendelser.

Så behandl Core Web Vitals som en hygiejnestandard. Få alle vigtige skabeloner ind i det gode bånd, hold dem der, når nye scripts og kampagner tilføjes, og brug så kræfterne på indhold og tilbud. Et tjek af Search Console én gang om måneden er som regel nok til at fange en tilbagegang, før den koster dig noget.