Preload en fetchpriority

Met <link rel="preload"> vertel je de browser: dit bestand heb je straks nodig, haal het nu al op. Dat is nuttig voor bestanden die de browser anders pas laat ontdekt, zoals een webfont uit een CSS-bestand of een hero-afbeelding die via JavaScript of als CSS-achtergrond wordt geladen.

Fetchpriority is een attribuut op img, link en script met de waarden high, low of auto. Het verandert niet wanneer de browser een bestand ontdekt, maar hoe hoog het in de wachtrij staat. Een img met fetchpriority="high" wordt eerder opgehaald dan andere afbeeldingen op de pagina. Het attribuut wordt ondersteund door Chrome, Edge, Safari en Firefox.

Het verschil in één zin: preload lost een ontdekkingsprobleem op, fetchpriority een prioriteitsprobleem. Staat je productfoto gewoon als img in de HTML, dan is fetchpriority meestal genoeg.

Bij de meeste webshops is de LCP een afbeelding: de hoofdfoto op de productpagina, de banner op de homepage of de eerste productkaarten op een categorie. Browsers geven afbeeldingen standaard een lage prioriteit tot ze weten dat die in beeld staan. Daardoor wacht de belangrijkste foto vaak achter scripts, fonts en andere afbeeldingen.

Met fetchpriority="high" op die ene afbeelding los je dat op. Het is een kleine wijziging in het template die vaak direct zichtbaar is in de LCP. Voorwaarde is wel dat de afbeelding niet lazy geladen wordt. Een img met loading="lazy" boven de vouw wordt pas laat opgehaald, wat je ook aan prioriteit doet.

Fonts zijn het tweede veelvoorkomende geval. Een webfont wordt pas ontdekt als de browser de CSS heeft gelezen. Een preload van het belangrijkste font voorkomt dat tekst lang onzichtbaar blijft of verspringt als het font binnenkomt. Beperk je tot het font dat in de koppen en de navigatie boven de vouw staat.

In Hyvä pas je de templates voor de productgalerij en de homepage-banner aan: de eerste afbeelding krijgt loading="eager" en fetchpriority="high", de rest blijft lazy. Fonts preload je via de head-layout, met crossorigin erbij, anders haalt de browser het font twee keer op. In Luma laadt de galerij via JavaScript; daar helpt een preload van de eerste productfoto in de head.

Shopify kent bij de image_tag-filter een preload-optie. Shopify zet dan een Link-header voor die afbeelding, wat de browser nog eerder laat beginnen. Shopify zelf adviseert preloads spaarzaam te gebruiken en de LCP-afbeelding nooit lazy te laden. Fetchpriority voeg je als gewoon HTML-attribuut toe in het template.

In Laravel met Vite helpt de Vite-integratie met het preloaden van JavaScript-modules. Voor de hero- of productafbeelding zet je fetchpriority zelf in de Blade-component.

Te veel preloaden. Elke preload concurreert om dezelfde bandbreedte. Tien preloads betekent dat niets meer voorrang krijgt. Beperk het tot één of twee bestanden die echt het verschil maken.

Ook fout: een preload voor een afbeelding die op mobiel niet getoond wordt, of een preload zonder imagesrcset waardoor de browser het verkeerde formaat ophaalt en daarna nog een keer het juiste. En fetchpriority="high" op alle afbeeldingen in een slider, wat het effect volledig tenietdoet.

Meet het effect met de field data, niet alleen met één Lighthouse-run. Een preload die in het lab helpt, kan op echte apparaten andere bestanden verdringen. Kijk een paar weken na de wijziging naar je LCP in CrUX of je RUM-tool.