Preload toegevoegd maar pagina wordt niet sneller

Resource hints zijn volgens de cursus Learn Performance van web.dev een verzameling HTML-functies die de browser kunnen helpen om resources eerder te laden, mogelijk met een hogere prioriteit. Let op het woord 'kunnen': het is een hulpmiddel, geen versneller die altijd werkt.

Een preload verplaatst alleen het moment waarop de download start. Hij maakt een bestand niet kleiner, hij maakt je server niet sneller en hij verhelpt geen trage JavaScript-uitvoering. Als je pagina vooral wacht op een zware script, op een traag antwoord van je server of op een niet-geoptimaliseerde afbeelding, dan verandert een preload daar weinig aan.

Een preload kan zelfs nadelig uitpakken. Elke gepreloade resource neemt bandbreedte in beslag op een moment waarop andere bestanden die bandbreedte ook nodig hebben. Hoe meer je als belangrijk markeert, hoe minder die markering nog onderscheidt.

Voor je iets wijzigt, leg je een nulmeting vast. Zonder die meting weet je achteraf niet of je hint iets deed. Werk in deze volgorde:

1. Kies één concrete pagina en één concreet doel, bijvoorbeeld 'het grootste zichtbare element verschijnt eerder' of 'de tekst staat er zonder lettertypeflits'.
2. Meet de pagina meerdere keren in dezelfde omstandigheden: zelfde browser, zelfde netwerkprofiel, lege cache. Eén meting zegt weinig, omdat uitkomsten schommelen.
3. Noteer in het netwerkoverzicht van de ontwikkelaarstools wanneer de gepreloade resource start en eindigt, en welke prioriteit de browser eraan geeft.
4. Noteer ook welk element of welke gebeurtenis het eigenlijke knelpunt vormt.

MDN's overzicht over webprestaties maakt onderscheid tussen objectieve metingen en de ervaren snelheid. Houd beide bij: een hint kan een meetwaarde verbeteren zonder dat gebruikers iets merken, of omgekeerd.

Beperk je tot één wijziging per test. Voeg je tegelijk een preload, een afbeeldingsoptimalisatie en een scriptwijziging toe, dan weet je niet welke maatregel het verschil maakte.

De meest voorkomende oorzaak van een nutteloze preload is een bestand dat niet, of niet op tijd, wordt gebruikt. Browsers tonen in de console vaak een waarschuwing wanneer een gepreloade resource niet kort na het laden daadwerkelijk wordt toegepast. Zo'n waarschuwing is een signaal om serieus te nemen. Welke exacte tekst je ziet, verschilt per browser en versie, dus lees de melding in jouw browser zelf.

Controleer deze oorzaken, in deze volgorde:

• Verkeerde URL. Het adres in de preload wijkt af van het adres dat de pagina later opvraagt, bijvoorbeeld door een versienummer, een queryparameter of een ander domein. De browser haalt het bestand dan twee keer op.
• Verkeerd type of attribuut. Bij lettertypes kan een ontbrekend of afwijkend cross-origin-attribuut ertoe leiden dat het bestand dubbel wordt opgehaald. Controleer dit in het netwerkoverzicht van je eigen browser en in de documentatie, want het gedrag hangt af van het resourcetype.
• Pagina gebruikt het bestand niet. Na een redesign of een themawissel staat de hint er nog, maar de afbeelding of het script komt niet meer voor.
• Gebruik komt te laat. Het bestand wordt pas na een gebruikersactie of lang na het laden ingezet. Dan bespaar je niets en kost de preload bandbreedte.

Verwijder de hint tijdelijk en meet opnieuw. Verandert er niets aan het laadgedrag, dan droeg hij niets bij en kan hij weg.

Een preload staat niet los van de rest. Volgens web.dev bepalen render-blocking en parser-blocking resources in hoge mate hoe snel een pagina in beeld verschijnt. Een gepreloade resource moet dus bandbreedte delen met precies die bestanden.

Gebruik dit beslisblad om per hint te oordelen:

Preload alleen wat de browser pas laat ontdekt, zoals een afbeelding die vanuit CSS wordt aangeroepen of een lettertype dat pas na het parsen van de stijlen bekend raakt. Een resource die al vroeg in de HTML staat, wordt vaak al vroeg ontdekt. Controleer in het netwerkoverzicht of een hint dan nog iets aan het starttijdstip verandert.

Dit is een denkbeeldig voorbeeld, bedoeld om de procedure te tonen. Er zijn geen echte metingen of resultaten achter dit scenario.

Een kmo heeft op een dienstenpagina drie hints toegevoegd: één voor een lettertype, één voor een achtergrondafbeelding in CSS en één voor een script van een externe widget. Een collega neemt het dossier over en volgt de procedure.

Invoer: de pagina, het netwerkprofiel dat je kiest, en de drie hints.

Verwachte controles, per hint:

1. Lettertype: staat het cross-origin-attribuut erop, en komt de URL exact overeen met de URL in de stijlregel? Verschijnt er een tweede download van hetzelfde bestand?
2. Achtergrondafbeelding: staat deze boven de vouw en wordt hij direct getoond? Zo niet, dan is een preload waarschijnlijk overbodig.
3. Widgetscript: wordt het pas na een klik gebruikt? Dan hoort het niet vooraan in de wachtrij.

Het verwachte overdrachtsresultaat is geen versnelling, maar een tabel met per hint: gebruikt ja/nee, URL's gelijk ja/nee, prioriteit zichtbaar in de tools, en het besluit behouden, aanpassen of verwijderen. Wat de nieuwe laadtijd wordt, weet je pas na meting op jouw eigen pagina.

Een wijziging is pas afgerond als je het effect hebt gecontroleerd. Herhaal dezelfde meting als in stap 1, onder dezelfde omstandigheden, en vergelijk met je nulmeting. Kijk naar het starttijdstip van het bestand, de volgorde in het netwerkoverzicht en het verdwijnen van waarschuwingen.

Ga daarna na of er geen nieuw probleem is ontstaan. Een hint kan het ene bestand versnellen en een ander vertragen. Controleer ook dat de pagina nog goed werkt voor wie met een toetsenbord of hulptechnologie navigeert: de WAI-tutorials van W3C geven richtlijnen voor toegankelijke content. Controleer zelf of uitgestelde of anders geladen content nog bruikbaar blijft; zo'n check bewijst geen volledige WCAG-conformiteit.

Leg tot slot vast wat je deed en waarom: welke hints blijven, welke zijn weggehaald, en onder welke omstandigheden je hebt gemeten. Dat voorkomt dat iemand over een half jaar dezelfde hints weer toevoegt.

Wil je weten welke zichtbare signalen van je website opvallen, dan kun je die bekijken via Marketing Scan. Een publieke scan meet wat van buitenaf zichtbaar is en bewijst niet hoe je site technisch is opgebouwd.