Fix "Avoid Chaining Critical Requests" in Lighthouse

Hoe de downloadprioriteit wordt bepaald

Kritieke requests zijn de resources die met hoge prioriteit worden gedownload tijdens het initieel laden van de pagina. Hoe wordt deze prioriteit bepaald?

De downloadprioriteit wordt bepaald door de browser zelf. De browser volgt een reeks regels om de prioriteit van elk bestand te bepalen. Welke elementen uiteindelijk de hoogste prioriteit krijgen, hangt af van de structuur van de pagina. De elementen waarvan je browser denkt dat ze nodig zijn voor de eerste rendering van de pagina krijgen de hoogste prioriteit.

Je browser maakt aanvankelijk een weloverwogen schatting van welke elementen het belangrijkst zijn. Over het algemeen werkt de downloadprioriteit als volgt: HTML krijgt altijd de hoogste prioriteit, dan stylesheets, synchroon JavaScript, lettertypen, AJAX-verzoeken, afbeeldingen bovenaan de pagina, afbeeldingen lager op de pagina, en daarna asynchroon JavaScript.

Je kunt deze prioriteiten overschrijven met het fetchpriority-attribuut. Door fetchpriority="high" in te stellen vertel je de browser dat een resource belangrijker is dan normaal ingeschat. fetchpriority="low" instellen doet het tegenovergestelde. Dit attribuut heeft nu 93% browserondersteuning. Voor een complete gids, zie Resource Prioritization en de Core Web Vitals.

Je kunt zien welke resources op je pagina een hoge prioriteit krijgen. Open DevTools met Ctrl+Shift+J. Navigeer naar het Network-tabblad, klik met de rechtermuisknop op de kolomnamen en selecteer 'Priority'.

Hoe beïnvloedt de kritieke request-keten de laadtijd van een pagina?

Bij het laden van een pagina start een browser in "weergaveblokkerende" modus. In deze modus worden de belangrijkste resources met hoge prioriteit gedownload. Dat zijn de kritieke resources.

Een browser zal de pagina niet (volledig) beginnen te renderen totdat alle kritieke resources zijn gedownload. Elke kritieke resource kan dus de eerste rendering van een pagina blokkeren.

Hoe minder kritieke resources een pagina heeft, hoe minder werk de browser hoeft te doen om de eerste content op het scherm te krijgen, en hoe minder concurrentie er is voor de CPU en andere resources.

Volgens de 2025 Web Almanac slaagt slechts 15% van de mobiele pagina's voor de audit van renderblokkerende resources. Dat betekent dat 85% van het web nog steeds problemen met kritieke ketens heeft op te lossen. Dit is een van de belangrijkste redenen waarom slechts 55% van de mobiele origins "goed" scoort op First Contentful Paint. Op sites die worden gemonitord door CoreDash hebben origins met minder dan 3 kritieke ketenverzoeken een mediaan FCP van 1,2 seconden, vergeleken met 2,4 seconden voor origins met 8 of meer ketenverzoeken.

Opmerking: Vanaf Lighthouse 13 (oktober 2025) is deze audit hernoemd naar het "Network Dependency Tree"-inzicht. Het concept is hetzelfde: Lighthouse analyseert de keten van netwerkverzoeken met hoge prioriteit en waarschuwt wanneer deze te diep is.

Hoe fix je "Avoid Chaining Critical Requests" in Lighthouse

Je kunt de impact van kritieke requests op drie manieren verminderen:

1. Verminder het aantal kritieke resources. Converteer kritieke resources naar niet-kritieke resources door ze te verwijderen of uit te stellen.
2. Verminder het aantal kritieke bytes. Het verkleinen van kritieke-pad-resources zorgt ervoor dat ze sneller downloaden. Gzip- of Brotli-compressie, JavaScript tree shaking, afbeeldingsoptimalisatie en font subsetting helpen allemaal.
3. Verbeter de downloadvolgorde van het kritieke pad. Gebruik resource hints zoals preloading om resourceontdekking over te slaan en ervoor te zorgen dat de kritieke resources zo snel mogelijk worden gedownload. Gebruik HTTP 103 Early Hints om te beginnen met het preloaden van resources voordat de HTML zelfs maar arriveert.

Welke optie het beste is, hangt af van het bestandstype van de resource:

1. HTML

De HTML zelf wordt altijd met de hoogste prioriteit gedownload. De pagina maakt altijd deel uit van de kritieke request-keten. Daarom is de pagina zelf het eerste om te overwegen bij het optimaliseren.

Vertraagd laden van content: Veel grote sites, zoals Google zelf, gebruiken deze techniek om de kritieke request-keten te verminderen. Op de zoekresultatenpagina worden bijvoorbeeld delen van de content die niet direct nodig zijn pas later geladen via een AJAX-verzoek.

Minify: Kleiner is altijd sneller. Gebruik HTML-minificatie om opmerkingen, spaties en lege regels van de pagina te verwijderen.

Compressie: Comprimeer je HTML met Brotli of Gzip. Brotli bereikt doorgaans 15 tot 20% betere compressie dan Gzip.

2. Stylesheets

Stylesheets in de head van de pagina zijn altijd kritiek. Zonder stijlen weet een browser niet hoe de pagina eruit zal zien. Stylesheets zijn daarom een standaard onderdeel van de kritieke request-keten.

Critical CSS: De meest effectieve manier om de CSS-keten te doorbreken is om je critical CSS direct inline te plaatsen in een <style>-tag in de <head>. Dit elimineert het renderblokkerende netwerkverzoek volledig. Je kunt critical CSS genereren via NodeJS-tools of via de Critical CSS Generator. Plaats critical CSS inline en laad de rest met een lagere prioriteit:

<link rel="preload"
      href="css.css"
      type="text/css"
      as="style"
      onload="this.onload=null;this.rel='stylesheet';"/>

Let op dat er nu iets vreemds op de pagina gebeurt. Eerst wordt de pagina zonder stijlen getoond, en pas na het laden van de CSS wordt de styling toegepast. Alle content zal flashen van ongestijld naar gestijld. Daarom heb je critical CSS nodig: de CSS-regels voor het zichtbare deel van de pagina staan inline, zodat de pagina er direct correct uitziet, en de rest van de CSS laadt zonder de rendering te blokkeren.

Vermijd CSS @import-ketens: Als je CSS-bestanden @import gebruiken om andere CSS-bestanden te laden, creëer je een keten waarbij de browser bestand A moet downloaden voordat het ontdekt dat het bestand B nodig heeft. Vervang @import-statements door afzonderlijke <link>-tags of voeg de bestanden samen tijdens het buildproces. Dit is een van de meest voorkomende oorzaken van onnodig diepe kritieke ketens.

Media queries: Laad alleen de stijlen die je apparaat nodig heeft. Als een bezoeker op mobiel zit, hoeven ze de desktop- of printstijlen niet te downloaden. Gebruik het media-attribuut om stylesheets niet-blokkerend te maken voor apparaten die niet overeenkomen:

<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">

De browser downloadt alleen stylesheets waarvan het media-attribuut overeenkomt met het huidige apparaat met hoge prioriteit. Niet-overeenkomende stylesheets worden met lage prioriteit gedownload en blokkeren de rendering niet.

Minify: Verwijder ongebruikte CSS. Veel sites gebruiken CSS-bibliotheken zoals Bootstrap. Deze bibliotheken zijn vaak overcompleet en niet alle stijldeclaraties worden gebruikt. Bewerk deze bibliotheken via een CSS-preprocessor (zoals Sass) om ongebruikte stijlgroepen te verwijderen. Preprocessors minificeren ook je CSS door alle spaties en regeleinden te verwijderen. Zie ook hoe je 'remove unused CSS' fixt.

Compressie: Comprimeer stylesheets met Brotli- of Gzip-compressie.

3. JavaScript

JavaScript-bestanden in de head van de pagina worden standaard met hoge prioriteit gedownload en blokkeren de rendering van de pagina terwijl ze worden gedownload en uitgevoerd. JavaScript is daarom een standaard onderdeel van de kritieke request-keten.

Defer en Async: Pas de prioriteit van JavaScript-bestanden aan door ze asynchroon te laden via het async- of defer-attribuut. Async-scripts worden parallel gedownload met lagere prioriteit. Deferred scripts worden ook parallel gedownload en hun uitvoering wordt uitgesteld totdat de HTML is geparsed. Voor een complete vergelijking, zie async vs defer en hoe ze de Core Web Vitals beïnvloeden.

// blokkeert laden en uitvoering
<script src="normalscript.js"></script>
// async blokkeert niet tijdens laden, maar wel tijdens uitvoering
<script  src="asyncscript.js"></script>
// defer blokkeert niet tijdens laden of uitvoering
<script  src="deferscript.js"></script>

Voor meer technieken om JavaScript uit te stellen, zie 16 methoden om JavaScript uit te stellen of in te plannen. Als je ongebruikt JavaScript hebt dat niet uitgesteld kan worden, zie hoe je ongebruikt JavaScript kunt verminderen.

Code splitting en preloading: Als de pagina het niet toelaat om JavaScript asynchroon te laden, splits JavaScript dan op in meerdere bestanden. Plaats het deel dat kritiek is tijdens het laden van de pagina in een klein bestand en preload dit. Plaats het niet-kritieke JavaScript in een ander bestand en laat het deferred of async laden.

Minify: Verklein het aantal bytes door een JavaScript-minifier. Moderne bundlers zoals webpack, Rollup en Vite gebruiken terser onder de motorkap om JavaScript te analyseren en zo klein mogelijk te maken.

Compressie: Verminder het aantal bytes door JavaScript te comprimeren via Gzip of Brotli.

4. Weblettertypen

Weblettertypen zijn meestal de laatste bestanden in de kritieke request-keten. Dit komt doordat weblettertypen afhankelijk zijn van ontdekking: ze worden pas geladen wanneer een browser erachter komt dat ze nodig zijn. Hiervoor moet een browser eerst de HTML analyseren en in de stylesheet opzoeken welk lettertype wordt gebruikt.

Preloading: Wanneer je weet dat je een lettertype gaat gebruiken, is het sneller om dit lettertype te preloaden. Het lettertype wordt dan zo vroeg mogelijk gedownload, waardoor de invloed op de kritieke request-keten wordt geminimaliseerd. Preload een lettertype door deze code zo vroeg mogelijk in de head van de pagina toe te voegen:

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Lettertypestrategie: Er zijn veel andere manieren om lettertypen sneller te laden. Zie hoe je Google Fonts zelf host en hoe je ervoor zorgt dat tekst zichtbaar blijft tijdens het laden van weblettertypen.

• Gebruik altijd zelf-gehoste weblettertypen, nooit op afstand gehoste lettertypen zoals Google Fonts.
• Verklein het lettertype met font subsetting.
• Laad niet-kritieke lettertypen via de FontFace API.
• Gebruik font-display: swap om te voorkomen dat lettertypen de initiële rendering blokkeren.
• Laat browsers hun eigen lettertypevarianten genereren door middel van fontsynthese.

5. Afbeeldingen

Afbeeldingen die in de zichtbare viewport verschijnen tijdens het laden van de pagina kunnen ook een hoge prioriteit krijgen en het kritieke pad verstoren. Wanneer je zeker weet dat een afbeelding altijd in het zichtbare deel van de website verschijnt, preload deze afbeelding. Voeg fetchpriority="high" toe om de browser te vertellen dat het de belangrijkste afbeelding op de pagina is:

<link rel="preload" as="image" href="important-image.webp">

Voor alle afbeeldingen die niet direct zichtbaar zijn, laad deze afbeeldingen lazy. Gebruik loading="lazy" om het laden van de afbeelding uit te stellen tot net voordat deze zichtbaar wordt:

<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="...">

6. AJAX-verzoeken

AJAX-verzoeken krijgen altijd een hoge prioriteit. Stel AJAX-verzoeken daarom uit totdat de pagina klaar is met renderen. Wacht tot de pagina het "load"-event heeft gestuurd:

window.addEventListener('load', (event)=>{
  console.log('this is a good time for an AJAX request');
});

Als het niet mogelijk is om het AJAX-verzoek uit te stellen, kun je de resource preloaden om deze eerder beschikbaar te maken voor de browser.

7. Iframes

Iframes worden meestal met hoge prioriteit gedownload. Omdat een iframe eigenlijk een pagina binnen een pagina is, kan een iframe een aanzienlijke vertraging veroorzaken in de laadtijden van de pagina. De resources die het iframe nodig heeft, kunnen ook met hoge prioriteit worden gedownload en vormen hun eigen kritieke request-keten. Het gebruik van iframes kan daarom een aanzienlijke impact hebben op je Core Web Vitals.

Je kunt het laden van een iframe vertragen via het loading="lazy"-attribuut. Dat maakt vaak een groot verschil wanneer het iframe niet direct zichtbaar is tijdens het laden. Voor meer controle over de timing, injecteer het iframe via JavaScript om ervoor te zorgen dat het niet in de kritieke request-keten terechtkomt. Zie hoe je Google Maps insluit zonder je PageSpeed te schaden en hoe je YouTube insluit met perfecte Core Web Vitals voor voorbeelden van deze techniek.

Verifieer je verbeteringen

Na het optimaliseren van je kritieke keten, verifieer de verbetering met Real User Monitoring. Je FCP en LCP zouden beide moeten verbeteren. Labtools zoals Lighthouse geven je directe feedback, maar velddata van echte gebruikers is wat telt voor de Core Web Vitals.