Hvad er render-blocking ressourcer?
Render-blocking ressourcer er filer der stopper browseren i at tegne siden. Se hvilke filer der blokerer, hvorfor de gør det, og hvordan du får dem af vejen.
Render-blocking ressourcer er filer, som browseren skal hente og læse færdigt, før den overhovedet må tegne noget på skærmen. Det er næsten altid CSS-filer og JavaScript-filer, der står i sidens <head>. Så længe de er undervejs, ser den besøgende en tom skærm — også selv om HTML’en for længst er ankommet. Det er en af de hyppigste årsager til dårlig LCP, og det er den, PageSpeed Insights kalder “Eliminate render-blocking resources”.
Hvorfor browseren venter
Der er en fornuftig grund til begge dele.
CSS blokerer, fordi alternativet er værre. Tegnede browseren siden, før den kendte stylesheetet, ville den besøgende se et sekund utylet HTML og derefter et voldsomt spring, når stilen kom. Derfor venter browseren, til den ved, hvordan siden ser ud.
JavaScript blokerer, fordi det kan ændre siden. Et script kan skrive nyt indhold ind i dokumentet, mens det læses. Browseren kan derfor ikke bare springe det over — den standser og kører scriptet, før den læser videre.
Sådan finder du dem
Kør siden gennem PageSpeed Insights og kig på listen under den blokerende audit. Den viser hver fil, dens størrelse, og hvor meget tid der er at hente. Vil du se det direkte, kan du åbne netværksfanen i browserens udviklerværktøjer og se, hvad der ligger før det første, der bliver tegnet.
På en typisk dansk WordPress-side finder jeg mellem 8 og 20 blokerende filer. De kommer fra temaet, fra sidebyggeren og fra hvert plugin, der har sin egen stilfil med.
Sådan får du dem af vejen
JavaScript først, for det er det letteste. De fleste scripts har ikke brug for at køre, før siden er tegnet:
<script src="/js/menu.js" defer></script>defer udskyder scriptet, til HTML’en er læst færdig, og bevarer rækkefølgen mellem scripts. async kører det, så snart det er hentet, uden garanti for rækkefølge — brug den til uafhængige ting som sporingsscripts.
CSS er sværere, fordi noget af den skal bruges. Fremgangsmåden er at skille det, der er synligt uden at rulle, fra resten:
- Læg den kritiske CSS direkte i
<head>som en<style>-blok, så den ikke skal hentes. - Hent resten bagefter, så den ikke blokerer.
- Fjern stilfiler fra sider, hvor de ikke bruges. Et formular-plugin behøver ikke sit stylesheet på forsiden.
Skrifttyper tæller også med. Hentes de fra et fremmed domæne, skal browseren først slå domænet op og åbne en forbindelse. Læg dem på dit eget domæne, og brug font-display: swap, så teksten vises med det samme.
Det, der virkelig flytter noget, er at fjerne filer frem for at flytte dem. Færre plugins giver færre stilfiler. Se TBT for den anden halvdel af det samme problem, og hurtigere WordPress for fremgangsmåden i praksis.
Ofte stillede spørgsmål
Er alle CSS-filer render-blocking?
Nej. En stilfil med et media-krav, der ikke passer på situationen — for eksempel media="print" — henter browseren uden at vente på den. Det er også det trick, der bruges til at hente ikke-kritisk CSS uden at blokere.
Hvad er forskellen på defer og async?
defer venter, til HTML’en er læst færdig, og kører scripts i den rækkefølge, de står. async kører scriptet, så snart det er hentet, og rækkefølgen er tilfældig. Brug defer som standard.
Hvor meget kan jeg spare?
På de sider, jeg gennemgår, ligger gevinsten typisk mellem et halvt og halvandet sekund på mobil. Det afhænger af, hvor mange filer der er, og hvor de hentes fra. Vil du se dine egne tal, så kør en hastighedsanalyse.