En langsom eller “hakkende” hjemmeside får flere til at opgive — især på mobil. Google bruger Core Web Vitals (LCP, CLS og INP) som en del af page experience-signalerne. Hastighed erstatter ikke godt indhold, men dårlig performance kan koste både kunder og synlighed. Start med de største filer, unødvendigt JavaScript og tung tredjepart.
Hvorfor fart er en forretningssag
Når en side føles træg, tøver folk. De lukker fanen, åbner en konkurrent eller ringer til en anden. Det gælder takeaway-bestilling, booking og almindelige kontaktformularer. Hastighed er ikke kun “noget for udviklere” — det er friktion i kunderejsen.
Samtidig dokumenterer Google, at page experience og Core Web Vitals indgår i, hvordan sider vurderes i søgeresultaterne. Det betyder ikke, at den hurtigste side altid vinder. Det betyder, at dårlig oplevelse kan trække ned, især når konkurrenterne ellers er jævnbyrdige.
Core Web Vitals på almindeligt dansk
Core Web Vitals er tre målinger af, hvordan en side opleves: hvor hurtigt det primære indhold viser sig, hvor stabilt layoutet er, mens det loader, og hvor hurtigt siden reagerer på brugerens handlinger. Google og web.dev beskriver dem som LCP, CLS og INP.
LCP — Largest Contentful Paint
LCP måler, hvor lang tid der går, før det største synlige indholdselement (ofte et hero-billede eller en stor overskrift) er malet på skærmen. Høj LCP opleves som “siden er blank / loader stadig”.
Typiske årsager: for store billeder, langsom server, render-blokerende CSS/JS, eller at LCP-elementet loades sent (fx forkert lazy-load på hero). Ret LCP ved at komprimere og dimensionere det rigtige billede, prioritere det i load-rækkefølgen og mindske blokering af first render.
CLS — Cumulative Layout Shift
CLS måler, hvor meget indholdet hopper, mens siden loader. Du er ved at trykke på “Bestil”, og pludselig skubber et banner eller en skrifttype knappen ned. Det er CLS i praksis.
Typiske årsager: billeder uden bredde/højde, annoncer og cookie-banners, der indsættes sent, webfonts der bytter glyph-bredde, dynamisk indhold over folden. Reserver plads til medier og UI, load fonts stabilt, og undgå at skubbe primary content ned efter første paint.
INP — Interaction to Next Paint
INP måler, hvor hurtigt siden responderer visuelt efter en interaktion (klik, tap, tast). Dårlig INP føles som “jeg trykkede, men intet skete”. Den erstattede den ældre FID-metrik som Core Web Vital for interaktivitet.
Typiske årsager: tung JavaScript på hovedtråden, store frameworks der hydrater for meget, chat- og tracking-scripts, lange opgaver ved menu-open eller filterklik. Del arbejde op, udskyd det der ikke behøver at køre med det samme, og fjern scripts I ikke bruger.
Billeder: den hyppigste lavthængende frugt
Upload ikke et 4000 px photo til en 400 px plads. Brug moderne formater, hvor det giver mening, og server forskellige størrelser til mobil og desktop. Hero-billeder skal prioriteres; neden-for-fold-billeder kan oftere lazy-loades.
Baggrunde og dekorative lag behøver ikke samme skarphed som produkt- eller madfotos. Vælg bevidst: stemning må ikke koste tre sekunder på 4G i metroen.
- Korrekte dimensioner og kompression
- Undgå at lazy-loade LCP-hero
- Brug srcset/sizes eller tilsvarende, når I har flere breakpoints
- Video kun når det er nødvendigt — og ikke autoplay med tung fil uden kontrol
Skrifttyper
Webfonts er fine, når de er begrænset og loadet fornuftigt. Mange vægtvarianter og store families forsinker tekst og kan skabe layout-skift. Subset fonts, begræns vægte, og vælg font-display-strategi, der matcher designet uden lange usynlige tekster.
Systemfonts er ikke forbudt. Hvis brandet kræver en specifik type, så betal prisen bevidst — og mål effekten.
JavaScript og tredjepart
Hver chat, heatmaps, A/B-test, pixel og embed koster. Nogle er værdifulde. Mange er kopieret ind “fordi vi altid har haft dem” og kører på alle sider. Audit jeres tags: hvad bruges aktivt? Hvad kan vente til efter interaktion? Hvad kan begrænses til bestemte sider?
Consent-banners skal selv være lette. Et banner, der skubber hele layoutet og loader fem vendors synkront, skader både CLS og tillid.
CMS, plugins og “performance-debt”
Mange sites bliver langsomme over tid: ekstra plugins, ubegrænsede slider-biblioteker, ubrugte CSS-frameworks og gamle shortcodes. Et redesign er en chance for at skære ind til det, I faktisk bruger. Vedligehold er den anden halvdel: fjern det, der ikke længere tjener en side.
Hvis I bygger specialudviklet, er ansvaret det samme — bare i jeres egen kode. Bundle-størrelse, unødvendig client-side rendering og store afhængigheder skal prioriteres bevidst, især på mobil.
Hosting, caching og CDN
Et hurtigt origin-svar (TTFB) og caching af statiske assets hjælper alle metrics. CDN bringer filer tættere på brugeren. Hosting alene løser dog ikke frontend-fedme.
Ved valg af hosting: kig på HTTPS, oppetid, backup og om I kan cache HTML/assets fornuftigt for jeres CMS — ikke kun på marketing-claims om “lynende hurtighed”.
Tracking uden at kvæle siden
Analytics, ads-pixels og remarketing er ofte nødvendige — men de behøver ikke at loade synkront på første byte. Brug tag manager fornuftigt, begræns tags til de sider der har brug for dem, og respekter consent. Et site der “måler alt” på alle routes betaler ofte med dårligere INP og længere LCP.
Efter go-live: sammenlign feltmålinger før og efter I tilføjer nye scripts. Hvis en ny chat-widget koster synlig forsinkelse på mobil, skal gevinsten kunne forsvares — ellers skal den ud eller begrænses.
Sådan arbejder I praktisk med forbedringer
1) Mål mobil først (lab + Search Console-felt, når data findes). 2) Identificér den værste side-type (forside, landingsside, menukort). 3) Ret den største årsag. 4) Mål igen. 5) Først derefter finpuds.
Kombiner med den tekniske SEO-tjekliste før lancering, så performance ikke er det eneste, I kigger på — crawl og indeksfejl kan skjule selv en hurtig side.
Blank hero længe
- Mistænkt metrik
- LCP
- Første check
- Billedstørrelse, prioritet, server
Knapper hopper
- Mistænkt metrik
- CLS
- Første check
- Billedmål, fonts, banners
Klik føles døde
- Mistænkt metrik
- INP
- Første check
- JS-tungde, tredjepart, long tasks
Kun dårlig på mobil
- Mistænkt metrik
- Flere
- Første check
- Store assets + CPU på telefon
| Symptom | Mistænkt metrik | Første check |
|---|---|---|
| Blank hero længe | LCP | Billedstørrelse, prioritet, server |
| Knapper hopper | CLS | Billedmål, fonts, banners |
| Klik føles døde | INP | JS-tungde, tredjepart, long tasks |
| Kun dårlig på mobil | Flere | Store assets + CPU på telefon |
Hvad hastighed ikke kan
En hurtig side med uklart tilbud konverterer stadig dårligt. En hurtig side med tyndt indhold rangerer ikke magisk lokalt i København. Hastighed fjerner friktion; den erstatter ikke strategi, indhold og tillid.
Prioritér derfor i den rækkefølge, der matcher jeres flaskehals: hvis ingen forstår tilbuddet, ret budskabet først. Hvis budskabet er klart, men siden hakker på mobil, er performance næste skridt. Hvis begge er på plads, kan SEO og Ads skalere det, der allerede virker.
Hos CPH WebDesigners arbejder vi med performance som del af webdesign, SEO og drift — med konkrete flaskehalse, ikke med tomme “vi gør dig #1”-løfter.
Ofte stillede spørgsmål
- Er PageSpeed-score det samme som Core Web Vitals?
- Nej. Lab-scores i værktøjer er vejledende. Core Web Vitals i Search Console bygger på feltmålinger fra rigtige brugere (CrUX), når der er tilstrækkelig trafik. Optimér den reelle oplevelse — ikke kun en enkelt desktop-score.
- Hvad skal jeg rette først?
- Typisk det største above-the-fold-billede (LCP), layout-skift fra fonts/banners (CLS) og tung JavaScript eller tredjepart, der forsinker klik (INP). Mål før/efter, så I ved, hvad der virkede.
- Kan hosting alene løse hastighed?
- God hosting og CDN hjælper, men redder ikke en side med 8 MB hero-video, tre chat-widgets og synkron tracking. Hastighed er et samspil mellem infrastruktur, frontend og hvilke scripts I tillader.