Web Performance — Core Web Vitals og teknisk hastighed

Web performance handler om, hvor hurtigt og stabilt en hjemmeside loader og responderer. For SEO er performance ikke blot et brugervenligheds-parameter — det er siden 2021 en direkte rankingfaktor via Googles Core Web Vitals. En langsom side kan have fremragende indhold og stærke backlinks og stadig underperforme i søgeresultaterne.

Hvad er Core Web Vitals?

Core Web Vitals er tre specifikke målinger af brugeroplevelsens tekniske kvalitet. Google definerede dem som rankingfaktorer som del af Page Experience-opdateringen, der rullede ud fra 2021.

De tre målinger er:

LCP — Largest Contentful Paint

LCP måler, hvornår sidens største synlige indholdselement er indlæst. Det er typisk et hero-billede, et baggrundsbillede eller en stor overskrift øverst på siden.

Googles grænseværdier:

• God: under 2,5 sekunder
• Skal forbedres: 2,5–4,0 sekunder
• Dårlig: over 4,0 sekunder

LCP er den vigtigste af de tre Core Web Vitals-målinger set fra et brugeroplevelsesperspektiv, fordi den er det tætteste vi kommer på “hvornår ser siden brugbar ud?”.

Typiske årsager til dårlig LCP:

• Store, ukomprimerede billeder
• Render-blocking CSS eller JavaScript
• Langsom server response time (TTFB)
• Billeder uden forudindlæsning (preload)

INP — Interaction to Next Paint

INP måler, hvor responsiv siden er over for brugerinteraktioner — klik, tastaturinput, tryk. Det er en samlet score over alle interaktioner under besøget, ikke blot den første.

INP erstattede FID (First Input Delay) i marts 2024. FID målte kun forsinkelsen til første interaktion og fangede ikke opdateringens omfang. INP er en mere præcis og nuanceret måling.

Googles grænseværdier:

• God: under 200 millisekunder
• Skal forbedres: 200–500 millisekunder
• Dårlig: over 500 millisekunder

Typiske årsager til dårlig INP:

• Tung JavaScript-eksekvering på main thread
• Lang task-kørsel der blokerer for UI-opdateringer
• For mange JavaScript event handlers
• Komplekse DOM-opdateringer ved interaktion

CLS — Cumulative Layout Shift

CLS måler, hvor meget sidens elementer rykker sig, mens siden loader og brugeren interagerer. Uventede layout-skift er frustrerende: du er ved at trykke på en knap, og pludselig rykker layoutet, og du trykker på noget andet.

CLS scores er unitless — de er et beregnet produkt af skiftets størrelse og afstand.

Googles grænseværdier:

• God: under 0,1
• Skal forbedres: 0,1–0,25
• Dårlig: over 0,25

Typiske årsager til dårlig CLS:

• Billeder og videoelementer uden width- og height-attributter
• Reklamer og embeds der indsættes dynamisk
• Web fonts der loades sent og forskubber tekst (FOUT/FOIT)
• Indhold der indsættes dynamisk over eksisterende indhold

Field data vs Lab data

Core Web Vitals måles på to måder, og forskellen er vigtig:

Lab data (syntetisk data) — målinger foretaget i et kontrolleret miljø med et specifikt testværktøj (Lighthouse, PageSpeed Insights, WebPageTest). Reproducerbare og nyttige til fejlfinding, men afspejler ikke nødvendigvis rigtige brugeroplevelser.

Field data (real user monitoring, RUM) — målinger fra rigtige brugere samlet via Chrome User Experience Report (CrUX). Det er field data, Google bruger som rankingfaktor — ikke lab data.

En side kan have gode Lighthouse-scores men dårlige CrUX-scores (f.eks. fordi rigtige brugere primært er på langsomme mobilforbindelser). Optimer altid mod field data.

Responsivt design og mobile-first indexing

Google bruger mobile-first indexing — det vil sige, at Googles primære vurdering af din side er baseret på mobilversionen. Siden 2024 er alle nye sider subject til mobile-first indexing.

Responsivt design er den anbefalede tilgang: én URL, ét sæt HTML, CSS der tilpasser layoutet til skærmstørrelsen via media queries. Alternativerne — separate mobile-sider (m.example.com) eller dynamisk serving — er mere komplekse at vedligeholde og kræver ekstra konfiguration for at undgå SEO-problemer.

/* Eksempel på responsive CSS */
.container {
  width: 100%;
  max-width: 1200px;
  padding: 0 1rem;
}

@media (min-width: 768px) {
  .container {
    padding: 0 2rem;
  }
}

Viewport meta tag er obligatorisk for korrekt mobilvisning:

<meta name="viewport" content="width=device-width, initial-scale=1">

Sider uden viewport meta tag vises zoomet ud og ulæselige på mobil.

Billedoptimering

Billeder er typisk den tyngste ressource på en hjemmeside. Optimering af billeder giver typisk den største enkeltgevinst i performance:

Moderne billedformater: WebP og AVIF er markant mere komprimerede end JPEG og PNG ved sammenlignelig kvalitet. Brug <picture> elementet til at servere det bedst understøttede format:

<picture>
  <source srcset="billede.avif" type="image/avif">
  <source srcset="billede.webp" type="image/webp">
  <img src="billede.jpg" alt="Beskrivelse" width="1200" height="800">
</picture>

width og height attributter er afgørende for CLS. Når browseren kender billedets dimensioner i forvejen, reserverer den pladsen i layoutet, inden billedet er indlæst — og forhindrer dermed layout-skift.

loading="lazy" på billeder under fold udsætter download til billedet er ved at blive synligt. Brug ikke lazy loading på billeder øverst på siden (over fold) — det forsinker LCP.

fetchpriority="high" på det primære LCP-billede signalerer til browseren, at dette billede skal prioriteres:

<img src="hero.webp" alt="Hero" width="1200" height="600" fetchpriority="high">

Render-blocking ressourcer

CSS og JavaScript i <head> kan blokere rendering — browseren kan ikke vise siden, mens disse filer downloades og processeres.

For CSS: Kritisk CSS (above-the-fold styling) kan inlines direkte i <head> for øjeblikkelig rendering. Resten af CSS indlæses asynkront:

<style>/* Kritisk CSS her */</style>
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">

For JavaScript: Brug defer attributten på ikke-kritiske scripts. Placer scripts i bunden af <body> hvis ikke defer kan bruges.

Ressource hints

Ressource hints giver browseren forhåndsinformation om, hvad den snart skal bruge:

• preload: Kritiske ressourcer der er nødvendige for den aktuelle side (LCP-billede, kritisk font)
• prefetch: Ressourcer der sandsynligvis bruges på næste side (lav prioritet)
• preconnect: Opret forbindelse til et origin tidligt (Google Fonts, CDN)

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

Måling og monitoring

PageSpeed Insights (pagespeed.web.dev) viser både lab data (Lighthouse) og field data (CrUX) for en specifik URL.

Google Search Console — Core Web Vitals-rapporten viser aggregerede field data for sitet, opdelt i mobile og desktop, med URL-grupper der underperformer.

Lighthouse i Chrome DevTools giver detaljerede lab-data og konkrete forbedringssforslag direkte i browseren.

WebPageTest er et avanceret testværktøj med mulighed for test fra mange geografiske lokationer og på simulerede enheder.

Relaterede artikler

• Kode og teknisk SEO — den komplette guide
• Server og HTTP-responser
• JavaScript og rendering
• Indholdselementer i kode

---

Sidst opdateret: marts 2026. Denne artikel er en del af Stegger.dk’s SEO-ordbog.