Core Web Vitals og page speed-metrikker

Core Web Vitals er de tre field-metrikker, Google bruger til at beskrive reel brugeroplevelse: LCP for indlæsning, INP for reaktionsevne og CLS for visuel stabilitet. Omkring dem ligger et lag af diagnostiske metrikker — FCP, TBT, TTFB — som ikke påvirker placeringen, men som fortæller dig hvorfor en Core Web Vital fejler.

Denne side dækker dem alle, grænseværdierne for hver enkelt, og hvordan du arbejder fra en dårlig score tilbage til årsagen.

Grænseværdierne kort fortalt

Alle metrikker nedenfor vurderes på 75. percentil af rigtige sidevisninger. Det betyder mere, end det lyder: hvis tre fjerdedele af dine besøg er hurtige, og den langsomste fjerdedel er elendig, fejler du. Et par hurtige test på din egen maskine beviser ingenting.

De tre første er resultattavlen. De tre sidste er det, du rent faktisk retter.

Lab data kontra field data

Den skelnen skaber mere forvirring end noget andet inden for web performance, så den er værd at få præcist på plads.

Field data (også kaldet RUM, Real User Monitoring) indsamles fra rigtige besøg på rigtige enheder. Chrome User Experience Report — CrUX — er det offentlige datasæt, Google selv rangerer på, og det er det, PageSpeed Insights viser øverst i en rapport. Det afspejler din faktiske målgruppe: deres telefoner, deres netværk, deres geografi. Det bevæger sig også langsomt, fordi CrUX rapporterer på et rullende 28-dages vindue. Deployer du en rettelse i dag, er tallet ikke fuldt opdateret før om en måned.

Lab data er en syntetisk test på en fast enhedsprofil med defineret CPU- og netværksbegrænsning. Lighthouse og WebPageTest producerer lab data. Fordi miljøet er konstant, skyldes en regression næsten altid en kodeændring frem for nogens ustabile wi-fi — og det gør lab data til det rigtige at lade en CI-build fejle på.

Brug begge dele, til hver sit formål:

• Field data fortæller dig, om du har et problem. Det er de eneste tal, der afspejler dine rigtige brugere, og de eneste Google rangerer på.
• Lab data fortæller dig, hvad problemet er. Det er reproducerbart, det giver dig en waterfall, og det fanger regressioner, før brugerne møder dem.

Et site kan have grønne lab-scores og røde field-scores — typisk fordi testprofilen er hurtigere end den typiske reelle enhed, eller fordi den testede URL ikke er den, folk lander på.

• Kør lab-test på én throttling-profil (mobil langsom 4G er standard), så tallene kan sammenlignes over tid.
• Tag medianen af 3-5 kørsler, aldrig en enkelt måling.
• Test repræsentative URL'er — forside, en produktside, en lang artikel — ikke kun landingssiden.
• Drag aldrig konklusioner om rigtige brugere ud fra lab data alene.

LCP — Largest Contentful Paint

LCP måler, hvor lang tid der går, før det største tekstblok, billede eller video-poster i viewporten er færdigrenderet. Det er Googles primære indikator for oplevet indlæsningshastighed.

Et langsomt LCP har næsten altid én af tre årsager: serveren er langsom (se TTFB nedenfor), hero-billedet er for tungt, eller render-blokerende ressourcer forsinker layout.

• Find ud af, hvilket element der faktisk er LCP-kandidaten — Lighthouse navngiver det. Udviklere optimerer rutinemæssigt det forkerte billede.
• Sænk TTFB først. LCP kan aldrig blive hurtigere end den første byte.
• Preload hero-billedet med <link rel="preload" as="image"> og lever det i AVIF eller WebP.
• Sæt eksplicit width og height, så layout ikke skubber LCP senere. Det hjælper CLS samtidig.
• Lazy-load aldrig hero-billedet. Lazy-load kun medier under folden.

INP — Interaction to Next Paint

INP måler forsinkelsen mellem en brugerinteraktion — klik, tryk, tastetryk — og den næste visuelle opdatering, browseren tegner. Den rapporterer den værste observerede interaktion, så ét langsomt klik kan dominere scoren.

INP fanger den oplevede reaktionsevne efter indlæsning: præcis de øjeblikke, hvor brugeren afgør, om sitet virker. Langsomme interaktioner skyldes typisk lange JavaScript-tasks, der blokerer main thread.

• Del lange tasks (over 50 ms) op med scheduler.yield() eller setTimeout.
• Defer ikke-kritiske scripts og fjern ubrugt JavaScript.
• Flyt tungt arbejde ud af click-, input- og keydown-handlers.
• Brug passive event listeners til scroll og touch.
• Hydrér framework-komponenter lazily — fuld sidehydrering er en klassisk INP-dræber.

CLS — Cumulative Layout Shift

CLS måler, hvor meget synligt indhold flytter sig uventet, mens siden indlæses og bruges. God er 0,1 eller derunder.

Layoutskift giver fejlklik, mistet læseposition og en generelt ustabil fornemmelse. I modsætning til rene indlæsningsmetrikker måler CLS friktion, brugeren mærker hver eneste gang en knap hopper under fingeren.

• Sæt altid width og height, eller aspect-ratio, på billeder, video og iframes.
• Reservér plads til annonceslots, embeds og indsatte bannere med min-height.
• Indsæt aldrig DOM over eksisterende indhold, medmindre det er direkte svar på en brugerhandling.
• Preload kritiske fonte og vælg font-display med omtanke.
• Animér med transform og opacity frem for egenskaber, der udløser reflow.

FCP — First Contentful Paint

FCP er det øjeblik, browseren tegner det første indhold — tekst, billede, SVG. Det er, når brugeren holder op med at stirre på en tom skærm.

FCP påvirker ikke placeringen direkte, men et dårligt FCP følges næsten altid af dårlige metrikker, der gør. Det peger typisk på render-blokerende ressourcer eller en langsom server.

Ret det ved at sænke TTFB, inline kritisk CSS, defer ikke-essentielle stylesheets og scripts, preloade fonte med font-display: swap og få render-blokerende tredjepartstags ud af <head>.

TBT — Total Blocking Time

TBT lægger de dele af alle lange tasks (over 50 ms) sammen, som falder mellem FCP og Time to Interactive. Den måles kun i lab og er den tætteste syntetiske indikator for INP.

Et højt TBT betyder, at main thread er optaget af at parse, kompilere eller eksekvere JavaScript, mens brugeren forsøger at interagere. Fordi den kører i lab, dukker den op i CI længe før brugerne mærker den.

• Profilér lange tasks i DevTools' Performance-panel.
• Code-split routes og defer ikke-kritiske bundles med dynamisk import().
• Flyt tungt arbejde til Web Workers.
• Gennemgå tredjepartsscripts — analytics, chat-widgets, A/B-værktøjer — og indlæs dem efter interaktion.
• Send mindre client-JavaScript. Intet andet flytter TBT lige så pålideligt.

TTFB — Time To First Byte

TTFB måler tiden fra request til første byte af svaret. Den dækker DNS-opslag, TCP- og TLS-handshakes, transporttid, serverbehandling og eventuelt CDN-arbejde.

TTFB er gulvet for alle andre indlæsningsmetrikker. En langsom server forsinker LCP, FCP og starten på script-eksekvering. Crawlere oplever den samme langsomhed, hvilket påvirker, hvor meget af sitet der bliver crawlet.

• Lever cacheable HTML og assets fra et CDN.
• Tilføj full-page eller fragment-caching for dynamisk indhold, der ikke er per bruger.
• Profilér langsomme databasekald, N+1-loops og synkrone eksterne API-kald.
• Aktivér HTTP/2 eller HTTP/3 og moderne TLS.
• Mål fra flere regioner — et hurtigt TTFB i din egen by beviser meget lidt.

FID — First Input Delay (retired)

FID målte forsinkelsen mellem brugerens første interaktion og browserens påbegyndelse af handleren. Den var en Core Web Vital fra 2020 til 12. marts 2024, hvor Google erstattede den med INP.

Behandl FID i ældre audits og dashboards som historisk kontekst. INP er en strengere test, fordi den måler den langsomste interaktion i hele sidens levetid og ikke kun den første — et site med grønt FID kan sagtens have dårligt INP.

Har du stadig FID-instrumentering: udskift dashboards og alerts med INP-mål, behold TBT som lab-indikator, og geninstrumentér RUM med web-vitals-biblioteket, der rapporterer INP som standard.

Lighthouse

Lighthouse er Googles open source-auditværktøj, indbygget i Chrome DevTools og motoren bag PageSpeed Insights. Det producerer lab-data inden for performance, tilgængelighed, best practices og SEO.

Den klassiske fejl er at behandle Lighthouse performance-scoren som målet. Den er et vægtet gennemsnit af lab-metrikker på én syntetisk profil — nyttig som diagnose, meningsløs som mål. Google rangerer på field data, ikke på din Lighthouse-score.

Brug Lighthouse til det, den er god til: opportunities- og diagnostics-sektionerne, som navngiver konkrete ressourcer og konkrete omkostninger. Scoren er en overskrift; waterfallen er historien.

En fremgangsmåde, der faktisk finder årsagen

1. Start i field data. Åbn PageSpeed Insights eller Search Consoles Core Web Vitals-rapport og få bekræftet, hvilken metrik der fejler, på hvilken skabelon, på hvilken enhedstype. Ret ikke noget endnu.
2. Reproducér i lab. Kør Lighthouse på en fejlende URL med mobil-throttling. Ser lab fint ud, mens field fejler, er din testprofil for gavmild, eller du tester den forkerte side.
3. Arbejd nedad i stakken. Et dårligt LCP med et dårligt TTFB er et serverproblem, ikke et billedproblem. Ret gulvet før loftet.
4. Ændr én ting ad gangen. Kør medianen af 3-5 lab-kørsler igen. Bekræft at metrikken flyttede sig.
5. Vent på field data. CrUX er et rullende 28-dages vindue. Reel bekræftelse tager uger, og det er normalt.

Sitecheck kører PageSpeed Insights som del af hvert scan, så lab-metrikker og deres diagnoser registreres løbende i stedet for at blive testet én gang og glemt.

Se også

• Web performance: levering, caching og uptime
• Teknisk SEO: crawling og indeksering
• Websikkerhed