En waterfall er et af de bedste værktøjer til performance-arbejde, fordi den viser rækkefølgen: hvad der starter først, hvad der blokerer, og hvad der venter.
Hvis du kun kigger på en score, misser du ofte årsagen. En waterfall tvinger dig til at svare på de vigtigste spørgsmål:
- Kom HTML hurtigt? (TTFB)
- Hvornår blev CSS og kritisk JS hentet?
- Hvornår startede LCP-ressourcen?
- Er der render-blocking?
- Er der tredjepart der stjæler “early bandwidth”?
Artiklen her er et praktisk kompas: du kan bruge den i Chrome DevTools (Network), i Lighthouse’s “network”-visning, eller i WebPageTest. Den supplerer Lighthouse vs CrUX - waterfall forklarer hvorfor en side opfører sig som den gør i én kørsel; feltdata viser om problemet er repræsentativt for brugerne.
Start med det grove
- Er TTFB høj?
- Hvad er LCP-elementet, og hvornår starter download?
- Er der render-blocking CSS/JS?
Fire typiske mønstre (hvad du ser → hvad det betyder)
| Mønster i waterfall | Typisk betydning | Næste skridt |
|---|---|---|
| Lang waiting/TTFB på dokumentet | Server, DB, manglende page cache, cold origin | TTFB/cache-guide, Cache-Control |
| LCP-billede starter sent eller efter mange requests | Forkert prioritet, for sent discovery, eller for mange domæner foran | Preload med måde, færre hops, LCP-guide |
| Tyk blok af CSS/JS før første paint | Render-blocking | Fjern render-blocking, defer/async |
| Mange parallelle requests til tredjepart tidligt | Bandwidth/kø til analytics, tags, fonts | Udskyd, self-host hvor muligt, reducer antal domæner |
Når du har navngivet mønsteret, undgår du at «optimere billeder» mens dokument-HTML stadig er flaskehalsen.
Hvad er en waterfall egentlig?
Waterfall’en (typisk i WebPageTest eller DevTools Network) viser hver request som en række faser:
- DNS lookup
- connection/TLS
- waiting/TTFB
- download
Det der gør en waterfall værdifuld er ikke bare “hvor lang tid tog det”, men:
- om requests er serialiseret (venter på hinanden)
- hvad der er prioriteret af browseren
- hvilke requests der ligger i critical path
Hvad betyder felterne i praksis? (hurtig oversættelse)
Når du kigger på en request-linje i en waterfall, vil du typisk se noget a la:
- DNS: tid brugt på at finde IP-adresse
- Connect/TLS: tid til at etablere forbindelse og handshake
- Waiting/TTFB: tid fra request sendes, til første byte kommer tilbage
- Download: tid til at hente selve responsen
Det hjælper at tænke sådan her:
- Hvis DNS/Connect/TLS er højt: latency/forbindelse – preconnect kan nogle gange hjælpe, men CDN/edge og færre domæner hjælper ofte mere.
- Hvis TTFB er højt: server/origin/caching er ofte roden.
- Hvis Download er højt: filstørrelse og komprimering (Brotli/minificering) eller billedformat/dimensioner.
Step-by-step metode (hurtig og robust)
Step 1: Find dokument-requesten (HTML)
Start med den første request til dokumentet.
Spørg:
- Er TTFB høj? (waiting er stor)
- Er der redirects før dokumentet? (unødvendig latency)
Hvis HTML er langsom, giver det sjældent mening at finpudse billeder først. Fix TTFB/caching tidligt.
Step 1.5: Kig efter redirects og “unødvendige hop”
Redirects kan være usynlige i en score, men tydelige i waterfall:
- http → https
- non-www → www (eller omvendt)
- trailing slash redirects
Hvert hop koster typisk mindst én roundtrip. På mobil kan det være dyrt. Målet er: så få redirects som muligt på landingssider.
Step 2: Find hvad der blokerer rendering
I de første sekunder leder du efter:
- CSS der loader tidligt og er stor
- JS i head uden
deferder kan blokere parsing
Hvis du ser store CSS/JS requests helt tidligt, er der en stor chance for at FCP/LCP bliver dårligere.
Step 3: Find LCP-ressourcen og dens starttidspunkt
LCP er ofte et hero-billede. I waterfall’en er det vigtigste:
- hvornår starter download?
- var der noget der burde have startet den tidligere? (fx preload)
- er billedet for stort? (download tiden er lang)
Hvis LCP først starter sent, er det ofte fordi browseren først “opdager” ressource sent: HTML/CSS skal parses før billedet findes.
Step 3.5: Afklar om det er “discovery” eller “download”
Det er to helt forskellige problemer:
- Discovery-problem: LCP-ressourcen starter sent (browseren opdager den sent).
- Download-problem: LCP-ressourcen starter tidligt, men tager lang tid at hente.
Discovery løses ofte med:
- flyt hero indhold tidligere i HTML
- undgå at hero-billede kun findes via tung CSS/JS
- målrettet preload
Download løses ofte med:
- mindre fil (AVIF/WebP, bedre dimensioner)
- bedre caching
- CDN/edge
Step 4: Kig efter tredjepart tidligt
Tredjepart kan være:
- analytics
- consent platform
- chat widgets
- AB-test
Hvis de loader tidligt, kan de:
- øge TTFB (hvis de påvirker server-rendering)
- stjæle netværksprioritet
- skabe CPU-arbejde og påvirke INP
Step 5: Tjek cache og gentagne besøg
Lav to runs:
- kold cache
- varm cache
Hvis varm cache stadig er dårlig, er problemet ofte:
- HTML ikke cached
- server/DB langsom
- render-blocking / CPU (uafhængigt af cache)
Et “diagnose flow” du kan bruge hver gang
Hvis du vil have en fast rutine, kan du bruge denne rækkefølge:
- HTML først: er TTFB høj, eller er der redirects?
- Render-blocking: ligger der stor CSS/JS tidligt?
- LCP: starter LCP-ressourcen tidligt nok?
- Størrelser: er hero-billedet og kritiske assets for store?
- Tredjepart: stjæler de tidligt båndbredde/CPU?
- Repeat view: bliver det bedre med varm cache? Hvis ikke, mangler caching eller du har CPU/rendering-problemer.
Kig efter klassikere
- Store billeder uden responsive størrelser
- Mange tredjeparts requests tidligt
- Lange “stille perioder” før noget sker
Typiske mønstre og hvad de betyder
“Alt venter på HTML”
Hvis alt starter sent, er HTML/TTFB problemet. Fokus: caching, server, CDN/edge.
“CSS er kæmpe og tidlig”
Hvis et stort stylesheet ligger meget tidligt, kan det blokere rendering. Fokus: critical CSS, trim CSS, split.
“LCP-billedet starter først efter 2–3 sek.”
Ofte et discovery-problem:
- billedet findes sent i DOM
- hero billedet ligger i CSS background uden preload
- eller scripts ændrer DOM før hero kommer frem
“Mange tredjepart requests i første sekund”
Fokus: udskyd, fjern, eller begræns tredjepart. Det hjælper ofte både LCP og INP.
“LCP-billedet er stort, men kommer fra cache på repeat view”
Hvis repeat view er markant bedre, er caching sandsynligvis OK. Så kan du fokusere på:
- billedstørrelse/dimensioner for first view
- preload/discovery hvis download starter sent
“Alt ser fint ud, men brugeren siger siden er ‘tung’”
Hvis waterfall ikke viser store netværksproblemer, kan flaskehalsen være:
- CPU (store bundles, hydration, long tasks)
- INP/interaction path
Så skal du over i DevTools Performance og kigge på main thread. Se INP-artiklen og guiden om JavaScript når du går fra netværk til CPU.
En simpel prioritering du kan bruge hver gang
- Fix redirects og TTFB (HTML)
- Fix render-blocking CSS/JS
- Fix LCP-ressource (format, størrelse, prioritet)
- Fix tredjepart
- Finpuds caching og preload/preconnect (med omtanke)
WebPageTest: filmstrip og sammenligning
I WebPageTest får du ofte filmstrip og video af visningen: det er nyttigt når “alt ser fint ud” i tal, men siden stadig føles langsom - du kan se hvornår første meningsfulde pixels vises. Brug first view vs repeat view og forskellige lokationer for at efterligne CDN-edge og brugere langt fra din origin.
Relateret
Relaterede blogindlæg
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
2025-11-14Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
2026-03-30Reverse 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.
Hvordan tredjeparts scripts gør din hjemmeside langsom
2026-03-26Få overblik over hvordan chat widgets, tracking, consent, video embeds og andre tredjeparts scripts påvirker LCP, INP, CLS og TTFB.
Cookie banner og Core Web Vitals: den oversete årsag til dårlig brugeroplevelse
2026-03-24Se hvordan cookie bannere og consent scripts kan påvirke load, layout og interaktion, og lær hvordan du undgår at de ødelægger brugeroplevelsen.
Fetchpriority, preload og preconnect: hvornår de hjælper og hvornår de gør skade
2026-03-23Lær hvornår fetchpriority, preload og preconnect faktisk forbedrer load, og hvornår de bare skaber mere støj og dårlig prioritering i browseren.
Cache-Control forklaret: sådan bruger du caching til lavere TTFB
2026-01-25Lær hvordan Cache-Control påvirker HTML, CSS, JavaScript og billeder, og få en praktisk gennemgang af caching, TTFB og klassiske fejl.
FAQ
Er DevTools Network nok, eller skal man bruge WebPageTest?
DevTools er godt til hurtige checks. WebPageTest er ofte bedre til stabil reproducering, prioritering og video/filmstrip. Begge er nyttige – brug DevTools til hurtigt at forstå en side, og WPT til at sammenligne før/efter på samme profil.
Skal man altid preload’e LCP-billedet?
Nej. Preload hjælper især ved discovery-problemer (billedet opdages sent). Forkert eller for meget preload kan stjæle båndbredde fra vigtigere downloads. Brug det målrettet og mål i waterfall.
Hvad hvis jeg har et CDN – skal jeg stadig kigge på waterfall?
Ja. CDN kan forbedre TTFB og asset-levering, men waterfall afslører stadig om HTML faktisk caches ved edge, om hero/LCP starter tidligt, og om render-blocking eller tredjepart skaber delays.
Næste skridt i samme emne
Fortsæt fra forklaring til handling med guides, emner og ordbog.
