Een browser is een verrassend braaf apparaat: hij ontdekt pas dat hij iets nodig heeft op het moment dat hij het tegenkomt. Daardoor ontstaat een keten van wachten. Deze preload preconnect uitleg gaat over de aanwijzingen waarmee u die keten doorbreekt, zodat de browser alvast begint met wat hij toch nodig heeft.
Het zijn kleine ingrepen: enkele regels in de kop van uw pagina. Goed toegepast levert het een halve seconde op. Verkeerd toegepast maakt het uw site langzamer, en dat gebeurt vaker dan u denkt.
Waarom er überhaupt gewacht wordt
Neem een pagina met een lettertype dat via een stylesheet wordt ingeladen. De browser haalt eerst de HTML op. Daarin staat een verwijzing naar het stylesheet, dus dat wordt opgehaald. Pas als het stylesheet binnen is, ontdekt de browser dat er ook nog een lettertypebestand nodig is. Drie stappen achter elkaar, elk met een volledige ronde naar de server.
Op een vaste verbinding kost dat misschien honderd milliseconden. Op 4G, met honderd milliseconden vertraging per ronde, bent u zomaar een halve seconde kwijt aan wachten waarin niets wordt gedownload. Dat is precies het gat dat deze aanwijzingen dichten.
Preload, preconnect: uitleg van de vier hints
Preconnect zegt: leg alvast een verbinding met deze server. De naam wordt opgezocht, de verbinding opgezet en de beveiligde handdruk afgehandeld, allemaal voordat er iets gevraagd wordt. Dat bespaart doorgaans honderd tot driehonderd milliseconden per externe partij. Gebruik dit voor diensten waarvan u zeker weet dat u ze nodig heeft: uw lettertypeleverancier, uw contentnetwerk, uw betaaldienst.
Preload zegt: haal dit bestand nu op, ik heb het straks nodig. Dit is de sterkste hint en de enige die u met beleid moet inzetten. Typische toepassing: het lettertype voor uw lopende tekst, of de grote afbeelding boven aan de pagina.
DNS-prefetch is het lichte broertje van preconnect: alleen de naam wordt opgezocht, verder niets. Nuttig als terugval voor oudere browsers, of voor domeinen die u misschien nodig heeft.
Prefetch zegt: haal dit vast op voor een volgende pagina, maar met lage prioriteit. Handig bij een duidelijke route, bijvoorbeeld van een productpagina naar de winkelwagen.
Er is nog een vijfde variant die u tegenkomt in instellingenschermen: de aanwijzing waarmee een browser de volgende pagina alvast helemaal opbouwt. Dat voelt razendsnel voor de bezoeker die inderdaad doorklikt, maar u laat de server dan werk doen voor mensen die dat misschien niet doen. Op een webshop met filters is dat zelden verstandig; bij een handleiding met een duidelijke volgorde van hoofdstukken kan het juist prettig uitpakken.
Waar het misgaat
Deze aanwijzingen verdelen geen extra bandbreedte; ze verschuiven prioriteiten. Alles wat u naar voren haalt, duwt iets anders naar achteren. Vandaar deze valkuilen:
- Te veel preloads. Zet u acht bestanden op preload, dan concurreren die met elkaar en met uw HTML. Netto wordt de pagina trager. Houd het bij één tot drie.
- Preloaden wat u niet gebruikt. Laadt u alle zes lettertypevarianten voor terwijl er twee op de pagina staan, dan verspilt u bandbreedte op precies het verkeerde moment. De browser geeft daar in de console ook een waarschuwing over.
- Preconnect naar tien domeinen. Elke verbinding kost geheugen en rekenkracht op het toestel. Vier is een verstandig maximum.
- De verkeerde afbeelding voorladen. Op mobiel is het grootste element vaak een andere afbeelding dan op desktop. Preloadt u de verkeerde, dan haalt de bezoeker er twee binnen.
- Het attribuut crossorigin vergeten bij lettertypen. Zonder dat wordt het bestand twee keer opgehaald, wat het middel erger maakt dan de kwaal.
Wat u praktisch kunt doen in WordPress
- Zoek uit wat uw grootste element is. PageSpeed Insights noemt dat bij naam. Is het een afbeelding, dan is die de kandidaat voor preload.
- Kijk welke externe domeinen worden aangesproken in het netwerktabblad. Diensten die op elke pagina meedoen, zijn kandidaten voor preconnect.
- Gebruik de instellingen van uw cacheplugin. WP Rocket, LiteSpeed Cache en Perfmatters hebben hier allemaal een scherm voor, zodat u niet in de code hoeft.
- Meet voor en na, op mobiel. Werkt een hint niet aantoonbaar, haal hem dan weg. Dit is geen gebied voor verzamelwoede.
- Controleer de console op waarschuwingen over voorgeladen bestanden die niet zijn gebruikt. Dat is de snelste manier om fouten te vinden.
Zorg er wel voor dat de basis eerst klopt. Een afbeelding van drie megabyte voorladen maakt hem niet lichter; dan is verkleinen de echte oplossing. Dezelfde volgorde geldt voor lettertypen, zoals beschreven in het artikel over het gewicht van webfonts.
Houd de lijst met hints ook bij als uw site verandert. Wisselt u van lettertype, van chatdienst of van betaalprovider, dan wijzen de oude aanwijzingen naar bestanden en domeinen die niet meer bestaan. Dat levert geen zichtbare fout op, wel verspilde verbindingen en een browser die werk doet voor niets. Neem het daarom mee in de controle na elke grotere wijziging aan de site, samen met het nalopen van uw formulieren.
Hoeveel levert het op?
Realistisch: op een site met twee of drie externe diensten en een zwaar lettertype boekt u met preconnect en één gerichte preload doorgaans twee tot vier tienden van een seconde. Op een kale site die alles vanaf de eigen server serveert, wint u vrijwel niets, want dan is er geen keten om te doorbreken.
Het is dus geen wondermiddel maar een afronding. Wij zetten deze hints bij WebMaintor altijd als laatste stap in een optimalisatieronde waarin eerst het gewicht omlaag gaat, omdat ze pas zin hebben als er niets overbodigs meer wordt opgehaald.
Concrete volgende stap: kijk in PageSpeed Insights welk element als grootste wordt aangewezen op mobiel. Is dat een afbeelding die pas na twee seconden begint te laden, dan heeft u een goede kandidaat om voor te laden.
