Optimering av webbprestanda och Lighthouse · Lektion

Renderingsblockerande resurser

Identifiera och minska effekten av renderingsblockerande CSS och JavaScript på den initiala sidans laddningstid.

Lektion 2 av 412 steg

Renderingsblockerande resurser är en gratis lektion i Optimering av webbprestanda och Lighthouse på CoddyKit. Detta är lektion 2 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Optimering av webbprestanda och Lighthouse, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Optimering av webbprestanda och Lighthouse innehåller totalt 4 lektioner.

Vad blockerar sidan?

När en webbläsare läser in en webbsida behöver den bearbeta olika resurser som HTML, CSS och JavaScript. Ibland måste vissa resurser bearbetas helt innan webbläsaren kan börja visa något innehåll för användaren.

Dessa kallas render-blocking resources. De hindrar webbläsaren från att rendera sidan tills de har hanterats, vilket fördröjer ”First Contentful Paint”.

Snabb överblick: rendering i webbläsaren

För att visa en sida går webbläsaren igenom en serie steg som kallas Critical Rendering Path. Viktiga steg är:

Tolka HTML: Bygger upp Document Object Model (DOM).
Tolka CSS: Bygger upp CSS Object Model (CSSOM).
Kombinera: Skapar Render Tree (DOM + CSSOM).
Layout: Beräknar elementens positioner och storlekar.
Rita: Ritar pixlar på skärmen.

Både DOM och CSSOM behövs innan Render Tree kan byggas, vilket gör CSS till en viktig del av renderingen.

CSS: renderingsblockeraren

Som standard är externa CSS-filer renderingsblockerande. Det innebär att webbläsaren pausar renderingen tills alla externa stilmallar som är länkade i HTML-dokumentets <head> har laddats ner, tolkats och tillämpats.

Detta är avgörande eftersom webbläsaren måste veta hur elementen ska se ut innan den kan rita dem korrekt. Om CSS tar lång tid att ladda får användarna se en tom skärm längre.

Exempel: standardblockering med CSS

Ta en titt på denna enkla HTML-kod. Webbläsaren slutar tolka HTML-koden och väntar på att style.css ska laddas ner och bearbetas innan den kan rendera något.

<!DOCTYPE html>
<html>
<head>
  <title>Blocking CSS</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <h1>Welcome!</h1>
  <p>This content is waiting.</p>
</body>
</html>

Villkorsstyrd CSS med `media`

Ni kan göra viss CSS icke-renderingsblockerande genom att använda attributet media i er <link>-tagg. Det talar om för webbläsaren att en stilmall bara gäller under vissa villkor, till exempel för utskrift eller specifika skärmstorlekar.

Om villkoret i media inte stämmer med den aktuella visningsmiljön laddar webbläsaren fortfarande ner CSS-filen, men den blockerar inte den första renderingen.

<link rel="stylesheet" href="print.css" media="print">
<link rel="stylesheet" href="mobile.css" media="(max-width: 600px)">

Infoga viktiga stilmallar

En annan strategi för att minska renderingsblockerande CSS är att infoga kritiska stilmallar. Det är de minimala CSS-regler som behövs för att rendera innehållet above the fold, alltså det användarna ser först.

Genom att placera dessa stilmallar direkt i en <style>-tagg i HTML-dokumentets <head> behöver webbläsaren inte göra någon extra nätverksförfrågan, vilket snabbar upp den första renderingen. Återstående, icke-kritisk CSS kan laddas asynkront.

JavaScript stoppar allt

Precis som CSS kan även JavaScript vara renderingsblockerande. När webbläsaren stöter på en traditionell <script>-tagg, utan attributen async eller defer, pausar den tolkningen av HTML-koden.

Därefter laddar, tolkar och kör den JavaScript-filen. Först när skriptet har körts klart återupptas tolkningen av HTML-koden. Detta kan avsevärt fördröja renderingen.

Exempel: standardblockering med JS

Här pausar webbläsaren tolkningen av HTML-dokumentet när den når script.js. Om script.js är stor eller tar lång tid att ladda kommer elementen <h1> och <p> inte att tolkas eller renderas förrän skriptet är klart.

<!DOCTYPE html>
<html>
<head>
  <title>Blocking JS</title>
  <script src="script.js"></script>
</head>
<body>
  <h1>Content Below Script</h1>
  <p>This waits for the script.</p>
</body>
</html>

`async` och `defer` för skript

HTML erbjuder två attribut för <script>-taggar som förhindrar att JavaScript blockerar renderingen:

async: Laddar ner skriptet parallellt med tolkningen av HTML-koden. Kör det så snart det har laddats ner, eventuellt innan HTML-tolkningen är klar. Passar bra för fristående skript.
defer: Laddar ner skriptet parallellt med tolkningen av HTML-koden. Kör det först när HTML-tolkningen är helt klar, men innan händelsen DOMContentLoaded. Bevarar körordningen.

Kodexempel: icke-blockerande JS

Genom att lägga till async eller defer kan webbläsaren fortsätta tolka HTML-koden medan skripten laddas ner. Detta förbättrar den upplevda prestandan.

<!DOCTYPE html>
<html>
<head>
  <title>Non-Blocking JS</title>
  <script async src="analytics.js"></script>
  <script defer src="main-app.js"></script>
</head>
<body>
  <h1>Page Content</h1>
  <p>This renders without waiting for scripts.</p>
</body>
</html>

Hitta blockeraren!

Vilka av följande resurser anses vanligtvis vara renderingsblockerande som standard?

Besvara frågan i den interaktiva lektionen

Viktiga slutsatser

Renderingsblockerande resurser fördröjer visningen av webbsidan. Både extern CSS och traditionellt JavaScript kan blockera webbläsarens renderingsprocess.

För CSS: Använd attributet media för villkorsstyrd inläsning och överväg att infoga kritiska stilmallar.
För JavaScript: Använd async för fristående skript eller defer för skript som är beroende av DOM, så att nedladdningen kan ske parallellt och körningen inte blockerar.

Att optimera dessa resurser är ett viktigt steg mot bättre webbprestanda!

Gratis att börja

Lär dig Optimering av webbprestanda och Lighthouse med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser: 12
Lektioner: 48

Börja lära dig gratis Visa hela kursen

Vanliga frågor

Är lektionen ”Renderingsblockerande resurser” gratis?

Ja – hela texten till ”Renderingsblockerande resurser” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Optimering av webbprestanda och Lighthouse, kan Ni uppgradera till CoddyKit PRO. Kursen i Optimering av webbprestanda och Lighthouse innehåller totalt 4 lektioner.

Vad lär jag mig i ”Renderingsblockerande resurser”?

Identifiera och minska effekten av renderingsblockerande CSS och JavaScript på den initiala sidans laddningstid. Ni övar på Optimering av webbprestanda och Lighthouse med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Optimering av webbprestanda och Lighthouse?

Du behöver inga förkunskaper. Utbildningen i Optimering av webbprestanda och Lighthouse på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.

Hur lång tid tar lektionen ”Renderingsblockerande resurser”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Optimering av webbprestanda och Lighthouse-lektionen?

Ja. Varje Optimering av webbprestanda och Lighthouse-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

← Tillbaka till Optimering av webbprestanda och Lighthouse