Trin-for-trin
Identificér render-blocking CSS og JavaScript i Lighthouse eller PageSpeed Insights.
Udtræk og prioriter critical CSS for første viewport, og udskyd resten af CSS.
Sæt ikke-kritisk JavaScript til defer og fjern scripts der ikke er nødvendige for første render.
Genmål FCP/LCP og bekræft i waterfall at kritiske ressourcer starter tidligere.
Målet
At få noget på skærmen hurtigt og prioritere det indhold brugeren ser først.
Render-blocking handler om prioritering: browseren skal hurtigst muligt kunne male første version af siden. Hvis kritiske ressourcer drukner i ikke-kritiske filer, bliver både FCP og LCP langsommere - selv når “total vægt” ser acceptabel ud.
Denne guide er til dig der kan ændre hvordan CSS og JS inkluderes (build, tema, eller template). Den supplerer ordbog: render-blocking og critical CSS.
Før du går i gang
- Notér nuværende FCP/LCP (Lighthouse) og tag et screenshot af Network waterfall - du skal kunne se hvilke filer der ligger først.
- Afgør om problemet er for meget CSS (typisk ét stort stylesheet) eller synkron JS i
<head>. - Lav ændringer på staging; renderfejl i CSS kan ødelægge hele layoutet, så du skal kunne rulle tilbage.
Diagnose: find hvad der blokerer
Brug Lighthouse/PageSpeed og waterfall-visning i DevTools:
- hvilke CSS-filer bliver hentet først?
- er der synkrone scripts i head?
- hvor lang tid tager DNS, connection, request og download?
Hvis du ser mange tidlige requests, som ikke er nødvendige for “above the fold”, har du et prioriteringsproblem.
Trin-for-trin
- Find render-blocking ressourcer (Lighthouse/PSI: Opportunities)
- Extract/inline critical CSS
- Udskyd ikke-kritisk JS (defer) og fjern unødvendige scripts
- Sørg for at bundling og caching er korrekt
Trin 1: Kortlæg critical path
Lav en liste over hvad der er kritisk til første viewport:
- basis layout
- typografi
- farver/spacing til hero og navigation
Alt andet er sekundært og kan vente.
Trin 2: Prioritér critical CSS
Målet er at browseren hurtigt kan style første skærm.
Praktisk:
- hold critical CSS lille
- undgå duplikering mellem inline og hovedstylesheet
- mål FCP/LCP efter hver ændring
Trin 3: Udskyd eller fjern ikke-kritisk JavaScript
Ikke al «blocking» er lige alvorlig: en lille kritisk CSS-fil kan være acceptabel, mens et megabyte-tema der blokerer første paint er det ikke. Brug DevTools Coverage til at se ubrugt CSS/JS - fjern døde regler og dependencies der stadig loader i én stor fil. Kombinér med defer/async på scripts der ikke skal køre før efter synligt indhold.
JavaScript i head uden defer kan stoppe parsing.
Praktiske forbedringer:
- tilføj
defertil scripts der ikke er nødvendige med det samme (ellertype="module"for ES modules, som deferrer implicit i moderne browsere) - fjern scripts der ikke giver forretningsværdi
- load feature-kode først ved interaktion
Vigtige undtagelser: Scripts der læser/skriver DOM tidligt kan kræve en bestemt rækkefølge. Test kritiske flows (checkout, login, menu) efter du flytter scripts - INP og funktionalitet skal begge holde.
Trin 4: Oprydning i bundling og caching
Selv godt prioriteret CSS/JS kan være tungt.
Derfor:
- split bundles
- fjern dead code
- cache versionerede assets længe
Typiske fejl
- store frameworks/styles der loades globalt uden behov
- tredjeparts scripts i head
- for mange webfonts og varianter i critical path
- manglende preload af faktisk kritiske ressourcer
- inline alt for meget CSS “fordi det er hurtigere” - du kan ende med uoverskuelig HTML og dårlig cachebarhed; hold critical CSS lille
Sådan kontrollerer du resultatet
- Kør Lighthouse igen og sammenlign FCP og LCP - ikke kun Total Blocking Time.
- I DevTools Network: bekræft at det første meningsfulde indhold kommer tidligere i waterfall.
- Tjek at siden stadig ser korrekt ud på mobil og desktop (critical CSS kan være skrøbeligt).
- Hvis du har fjernet eller udskudt JS, test klik, formularer og tredjepart der afhænger af load-rækkefølge.
Praktisk checkliste
- Critical CSS dækker kun første viewport
- Ikke-kritiske scripts er udskudt
- Waterfall viser tidligere start på kritiske requests
- FCP/LCP er forbedret efter ændringer
Relateret
Relaterede guides
Gør hero til LCP: sådan ændrer du struktur, CSS og prioritering
2026-04-01Hvis 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
2026-03-23Få en praktisk guide til hvordan du bruger fetchpriority og preload på billeder, fonts og CSS uden at overstyre browseren forkert.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
2026-04-02Læ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.
Sådan fejlsøger du LCP fra start til slut
2026-03-27Følg en praktisk arbejdsgang til at finde årsagen til høj LCP, fra serverrespons og render blocking til billeder, prioritering og netværksrækkefølge.
Fjern eller udsæt tunge tredjeparts scripts uden at ødelægge funktionalitet
2026-03-26Følg en praktisk guide til at finde, vurdere og udsætte tredjeparts scripts, så de ikke ødelægger LCP, INP og den samlede brugeroplevelse.
Sådan finder du lange tasks i DevTools og forbedrer INP
2026-03-25Lær hvordan du bruger DevTools til at finde lange tasks, tunge event handlers og JavaScript der gør siden træg at bruge.
FAQ
Hvad betyder render-blocking i praksis?
Det betyder at browseren bliver nødt til at vente på bestemte ressourcer, før den kan vise første synlige indhold. Typisk gælder det CSS i head og synkron JavaScript.
Skal al CSS inlines for at blive hurtig?
Nej. Kun critical CSS for første viewport bør inlines. Resten kan loades normalt eller udskydes, så du undgår stor HTML og vedligeholdelsesproblemer.
Er defer altid nok for JavaScript?
Defer hjælper meget, men ikke alt. Hvis scriptet stadig er tungt at parse eller køre, kan det stadig påvirke interaktivitet og rendering senere.
Næste skridt efter guiden
Brug emnesider, ordbog og blog til at validere og uddybe næste ændring.
