Hvor meget påvirker sidens indlæsningshastighed din SEO-ranking i virkeligheden?

Sidens indlæsningshastighed påvirker din SEO-ranking mere end de fleste danske virksomheder er klar over — men det er heller ikke den eneste faktor der afgør, om du havner på side ét eller side tre. Sandheden er nuanceret: hastighed er et direkte rankingsignal, men vægten afhænger kraftigt af din niche, konkurrence og hvilke hastighedsmålinger der faktisk er dårlige. Denne artikel giver dig det fulde billede, så du ved præcis hvad du skal prioritere.

Indlæsningshastighed er blevet vigtigere for Google — men hvor vigtig?

Google bekræftede tilbage i 2010, at hastighed var et rankingsignal for desktop-søgninger — og siden da er betydningen kun vokset. Med introduktionen af Page Experience-signalet og Core Web Vitals som officielle rankingfaktorer er indlæsningshastighed nu direkte flettet ind i Googles algoritme på en måde, det ikke var tidligere.

Men det er vigtigt at forstå proportionerne. Google har selv udtalt, at relevans stadig er den primære faktor. Hvis din side er den klart mest relevante og autoritative for en given søgeforespørgsel, vil den stadig ranke godt — selv med en moderat hastighed. Hastighed bliver derimod afgørende når to sider er næsten ens på relevans og autoritet. Her kan Page Experience-signalet vippe vægten.

I praksis betyder det:

• En ekstremt langsom side (over 5-6 sekunder til første interaktion) vil blive straffet mærkbart, særligt på mobile enheder.
• En side der opfylder Core Web Vitals-tærskler (“Good”) har ingen direkte ulempe på hastighedsparametret.
• At gå fra “Good” til “exceptionelt hurtig” giver sandsynligvis ikke yderligere rankinggevinst — men gavner konverteringsraten.

Det er altså ikke sådan, at din side automatisk ryger til tops fordi den loader på 0,8 sekunder. Men er den langsom, kan du tabe terræn. Forstår du at arbejde strategisk med SEO over tid, giver det mere mening — læs gerne mere om Hvor lang tid tager SEO at virke? En realistisk tidslinje, som sætter hastighedsoptimering i et større perspektiv.

Core Web Vitals: hvad måler Google egentlig?

Core Web Vitals er Googles officielle ramme for at måle brugeroplevelsen på en webside. De består i 2026 af tre centrale målinger, der tilsammen giver et billede af, hvordan det rent faktisk føles at bruge en side — ikke blot om den teknisk set er loadet.

LCP — Largest Contentful Paint

LCP måler, hvor lang tid det tager for det største synlige element på siden at blive vist i skærmbilledet. Det er typisk et hero-billede, en stor tekstblok eller en video-thumbnail. Google anser under 2,5 sekunder som “Good”, 2,5-4,0 sekunder som “Needs Improvement” og over 4,0 sekunder som “Poor”.

LCP er den mest direkte forbundet med brugerens oplevelse af, om siden “loader hurtigt”. Det er også den måling, der oftest er problematisk for danske hjemmesider, fordi ukomprimerede billeder og tunge webfonts er udbredte synder.

INP — Interaction to Next Paint

INP (Interaction to Next Paint) erstattede FID (First Input Delay) og måler, hvor hurtigt siden reagerer visuelt på brugerens interaktioner — klik, tastetryk og swipes. God INP er under 200 millisekunder. INP er særligt relevant for dynamiske sider med meget JavaScript, f.eks. webshops med filterfunktioner eller interaktive formularer.

CLS — Cumulative Layout Shift

CLS måler, hvor meget elementerne på siden “hopper rundt” mens siden loader. Et lavt CLS-score (under 0,1) indikerer, at siden er stabil — brugerne klikker ikke ved et uheld på forkerte elementer fordi indhold pludselig skubber sig ned. Annoncer der loades sent, billeder uden specificerede dimensioner og webfonts der indsættes med forsinkelse er de typiske CLS-syndere.

Du kan læse mere om Core Web Vitals direkte hos web.dev (Googles udviklerdokumentation), som opdateres løbende med de nyeste tærskler og anbefalinger.

Hvad tæller IKKE som hastighedssignal?

Det er værd at nævne, hvad Google ikke bruger direkte som rankingsignal: den rå serverresponstid alene, PageSpeed Insights-score (den er diagnostisk, ikke direkte et signal), og antallet af HTTP-requests. Disse er vigtige at optimere fordi de påvirker Core Web Vitals indirekte — men de er ikke selvstændige rankingfaktorer.

Hvilke dele af indlæsningshastigheden påvirker din ranking mest?

Når vi ved, at Core Web Vitals er Googles målestok, kan vi prioritere hvilke tekniske forbedringer der faktisk rykker noget på rankingen — frem for dem der blot forbedrer et tal i en rapport.

Mobilhastighed vejer tungest

Google indekserer udelukkende mobilversionen af din side (mobile-first indexering). Derfor er det mobilscoren i Google Search Console og PageSpeed Insights, der er afgørende. Mange danske virksomheder optimerer primært til desktop — og opdager aldrig, at deres mobilside er markant langsommere.

LCP er dit primære fokuspunkt

Af de tre Core Web Vitals er LCP typisk den der har størst sammenhæng med ranking-forbedringer, fordi den er lettest at forbedre markant og har den klareste brugeroplevelses-effekt. De vigtigste LCP-syndere er:

• Store, ukomprimerede billeder (særligt hero-billeder)
• Manglende prioritering af LCP-elementet (fetchpriority-attribut)
• Langsom serverresponstid (Time to First Byte over 600ms)
• Render-blokkerende ressourcer (CSS og JavaScript der forsinker første render)

Hvad med TTFB?

Time to First Byte (TTFB) er serverens responstid — altså hvor hurtigt serveren sender det første byte af siden til brugerens browser. En dårlig TTFB (over 800ms) påvirker LCP direkte og bør adresseres, typisk ved hjælp af bedre hosting, CDN eller server-side caching. Mange danske hjemmesider på billig shared hosting lider under høj TTFB — her kan opgradering til en VPS eller managed WordPress-hosting give en mærkbar rankingforbedring.

CLS-problemer ses tit i praksis

Et højt CLS-score kan være svært at opdage manuelt, fordi det afhænger af, hvad der loades i realtid. Men Google samler CLS-data fra rigtige brugere via Chrome User Experience Report (CrUX) — det er disse data der bruges i rankingalgoritmen, ikke laboratoriedataene fra PageSpeed Insights alene.

Sådan måler du din egen indlæsningshastighed realistisk

Der er stor forskel på laboratoriemålinger og feltdata. For at forstå din faktiske SEO-situation skal du bruge begge typer.

Google Search Console

Under “Oplevelse” i Google Search Console finder du din sides Core Web Vitals-rapport baseret på rigtige brugerdata (CrUX-data). Dette er den vigtigste rapport til SEO-formål, fordi det er disse data Google faktisk bruger. Rapporten viser, hvilke URL-grupper der har “Poor”, “Needs Improvement” eller “Good” status — og du kan se separat status for mobil og desktop.

PageSpeed Insights

PageSpeed Insights kombinerer laboratoriedata (Lighthouse) med feltdata (CrUX). Laboratoriedataene er nyttige til at identificere specifikke tekniske problemer — de viser præcist hvilke ressourcer der forsinker din side og giver konkrete forbedringsforslag. Feltdataene viser din reelle performance baseret på rigtige brugere.

GTmetrix og WebPageTest

Disse tredjeparts-værktøjer tilbyder mere detaljerede analyser og mulighed for at teste fra servere i forskellige geografiske placeringer. GTmetrix er særligt brugervenligt til at identificere store billeder og unødvendige ressourcer. WebPageTest er mere teknisk men giver det mest detaljerede overblik.

Hvad skal du kigge efter?

1. Start med Google Search Console — er din status “Good” på mobil? Hvis ja, er du grundlæggende godt stillet rankingsmæssigt.
2. Er der “Poor” URL-grupper? Prioritér disse frem for at optimere sider der allerede performer godt.
3. Brug PageSpeed Insights til at identificere de specifikke problemer på de problematiske sider.
4. Mål igen efter optimering og vent 28 dage — CrUX-dataene opdateres på et rullende 28-dages vindue.

Det er i øvrigt relevant at tænke over hastighed allerede når du planlægger en ny hjemmeside. Læs mere om processen i Hvor lang tid tager det at få en ny hjemmeside?, hvor vi gennemgår hvad der typisk påvirker tidslinjen og kvaliteten.

De vigtigste optimiseringer som giver mest gevinst

Ikke alle hastighedsoptimeringer er skabt ens. Nogle kræver stor teknisk indsats for minimal gevinst — andre giver markant forbedring med relativ lille indsats. Her er de vigtigste prioriteret efter effekt.

1. Optimér billeder korrekt

Billeder er den hyppigste årsag til langsom LCP. Konkrete tiltag:

• Konvertér alle billeder til WebP eller AVIF-format (markant mindre filstørrelse end JPEG/PNG)
• Brug lazy loading (loading=”lazy”) på alle billeder der ikke er synlige i første skærmbillede
• Tilføj fetchpriority=”high” til dit LCP-element (det første store billede)
• Specificér altid bredde og højde på billedelementer for at undgå CLS

2. Brug et CDN

Et Content Delivery Network (CDN) distribuerer din hjemmesides filer fra servere tæt på brugeren. For danske hjemmesider med internationale besøgende er dette særligt relevant. Cloudflare tilbyder et gratis CDN der kan reducere TTFB markant og er relativt nemt at sætte op.

3. Minimer og udskyd JavaScript

JavaScript er den næststørste synder efter billeder. Tiltag med høj effekt:

• Udskyd ikke-kritisk JavaScript med defer eller async-attributter
• Fjern ubrugte JavaScript-biblioteker (tjek med Coverage-fanen i Chrome DevTools)
• Overvej at erstatte tunge jQuery-baserede funktioner med moderne vanilla JavaScript

4. Aktiver browsercaching og server-side caching

Caching sikrer at gentagne besøgende og Googles crawler ikke skal vente på at serveren genererer siden fra bunden hver gang. For WordPress-sider er plugins som WP Rocket eller LiteSpeed Cache effektive løsninger. Statiske HTML-sider er inherent hurtigere end dynamisk genererede sider.

5. Opgradér din hosting

Billig shared hosting er en af de mest undervurderede årsager til dårlig TTFB og dermed dårlig LCP. Hvis din TTFB konsekvent er over 800ms, er hosting-opgradering sandsynligvis den investering der giver størst gevinst pr. krone. Det er en overvejelse der ligner budgetspørgsmål i andre markedsføringsdiscipliner — ligesom du nøje overvejer dit budget til Google annoncering, bør du tænke strategisk over hostingomkostninger som en SEO-investering.

6. Reducér antallet af tredjepartsscripts

Chat-widgets, marketing-pixels, A/B-testingscripts og cookie-bannere kan tilsammen tilføje sekunder til din indlæsningstid. Gennemgå hvilke tredjepartsscripts der faktisk bruges aktivt, og fjern resten. Brug Tag Manager til at udskyde ikke-kritiske scripts til efter siden er loadet.

Ofte stillede spørgsmål

Kan jeg ranke på side ét med en langsom hjemmeside?

Ja, det er muligt — særligt i nichekategorier med lav konkurrence eller hvis din side er ekstraordinært autoritativ og relevant. Men i konkurrenceudsatte markeder vil en langsom side (specielt “Poor” Core Web Vitals) give dig en strukturel ulempe. Jo mere kompetitivt dit marked er, desto mere tæller hvert eneste rankingsignal, inklusive hastighed.

Hvad er den vigtigste enkeltstående forbedring jeg kan lave?

For langt de fleste danske hjemmesider er billedoptimering det hurtigste quick-win. Konvertér ukomprimerede JPEG-billeder til WebP, tilpas dimensionerne til faktisk visningsstørrelse, og tilføj fetchpriority=”high” til dit primære hero-billede. Disse tre ting kan alene reducere din LCP med 1-2 sekunder på mange sider og kræver ingen serverinfrastruktur-ændringer.

Er PageSpeed Insights-scoren direkte et rankingsignal?

Nej — PageSpeed Insights-scoren (0-100) er et diagnostisk værktøj, ikke et direkte rankingsignal. Google bruger feltdata fra rigtige brugere (CrUX-data) som rankingsignal, ikke laboratoriedata. En side kan have en Lighthouse-score på 65 og stadig have “Good” Core Web Vitals i Search Console, fordi rigtige brugere oplever siden som hurtig. Fokusér på Search Console-rapporten frem for Lighthouse-scoren alene.

Hvor lang tid tager det at se rankingforbedringer efter hastighedsoptimering?

CrUX-dataene opdateres på et rullende 28-dages vindue, så det tager minimum 4 uger at se ændringerne i Google Search Console. Selve rankingeffekten kan tage yderligere 2-8 uger at manifestere sig, afhængigt af hvor ofte Google gencrawler din side og opdaterer rankingdata. Forvent ikke resultater inden for den første måned efter optimering — men mål præcist for at dokumentere effekten.