Kort fortalt: Render-blocking betyder at browseren venter med at vise indhold, fordi den først skal hente og behandle bestemte CSS- eller JavaScript-filer.
Hvad betyder det?
Browseren stopper tidlig rendering indtil den har hentet og behandlet bestemte ressourcer.
I praksis handler det om “critical path”: hvis browseren ikke kan lave layout og paint, før CSS er klar, vil den ofte vælge at vente. Og hvis JavaScript blokerer parsing eller ændrer DOM tidligt, kan det også forsinke hvad der bliver vist.
Hvilken indflydelse har render-blocking?
Når du har render-blocking ressourcer, ser du ofte:
- højere FCP (første indhold kommer sent)
- højere LCP (det vigtigste indhold kommer sent)
- mere varians mellem besøg (tredjepart og netværk påvirker mere)
På mobil kan det være ekstra tydeligt, fordi CPU og netværk er langsommere.
Hvornår opstår render-blocking typisk?
De mest almindelige scenarier:
- store globale stylesheets der loader i
<head> - mange plugins/tema-assets i CMS’er
- scripts der ligger i head uden
defer - frameworks der loader meget JS tidligt før første paint
Typiske årsager
- Stor CSS uden critical split
- Synkron JavaScript i head
Typiske forbedringer
- Extract critical CSS
- Udskyd ikke-kritisk JS (defer) og CSS (media/async patterns)
Sådan identificerer du render-blocking (praktisk)
- PageSpeed Insights/Lighthouse: “Eliminate render-blocking resources”
- DevTools Network: se hvilke CSS/JS der starter tidligt og hvor store de er
- DevTools Performance: se om der går lang tid før første paint, og hvad der kører
Det vigtigste er at finde: hvilke ressourcer der ligger i den kritiske sti, og om de reelt er nødvendige for første viewport.
Konkrete optimeringer (i prioriteret rækkefølge)
1) Critical CSS (above the fold)
I stedet for at blokere med alt CSS kan du:
- inline kritisk CSS for første viewport
- load resten efterfølgende
Det reducerer ventetid før første render.
2) Udskyd ikke-kritisk JavaScript
Hvis scripts ikke er nødvendige for første paint:
- brug
defer(eller load efterDOMContentLoaded) - split bundles og undgå store “global init”-scripts
3) Fjern unused CSS/JS
På mange sites er der assets der ikke bruges på den konkrete side, men stadig bliver loadet.
Konkrete ting:
- load kun CSS/JS hvor det bruges (route-level)
- ryd op i plugins og tredjepart
4) Pas på tredjepart i head
Consent/AB-test/analytics kan være “render-blocking” indirekte, hvis de:
- injicerer styles/scripts tidligt
- laver DOM-manipulation før paint
Udskyd og begræns hvor det giver mening.
Tjekliste
- De vigtigste sider har minimal CSS/JS i critical path
- Ikke-kritisk JS er deferred
- CSS er delt i critical + resten
- Unused assets er fjernet eller gjort betingede
FAQ
Er render-blocking altid “forkert”?
Nej. Kritisk CSS er ofte nødvendigt for at browseren kan lave layout og paint korrekt.
Problemet opstår når du blokerer med **store** ressourcer der ikke er nødvendige for første viewport – fx et kæmpe globalt stylesheet eller synkron JavaScript i `<head>`.
Målet er ikke “ingen blocking”, men “kun det der er nødvendigt tidligt”.
Hvorfor flytter LCP sig ikke selvom jeg defer’er scripts?
Fordi LCP også kan være begrænset af CSS, billeder, TTFB eller paint/CPU.
`defer` kan fjerne én type blokering (synkron JS der stopper parsing), men hvis CSS stadig er render-blocking, eller hvis LCP-ressourcen opdages sent, kan LCP være uændret. Brug waterfall og LCP-opdelingen i Lighthouse til at se om flaskehalsen er netværk, discovery eller render delay.
Hvad er den mest robuste løsning på render-blocking CSS?
At splitte det du har brug for “above the fold” fra resten.
Praktisk betyder det typisk: et lille kritisk lag (critical CSS) til header/hero/typografi, og så resten af CSS efterfølgende. Det er ofte mere holdbart end mange små hacks i `<head>`.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Fjern render blocking CSS og JavaScript for hurtigere første visning
Lær hvordan du reducerer render blocking fra CSS og JavaScript, så siden viser indhold hurtigere og giver bedre FCP og LCP.
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.
Brug fetchpriority og preload rigtigt på de vigtigste ressourcer
Få en praktisk guide til hvordan du bruger fetchpriority og preload på billeder, fonts og CSS uden at overstyre browseren forkert.
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.
Fetchpriority, preload og preconnect: hvornår de hjælper og hvornår de gør skade
Læ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.
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
