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.

Tærskler for LCP

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) og billeder uden forudindlæsning (preload) er de hyppigste årsager.

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.

Tærskler for INP

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 er den primære årsag. Lang task-kørsel der blokerer for UI-opdateringer, for mange JavaScript event handlers og komplekse DOM-opdateringer ved interaktion bidrager alle.

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.

Tærskler for CLS

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 er den hyppigste årsag. Reklamer og embeds der indsættes dynamisk, web fonts der loades sent og forskubber tekst (FOUT/FOIT), og indhold der indsættes dynamisk over eksisterende indhold giver alle layout shifts.

Field data vs Lab data

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

Lab data (syntetisk data)

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

Field data (real user monitoring, RUM)

Field data er 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, for eksempel 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.

CSS og render-blocking

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 gælder: 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

Artikler i dette emne

• Animation performance
• Browser rendering pipeline
• CLS-problemer
• Core Web Vitals
• CSS containment
• CSS grundlæggende
• Font-optimering
• HTTP/2 og HTTP/3
• Billedoptimering
• INP-optimering
• JavaScript bundle-optimering
• Kritisk renderingsti
• Latency
• Lazy loading
• LCP-optimering
• Long Tasks og LoAF
• Navigation og resource timings
• PageSpeed og SEO
• Performance budgets
• Performance timings
• Resource hints
• Responsive images
• Responsivt design
• RUM vs. syntetisk monitoring
• Service Workers
• Speculative loading
• Startup performance
• Tredjeparts-scripts og performance
• Tredjepartsscripts
• TTFB og hosting
• Video performance
• Viewport tag
• Web Workers

---

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