Los "Avoid Chaining Critical Requests" op in Lighthouse.

Hoe de downloadprioriteit wordt bepaald

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

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

Uw browser maakt in eerste instantie een weloverwogen schatting welke elementen het belangrijkst zijn. Over het algemeen werkt de downloadprioriteit als volgt: HTML heeft altijd de hoogste prioriteit, dan stylesheets, synchrone JavaScript, fonts, Ajax-verzoeken, afbeeldingen bovenaan de pagina, afbeeldingen verderop op de pagina en vervolgens asynchrone JavaScripts.

U kunt zelf zien welke bronnen hoge prioriteit krijgen op uw pagina. Open de dev-console met Ctrl + Shift + J. Navigeer naar het netwerk-tabblad, klik met de rechtermuisknop op de kolomnamen en selecteer 'Priority'

Hoe beïnvloedt de Critical Request Chain de laadtijd van de pagina?

Bij het laden van een pagina start een browser in 'display blocking' modus. In deze modus worden de belangrijkste bronnen met hoge prioriteit gedownload. Dat zijn de kritieke bronnen.

Een browser zal de pagina niet (volledig) beginnen te renderen totdat alle kritieke bronnen zijn gedownload. Dus elke kritieke bron kan de eerste rendering van een pagina blokkeren.

Hoe minder kritieke bronnen 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 bronnen.

Hoe "Avoid Chaining Critical Requests" oplossen in Lighthouse?

U kunt de impact van kritieke verzoeken op drie manieren verminderen:

1. Verminder het aantal kritieke bronnen . Converteer kritieke bronnen naar niet-kritieke bronnen door ze te verwijderen of uit te stellen (defer).
2. Verminder het aantal kritieke bytes . Het lijkt misschien voor de hand liggend, maar het verminderen van het aantal bytes van de bronnen op het kritieke pad zorgt ervoor dat de kritieke bronnen sneller downloaden. Bijvoorbeeld door gzip-compressie, javascript tree shaking, afbeeldingsoptimalisatie of font subsetting.
3. Verbeter de downloadvolgorde van het kritieke pad . Gebruik resource hints zoals preloading om resource discovery over te slaan en ervoor te zorgen dat de kritieke bronnen zo snel mogelijk worden gedownload.

Er zijn veel opties. Welke optie de beste is, hangt af van het bestandstype van de bron:

1. HTML

De HTML, wat eigenlijk de pagina is die u bezoekt, wordt altijd met de hoogste prioriteit gedownload. De pagina zelf maakt altijd deel uit van de critical request chain. Daarom is de pagina zelf het eerste om te overwegen bij het optimaliseren van de critical request chain..

Vertraagd laden van content: Veel grote sites, zoals Google zelf, gebruiken deze techniek om de critical request chain te verkleinen. Op de pagina met zoekresultaten 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 commentaar, spaties en lege regels van de pagina te verwijderen.

Compressie : Ten slotte is het belangrijk om stylesheets goed te comprimeren met Brotli- of GZIP-compressie

2. Stylesheets

Stylesheets in de head van de pagina zijn altijd kritiek. Zonder stijlen weet een browser niet hoe de pagina eruit moet zien. Stylesheets zijn daarom een standaardonderdeel van de critical request chain in Lighthouse.

Critical CSS: Stylesheets kunnen niet-kritiek worden gemaakt met een simpele truc waarbij de stylesheet wordt voorgeladen via resource hints en als stylesheet wordt toegevoegd nadat het voorladen is voltooid.
Voeg de volgende code toe aan de pagina: Uw browser downloadt de stylesheet nu met een lagere prioriteit en behandelt de CSS als 'non-render blocking'. Het zal beginnen met renderen zonder op de CSS te wachten.

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

Kijk hoe er nu iets vreemds gebeurt op de pagina. Eerst wordt de pagina getoond en pas na het laden van de CSS wordt de styling toegepast. Alle content zal nu flitsen van ongestijlde content naar gestijlde content. Dit kunnen we oplossen met critical CSS.
Critical CSS is een verzameling van alle CSS-regels die u nodig heeft voor het zichtbare deel van de pagina. U kunt zelf critical CSS genereren via NodeJS of via een aantal online tools. Plaats deze critical CSS in de head van de pagina en laad de rest van de CSS met een lagere prioriteit.

Media queries : Laad alleen de stijlen voor uw apparaat. Uw pagina wordt vaak op mobiel bezocht. U hoeft dus eigenlijk de stijlen voor Desktop en Print niet te downloaden. Dit bespaart tijd en verkort dus de critical request chain in Lighthouse.

Gebruik het media-attribuut. Het media-attribuut zorgt ervoor dat een bestand alleen wordt gedownload als de media overeenkomt met de media die u momenteel gebruikt.

<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)">

Minify: Verwijder ongebruikte CSS. Veel sites gebruiken CSS-bibliotheken zoals bootstrap. Deze bibliotheken zijn vaak overcompleet en niet alle stijldeclaraties worden gebruikt.
Het is eenvoudig om deze bibliotheken te bewerken via een CSS-preprocessor (zoals SASS ). Verwijder simpelweg de ongebruikte stijlgroepen door te wijzigen wat er moet worden opgenomen, om ze een stuk kleiner te maken. Deze preprocessors geven u ook de optie om uw CSS te minificeren door alle spaties en regeleindes te verwijderen.">

Compressie : Ten slotte is het belangrijk om stylesheets goed te comprimeren met Brotli- of GZIP-compressie

3. Javascript

Javascript-bestanden in de head van de pagina worden standaard met een hoge prioriteit gedownload en blokkeren het renderen van de pagina terwijl ze worden gedownload en uitgevoerd. Javascript is daarom een standaardonderdeel van de critical request chain.

Defer en Async : Pas de prioriteit van de Javascript-bestanden aan door ze asynchroon te laden via het async of defer attribuut. Asynchrone scriptbestanden worden parallel gedownload met een lagere prioriteit. Uitgestelde (deferred) JavaScript wordt ook parallel geladen en de uitvoering van het Javascript-bestand wordt uitgesteld zodat de Javascript-uitvoering ook het initiële laden van de pagina niet blokkeert.

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

Code splitting en preloading: Als de pagina het niet toestaat dat JavaScript asynchroon wordt geladen, kan het een goed idee zijn om JavaScript in meerdere bestanden op te splitsen. Plaats het deel van de JavaScript dat kritiek is tijdens het laden van de pagina in een klein bestand en preload dit bestand. Plaats de niet-kritieke javascript in een ander bestand en laat het deferred of async laden en uitvoeren.

Minify : Verklein het aantal bytes op twee manieren via een Javascript Uglifier tool. Dit is een slimme tool die Javascript analyseert en zo klein mogelijk maakt. ">

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

4. WebFonts

Webfonts worden meestal als laatste bestanden in de critical request chain geladen. Dit komt omdat webfonts afhankelijk zijn van ontdekking. Ze worden pas geladen wanneer een browser ontdekt dat ze nodig zijn. Hiervoor moet een browser eerst de HTML analyseren en in de stylesheet opzoeken welk font wordt gebruikt.

Preloading : Wanneer u zeker weet dat u op een font gaat vertrouwen, is het meestal sneller om dit font te preloaden. Het font wordt dan zo vroeg mogelijk gedownload, dit minimaliseert de invloed op de critical request chain. Preload een font 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>

Fontstrategie : Daarnaast zijn er vele andere manieren om fonts sneller te laten laden.

• Vertrouw altijd op lokale webfonts en nooit op extern gehoste fonts zoals Google fonts.
• Verklein het font met font subsetting
• Laad niet-kritieke fonts via de Javascript <a href="https://developer.mozilla.org/en-US/docs/Web/API/FontFace">fontface interface</a>
• Gebruik display = swap om te voorkomen dat het font de initiële rendering blokkeert
• Laat browsers hun eigen fontvarianten genereren via font synthesis

Afbeeldingen

Afbeeldingen die tijdens het laden van de pagina in de zichtbare viewport verschijnen, kunnen ook een hoge prioriteit krijgen en het kritieke pad verstoren. Wanneer u zeker weet dat een afbeelding altijd in het zichtbare deel van de website verschijnt, kan het nuttig zijn om deze afbeelding ook te preloaden.

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

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

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

5. AJAX Request

Ajax-verzoeken krijgen altijd een hoge prioriteit toegewezen. Stel Ajax-verzoeken daarom bij voorkeur uit totdat de pagina klaar is met renderen. Wacht totdat de pagina het "load" event heeft verzonden.

Als het niet mogelijk is om het AJAX-verzoek uit te stellen, kunt u ervoor zorgen dat het Ajax-verzoek beschikbaar is voor de browser door het te preloaden.

window.addEventListener('load', (event)=>{
  console.log('dit is een goed moment voor een AJAX-verzoek');
});

6. iframes

Iframes worden meestal met een hoge prioriteit gedownload. Omdat een iframe eigenlijk een pagina binnen een pagina is, kan een iframe een zeer aanzienlijke vertraging in de laadtijden van de pagina veroorzaken. De bronnen die het iframe nodig heeft, kunnen ook met hoge prioriteit worden gedownload en hun eigen critical request chain vormen. Het gebruik van iframes kan daarom uw Lighthouse-score aanzienlijk beïnvloeden.

U kunt het laden van een iframe vertragen via het loading = "lazy" attribuut. Dat maakt vaak een verschil wanneer het iframe tijdens het laden niet direct zichtbaar is. Het is vaak sneller om dat iframe via JavaScript in de pagina te injecteren. Dit geeft u meer controle over de timing om er zeker van te zijn dat het niet in de critical request chain terechtkomt.