Kort fortalt: Speed Index beskriver hvor hurtigt indholdet på siden bliver visuelt udfyldt over tid. I stedet for at fokusere på ét tidspunkt (som FCP eller LCP), ser Speed Index på den samlede visuelle progression.
Hvad bruges det til?
- At forstå den samlede visuelle indlæsning, ikke kun et enkelt punkt.
Typiske forbedringer
- Reducér render-blocking
- Prioritér kritiske assets
Hvilken indflydelse har Speed Index?
Speed Index korrelerer ofte med brugerens “mavefornemmelse”:
- Hvis siden gradvist udfyldes hurtigt, føles den responsiv.
- Hvis siden står stille længe og så pludselig “popper” indhold ind, føles den langsom, selv hvis LCP ikke er katastrofal.
På content-sites kan Speed Index blive dårlig af:
- store CSS bundles der blokerer
- tunge hero-billeder
- mange tredjeparts requests tidligt
Hvordan skal man tænke Speed Index i praksis?
Speed Index er særligt nyttig, når du prøver at forstå “følelsen” af load:
- får brugeren gradvist mere at kigge på?
- eller står siden stille og popper indhold ind sent?
To sider kan have nogenlunde samme LCP, men meget forskellig Speed Index, fordi den ene har en jævn progression og den anden har en lang “stille periode”.
Hvornår blev Speed Index brugt?
Speed Index er især kendt fra WebPageTest, hvor man har brugt video/visuel progression til at måle oplevet hastighed. Det er stadig et nyttigt supplement til Core Web Vitals, især når du vil se “hvordan” siden loader, ikke kun “hvornår”.
Sådan måler du Speed Index
- WebPageTest (klassisk)
- Nogle performance-værktøjer rapporterer også lignende visuelle metrikker
Hvis du vil bruge det praktisk, så kig samtidig på:
- TTFB
- FCP/LCP
- waterfall (hvad blokerer tidligt)
Typiske årsager til dårlig Speed Index
Her er de mønstre der går igen på mange sites:
- store render-blocking stylesheets
- hero-billede der opdages sent eller er for stort
- mange tredjeparts scripts tidligt
- høj TTFB (HTML kommer sent, så intet kan starte)
Speed Index er derfor ofte et “samlet signal” om at critical path ikke er optimeret.
Konkrete optimeringer (praktisk)
1) Fjern render-blocking ressourcer
- critical CSS
- udskyd ikke-kritisk JS
- trim CSS/JS
2) Optimer billeder i første viewport
- AVIF/WebP
- responsive størrelser
- undgå at lazy-loade hero
3) Begræns tredjepart tidligt
- load efter consent/efter load, hvis muligt
- fjern det der ikke er nødvendigt
4) Caching og CDN
Hvis du får hurtigere TTFB og hurtigere assets, ser du ofte bedre visuel progression.
En praktisk prioritering
Hvis du vil forbedre Speed Index uden at gøre det komplekst, så gør dette i rækkefølge:
- Reducér TTFB (caching/edge)
- Fjern render-blocking (critical CSS, defer)
- Optimér hero/LCP-billedet (format, størrelse, prioritet)
- Fjern/udskyd tredjepart tidligt
Når de fire ting er på plads, bliver visuel progression næsten altid bedre.
FAQ
Skal man optimere for Speed Index?
Det kan være nyttigt som supplement, men du bør primært styre efter Core Web Vitals (LCP/INP/CLS).
Brug Speed Index til at forstå visuel progression (hvornår siden “får liv”), og til at spotte render-blocking/TTFB-problemer, hvor brugeren ser en “tom” side længe.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Gør hero til LCP: sådan ændrer du struktur, CSS og prioritering
Hvis LCP bliver en tilfældig paragraf i stedet for hero, får du både dårligere tal og en måling der ikke matcher brugerens første indtryk. Her er en konkret metode til at få hero (H1/billede) til at blive LCP – uden at snyde.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.
Hvordan du spotter render delay (uden at stirre på score)
Render delay er ofte grunden til at LCP bliver 1–2 sekunder for sent, selv når TTFB ser fin ud. Her er metoden til at finde årsagen hurtigt – og vælge den rigtige type fix.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
