Fjern gengivelsesblokerende JavaScript og CSS fra indholdet over skillelinjen – PageSpeed Insights

JavaScript og CSS er godt til mange ting, og noget som virkelig kan skabe nogle gode ting på en hjemmeside. Men at bruge JavaScript og CSS har også en bagside hvis man ikke tænker sig om.

Google PageSpeed Insights – Del 3

At fjerne gengivelsesblokerende JavaScript og CSS fra indholdet over skillelinjen også kaldet render-blocking – først hvad er JavaScript og CSS? Det er noget man typisk ser indsat imellem head tagget i et html dokument (HTML er den type kode din hjemmeside spytter ud, så ja stort set alle hjemmesider består af et HTML dokument). JavaScript og CSS er klientsidet, forstået på den måde at før der reelt bliver gjort noget med det, skal det hentes ned og fortolkes på brugerens computer i deres browser. CSS bruges til at designe hjemmesiden med, mens JavaScript typisk bruges i forbindelse med interaktion på siden.

Det er derfor ikke på samme måde som med serversidekode som jeg skrev om i del 2, og som omhandlede reducering af svartid. Men serversidekode bliver fortolket på serveren og derefter smidt ud til brugeren i form af HTML.

Hvad er gengivelsesblokerende JavaScript og CSS?

Nogle tror at det der bliver skrevet i Google PageSpeed Insights, er at JavaScriptet eller CSS filen er blokeret, og dermed ikke loader. Dette er ikke tilfældet. JavaScriptet og CSS filen er blokerende. Altså loader det, men blokerer for at andet på siden bliver arbejdet med så længe de loades og fortolkes. Når browseren er færdig med at fortolke elementet, går den videre til næste element på hjemmesiden.

Kort fortalt betyder gengivelsesblokerende JavaScript og CSS følgende: Når en browser indlæser en webside, kan den derfor ikke fortsætte med at vise indholdet før den har hentet og eksekveret eventuelle JavaScript- og CSS-filer, der er angivet i indholdets skillelinje. Dette kan forsinke indlæsningstiden for dine sider, især hvis der er meget JavaScript og CSS involveret.

Så man kan reelt sige at hvis din eksterne javascript/CSS fil bliver hentet ind allerede imellem head tagget, eller lige efter det startende bodytag. Så er det i sit udgangspunkt blokerende. Det samme gælder faktisk også inline JavaScript, det er også blokerende i sit udgangspunkt.

Dette er fordi inline JavaScript skal fortolkes og JavaScript + CSS filer som sagt skal hentes ned og fortolkes, og dette stopper altså renderingen af sitet, og lader resten af sitet vente på sig til dette er færdig med fortolkningen.

Hvad er rendering?

Det er vigtigt at forstå hvad rendering er, da det giver et meget godt billede af hvorfor et JavaScript eller en CSS fil i sit udgangspunkt er blokerende, hvis det fx indsættes mellem head taggene.

Når en hjemmeside hentes ned, hentes der et HTML dokument, hvori der er det man kalder HTML kode. Det kunne se ud sådan:

Der er både en CSS og JavaScript fil, og ydermere bliver der hentet et billede ind som indhold. Men når dokumentet er hentet ned, så begynder browseren at fortolke. Dette gør den som et træ, også kaldet dokumenttræ eller DOM tree.

Det vil sige den starter med at se, her har vi <html></html> inde i den er der først <head></head> og derefter <body></body>. Og da browseren fortolker fra toppen og ned, vil den først starte med at se på head hvori CSS og JavaScript jo også bliver hentet ind. Det betyder så at mens det bliver gjort, venter den med at fortolke det der er mellem body taggene. Men når den er færdig med at fortolke det der er i head, så går den videre med at fortolke body, og her finder den så billedet, der i øvrigt ikke er blokerende, men som skal hentes ned.

Hvordan kan man gøre JavaScript og CSS ikke blokerende?

Processen og hvad man gør, er forskellig alt efter om vi snakker JavaScripts eller CSS filer. Så jeg vil dele det op i disse to kategorier.

Fjern gengivelsesblokerende JavaScript

Når nu du forstår hvad rendering er, kan man i udgangspunktet sige at første step er at få dem ned under folden, jeg anbefaler typisk, lige før det afsluttende bodytag. Og hvad sker der så? Jo JavaScripts er ikke længere i Googles øjne blokerende. Og så er det punkt væk og af vejen.

Nej ikke rigtig, for det er noget vås at sige at det ikke er blokerende, for blokerende er det, se fx herunder på billedet, hvor den loader med JavaScripts nede ved det afsluttende bodytag som skrevet ovenfor, og som får grønt lys hos Google. Læg mærke til den blå streg, som viser at noget blokerer for renderingen af sitet.

Dette er jo fordi JavaScript i sit udgangspunkt er blokerende, uanset hvor det er placeret i HTML koden.

Men hvad kan man så gøre ved det? Jo man skal på en eller anden måde fortælle browseren af de her scripts, må du gerne vente med at fortolke, hente ned fint, fortolke nej. Det kan man gøre på flere måder. Man skal dog lige være obs på at man ikke altid kan bruge den samme metode til alle. Den vej jeg typisk vælger, er det man kalder asynkron load. Det ser ud sådan:

async gør det at filen hentes mens siden bliver renderet, og filen fortolkes så når filen er hentet ned.

Defer gør det at filen hentes efter siden er renderet, og filen fortolkes når filen er hentet ned.

Og så er der den normale, som jo stopper sidens rendering, mens filen loades og fortolkes.

Nogle gange skal man bruge en kombi af alle 3, da det kommer an på hvad JavaScriptet indeholder og bruges til, samt hvad JavaScriptet er afhængig af.

Men prøv at se på dette eksempel som viser hvordan renderingen går når man fx bruger async: læg igen mærke til den blå streg.

Forskellen er stor, faktisk renderes siden 50% hurtigere end i før viste eksempel, fordi JavaScriptene nu ikke er blokerende mere. Husk på, Google gav det andet grønt lys selvom de reelt var blokerende stadig. Så stol ikke altid på hvad Google PageSpeed Insights fortæller dig.

Fjern gengivelsesblokerende CSS

At fjerne gengivelsesblokerende CSS, er lidt sværere, da det også indbefatter det Google PageSpeed Insights kalder Prioriter Synligt Indhold, men det vil jeg ikke komme så meget ind på her, da det er et kapitel for sig.

Det jeg vil fokusere på er det at fjerne gengivelsesblokerende CSS, og det er der også her flere måder at gøre det på. Første skridt er at få fjernet kald til CSS filer 100%. Det vil sige at din side faktisk ikke skal hente nogen CSS filer ind på hjemmesiden overhovedet. Hvordan man fjerner dem er forskelligt fra system til system, men har du et custom, burde denne manøvre være nem. I WordPress skal man ind og kode for at fjerne de styles som bliver hentet ind, det kan du læse mere om her.

Dernæst skal du faktisk også her loade CSS filerne asynkront. Og dette kan man gøre via JavaScript, hvilken måde du gør det på er op til dig, for der er 1000 måder at gøre netop det.

Ud over det for at du undgår at siden hopper og danser, skal du lige få hele eller dele af dit hovedstylesheet (CSS) ind i head, mellem style tags. Dette er også starten på det at Prioritere Synligt indhold.

Sådan fjerner du gengivelsesblokeringen og gør din hjemmeside hurtigere

Fjernelse af gengivelsesblokerende JavaScript og CSS fra indholdet over skillelinjen

I denne guide vil jeg hurtigt fortælle, hvordan du fjerner gengivelsesblokerende JavaScript og CSS fra dit indhold over skillelinjen. Det kan gøre din hjemmeside mærkbart hurtigere.

For at fjerne denne blokering og optimere dit webindhold kan du følge disse trin:

Med disse trin kan du begynde at fjerne gengivelsesblokerende JavaScript og CSS fra dit indhold over skillelinjen og få en hurtigere hjemmeside. Og husk at teste hastigheden igen med jævne mellemrum.

Skrevet af

Kim Tetzlaff

Programmør og webudvikler · Kim Tetzlaff ApS

• Koder siden 1995
• HTML siden 1996
• WordPress siden 2007
• Oplægsholder, WordCamp Denmark 2013

Hvem

Skrevet af mig, der laver arbejdet: hastighedsoptimering, teknisk SEO og udvikling for egne kunder.

Hvordan

Bygger på målinger af rigtige hjemmesider med PageSpeed Insights, GTmetrix og mine egne testværktøjer. Udgivet 7. oktober 2015, senest opdateret 31. oktober 2026.

Hvorfor

Skrevet så du selv kan finde ud af, hvor din side taber tid, og hvad der er værd at rette først.

Kilder i artiklen

• developer.wordpress.org

Mere om mig →Spørgsmål til artiklen? Skriv til mig →