Network dependency tree in Lighthouse: zo lees en fix je hem

Wat is de Network dependency tree in PageSpeed Insights?

De Network dependency tree in Lighthouse ("Avoid chaining critical requests" vóór Lighthouse 13) toont welke bestanden je pagina als eerste nodig heeft en op welk bestand elk ervan wachtte: elk bestand dat in een ander bestand zit, levert extra wachttijd op. Host je fonts op je eigen domein, link stylesheets in de HTML in plaats van via @import en gebruik preconnect alleen als een kritiek bestand van een domein komt waar je niet omheen kunt.

Wil je meteen de snelle fix? Spring direct naar web fonts, WordPress @import, Shopify of bestanden die een script toevoegt.

Hoe lees je de Network dependency tree?

Lighthouse 13 en PageSpeed Insights omschrijven de melding als: "Avoid chaining critical requests by reducing the length of chains, reducing the download size of resources, or deferring the download of unnecessary resources to improve page load". Dit verving "Avoid chaining critical requests" (eerder "Minimize critical requests depth") en "Preconnect to required origins". Daarom staan er twee preconnect-tabellen onder de tree.

Het rapport hieronder komt van de homepage van een tandartspraktijk die ik heb gebouwd als een WordPress-site: de stylesheet van het child theme importeert die van het parent theme, die weer Google Fonts importeert, en de iconen komen via Font Awesome van een CDN.

Lighthouse 13.6 op mobiel, DevTools-throttling (Slow 4G, 4x CPU).

• Een ingesprongen rij is een bestand dat de browser pas vond in het bestand erboven; hij moest dus op dat bestand wachten. Rijen op hetzelfde niveau downloaden tegelijk, zoals de drie font-bestanden onder Google's css2-stylesheet.
• De tijd en het aantal KiB op een rij: wanneer dat bestand binnen was, gerekend vanaf de start van de laadtijd, en hoe groot het is.
• Maximum critical path latency is de tijd van de traagste keten, in het oranje. Op de tandartspagina is dat het icon font van 155 KiB dat twee niveaus diep zit: dat komt pas binnen ná de Google Fonts die vier niveaus diep zitten.
• LCP and Unscored: de melding telt niet mee voor je Performance-score, maar de stylesheets houden de first paint wel tegen. En LCP kan daar nooit vóór vallen.

PageSpeed Insights meet de laadtijd zonder throttling: de tree toont daardoor veel kortere tijden dan dit screenshot.

Waarom vertraagt een keten van bestanden de pagina?

Op de tandartspagina kijkt de bezoeker eerst naar een wit scherm. Daarna verschijnt tekst in een fallback-font dat verspringt zodra de web fonts binnen zijn, met lege rondjes waar de iconen horen.

De browser leest vooruit door de HTML (de preload scanner) en vraagt elk bestand dat hij daar tegenkomt direct aan. Een bestand dat in een ander bestand staat, ontdekt hij pas als dat andere bestand binnen is: een font in een stylesheet, een stylesheet achter een @import, of een script dat door een script wordt toegevoegd. Elk niveau voegt een roundtrip naar de server toe voordat het volgende request kan starten.

Een bestand op een ander domein wacht nog langer: de browser zet eerst een verbinding op (DNS, TCP en TLS). Op een mobiel netwerk duurt dat een veelvoud van een request over een open verbinding. Op de tandartspagina zitten de Google Fonts vier niveaus onder de HTML, achter twee @imports, waarvan de laatste twee op nieuwe domeinen staan (fonts.googleapis.com, fonts.gstatic.com). Render-blocking requests legt uit waarom een stylesheet de first paint tegenhoudt.

Hoeveel sneller is de pagina met een platte tree?

Na de fix rendert de tandartspagina een seconde eerder en staan de eigen fonts er bijna twee seconden sneller op. Ik heb drie versies gemeten. Before heeft de twee @imports. Links linkt dezelfde bestanden in de HTML, zoals WordPress ze met wp_enqueue_style inlaadt. After voegt de parent- en child-stylesheets samen in één bestand, host de fonts op het eigen domein van de site (alle drie gepreloaded) en toont de iconen als inline SVG.

Tijden in seconden, op een telefoon met throttling (Slow 4G, 4x tragere CPU). Niveaus en traagste keten (Maximum critical path latency in het rapport) komen uit Lighthouse 13.6 met dezelfde throttling.

Twee seconden na de start van de laadtijd op dezelfde telefoon met throttling.

Links levert al de meeste winst op de first paint op doordat de twee @import-niveaus weg zijn, al wachten de fonts en iconen nog op hun eigen domeinen. De LCP, de hero image, komt na de fix 0,4 s eerder. Links haalt de vroegste LCP omdat de foto de bandbreedte daar bijna voor zichzelf heeft; in After moeten de drie gepreloade fonts die delen. Daarom preloadt de fix er één of twee.

Wil je zien of echte bezoekers wachten op de keten? Splits dan mobiele LCP op in onderdelen in CoreDash: late stylesheets en fonts zie je terug als een lange render delay, de wachttijd nadat de LCP-afbeelding binnen is of, bij tekst, na de first byte.

CoreDash op mobiel, p75, tekst als LCP-element: vergelijk Render Delay met Time to First Byte.

Wat betekenen Preconnected origins en Preconnect candidates?

Een preconnect (<link rel="preconnect">) zet de verbinding met een domein alvast op voordat de browser er een bestand van nodig heeft. Preconnected origins toont de domeinen waarmee je pagina al een preconnect opzet; Preconnect candidates toont domeinen waarvan een bestand alsnog een verbinding moest opzetten, inclusief de winst die een preconnect kan opleveren (Est LCP savings).

Dezelfde tandartspagina met een grote, lazy-loaded hero image, Lighthouse 13.6 met DevTools-throttling.

• "Unused preconnect. Only use preconnect for origins that the page is likely to request." De pagina laadde niets van dat domein, hier maps.googleapis.com en www.youtube.com. Verwijder de preconnect zodra je hebt gecontroleerd of geen enkel ander template, zoals de checkout, hem gebruikt.
• "Unused preconnect. Check that the crossorigin attribute is used properly." Een font vereist een verbinding die is geopend met crossorigin; een stylesheet of script juist zonder. cdnjs.cloudflare.com levert aan de tandartspagina zowel de stylesheet van Font Awesome als het bijbehorende font. De stylesheet gebruikte de preconnect, waarna het font een tweede verbinding opende. Host het font zelf. Kan dat echt niet, voeg dan voor dat domein een tweede preconnect toe met crossorigin.
• "More than 4 preconnect connections were found." Elke preconnect bouwt een verbinding op tegelijk met de bestanden die de pagina als eerste nodig heeft. Host wat je kunt op je eigen domein, en bewaar preconnect alleen voor een kritiek bestand op een domein waar je niet omheen kunt.
• Een domein onder Preconnect candidates. Verplaats dat bestand naar je eigen domein. Lukt dat niet en is het bestand kritiek, zet er dan een preconnect voor.

Kun je Google Fonts nog niet zelf hosten, link de stylesheet dan in de HTML en zet een preconnect naar fonts.gstatic.com, mét crossorigin; de browser verbindt met fonts.googleapis.com zodra hij de link leest. Er blijft dan wel een keten over.

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Preconnect-instellingen in plugins gaan niet altijd goed om met crossorigin: DNS Preconnect van LiteSpeed Cache plaatst het bij geen enkel domein, en Perfmatters doet het alleen als je het vinkje aanzet. Controleer je paginabron: alleen font-domeinen hebben het nodig.

Hoe los je de Network dependency tree op?

Begin bij de traagste keten — degene die Lighthouse oranje markeert — op de diepste rij. Vraag je bij elk bestand af: kan dit bestand in de HTML worden genoemd, of van mijn eigen domein komen?

Google Fonts en andere web fonts

Zonder code zet je de instelling aan die Google Fonts op je eigen domein host: Self-host Google Fonts in WP Rocket of FlyingPress, Local Google Fonts in Perfmatters, Load Google Fonts Locally in Elementor (Settings, Performance), of de OMGF-plugin. De instelling van WP Rocket mist een Google Fonts-@import in de stylesheet van het theme. Staat fonts.googleapis.com daarna nog steeds in de tree, verwijder dan de @import (zie de volgende sectie). Een optie die Google Fonts 'asynchroon' laadt met een font-loader-script, zoals in LiteSpeed Cache en Autoptimize, voegt juist een extra niveau toe aan de keten: host de fonts liever zelf.

Handmatig zet je de @font-face-regels in je eigen stylesheet, met de woff2-bestanden in een fonts-map ernaast:

@font-face {
  font-family: "Poppins";
  font-style: normal;
  font-weight: 700;
  font-display: swap;
  src: url("fonts/poppins-v24-latin-700.woff2") format("woff2");
}

Een font kan alleen in een stylesheet worden aangeroepen, dus alleen een preload verkort deze keten. Gebruik minder font-bestanden en preload er één of twee — begin met het font van je grootste tekst op het eerste scherm — en controleer daarna de LCP:

<link rel="preload" href="/wp-content/themes/acme-smile/fonts/poppins-v24-latin-700.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/wp-content/themes/acme-smile/fonts/open-sans-v44-latin.woff2" as="font" type="font/woff2" crossorigin>
<link rel="stylesheet" href="/wp-content/themes/acme-smile/style.css?ver=2.5.0">

De preload heeft crossorigin nodig, ook op je eigen domein, anders downloadt het font twee keer. Font display legt font-preloads uit.

In Next.js host en preloadt next/font de fonts al automatisch: vervang een handgeschreven @import url(https://fonts.googleapis.com/...) in een CSS-bestand door next/font.

WordPress-themes met @import

Verwijder je een Google Fonts-@import uit het parent theme, dan komt die bij de volgende update gewoon weer terug: zoek naar een font-instelling in het theme of vraag de developer om de fonts te enqueue'en.

Een @import van de parent-stylesheet in de style.css van een child theme voegt een niveau toe. Vraag de maker van het theme om een child theme zonder die import, of stuur een developer de tree uit het rapport en deze code voor de functions.php van het child theme, die de @import vervangt:

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
} );

Controleer de paginabron daarna: de parent-stylesheet mag maar één keer laden.

Icon fonts

Font Awesome en de iconen van Elementor laden een stylesheet die weer een font inlaadt met daarin elk icoon. Zet in Elementor Inline Font Icons aan: dat vervangt de stylesheet en het font door inline SVG. Vervang elders de iconen die de pagina gebruikt door inline SVG, of host Font Awesome op je eigen domein.

Shopify

Kies je fonts in de theme editor (Theme settings, Typography) in plaats van Google Fonts-code in theme.liquid te plakken: het theme serveert ze dan vanaf het eigen domein van je shop, en Dawn (plus themes die daarop zijn gebaseerd) preloadt ze. App-embeds die een stylesheet toevoegen, duiken op in de tree: zet ze één voor één uit en run Lighthouse opnieuw. Shopify stuurt in de headers van de pagina eigen preconnects mee: naar het eigen CDN en naar de eerste drie andere domeinen waar je blocking bestanden vandaan komen. Lighthouse telt die mee voor zijn limiet van vier. Verwijder een oude preconnect naar cdn.shopify.com uit theme.liquid en voeg er zelf alleen één toe voor een domein dat je tree echt nog nodig heeft; elke app-embed die je uitzet, kan er één van Shopify schelen. Blijft "More than 4 preconnect connections" staan terwijl alleen die van Shopify zelf over zijn? Laat het dan zo.

Bestanden die een script toevoegt, en services die je niet kunt aanpassen

Een stylesheet die door een script wordt toegevoegd, wacht op dat script: heeft het eerste scherm die nodig, zet de link dan in de HTML; zo niet, defer het script. Een consent tool die als eerste moet draaien blijft blocking. Laadt die bestanden van een tweede domein waar je niet omheen kunt, zet dan een preconnect naar dat domein. Heeft je server tijd nodig om de HTML op te bouwen, dan stuurt 103 Early Hints de preconnect en de font-preload al vóór de HTML zelf.

Waarom is de tree na de fix nog steeds rood?

Lighthouse kleurt de melding al rood zodra de HTML één stylesheet laadt, dus een pagina zonder keten blijft rood. Dat rood mag je laten staan: het betreft de HTML en de bestanden die de HTML zelf noemt. Elke rij die onder een ander bestand inspringt, is een keten om te fixen:

• Fonts onder je eigen stylesheet. Gebruik minder bestanden en preload er één of twee. Een font dat niet op het eerste scherm te zien is, is de enige keten die mag blijven staan.
• Bestanden die een service toevoegt. Cloudflares Email Obfuscation (email-decode.min.js) en Web Analytics-beacon, of guest.vary.php van de Guest Mode in LiteSpeed Cache. Zet die feature uit.

Door een bekende bug in PageSpeed Insights komen requests van andere sites soms in de tree terecht: run de test opnieuw.

De tandartspagina waarbij elke keten is verdwenen, Lighthouse 13.6 met DevTools-throttling.

Hoe controleer je of de tree korter is geworden?

Run Lighthouse opnieuw en vergelijk eerst de niveaus en de traagste keten; de Maximum critical path latency schommelt immers per run. De Initiator-kolom in het Network-paneel van Chrome DevTools toont welk bestand elk request heeft gedaan. Voor echte bezoekers volg je vanaf de volgende bezoeken FCP en LCP op mobiel in CoreDash; Search Console doet er tot 28 dagen over.

Komt je langste keten uit een theme of page builder die je niet kunt aanpassen, of een app die eigen fonts laadt? In een Core Web Vitals power hour lopen we samen door je tree, bestand voor bestand. We bepalen welke bestanden naar je eigen domein verhuizen, welke direct in de HTML komen en welk domein nog een preconnect nodig heeft.