Wordpress en resource hints

Verkeerd gebruik van resource hints

De kunst is namelijk om de inzet van resource hints niet te overdrijven. Het is verleidelijk om vervolgpagina's, of bronnen die op een volgende pagina gebruikt worden, reeds vooraf in te laden. Dit terwijl je niet zeker weet of een gebruiker de volgende pagina überhaupt zal bereiken. De ene website of webapplicatie leent zich dan ook beter voor gebruik van resource hints dan de ander.

Wordpress praktijk voorbeeld van resource hints

Wordpress is dan ook een voorbeeld van hoe het niet moet. Zonder aanvullende aanpassingen, zal Wordpress vanaf versie 4.6, automatisch resource-hints onder de noemer dns-prefetch toevoegen aan de broncode. Hierin is het volgende te ontdekken:

• Wordpress brengt geen gradatie aan in het type resource hint, en geeft ze allemaal eerste prioriteit. Je Wordpress site dwingt bij de browser af dat het tot stand brengen van een DNS verbinding plaats moet vinden, waarmee andere processen vertraagd kunnen worden;
• Sommige domeinen die via de resource hints prioriteit mee krijgen, wordt niet gebruikt. Het domein s.w.org werd op de betreffende site enkel gebruikt voor de tegenwoordig (sinds Wordpress 4.2) standaard ingeladen emoticons. Zelfs als je wel gebruik wilt maken van emoticons, is het naar mijn idee van dusdanig secundair belang, dat een DNS lookup inclusief hand-shake niet middels een dns-prefetch resource hint afgehandeld hoeft te worden;
• Meerendeel van de domeinen zullen van secundair belang zijn. De s.gravatar.com verwijzing heeft geen prioriteit, omdat de avatar-afbeelding in deze specifieke situatie, pas in de footer terecht komt. Veelal zal men niet direct in de eerste milliseconden in de footer terecht komen, en zelfs dan is het geen ramp als een afbeelding iets later laadt. Ook het lettertype (fonts.googleapis.com) is in mijn ogen geen topprioriteit, waardoor deze niet via de dns-prefetch resource hint binnengehaald hoeft te worden

HTTP/2 effect

Domein-namen van externe bronnen lijken dus lukraak omgezet te worden in resource hints, maar te veel resource hints van hetzelfde type op hetzelfde moment, kan er voor zorgen dat de laadtijd juist hoger ligt, doordat de browser vooraf meer gelijktijde en vergelijkbare taken te verwerken krijgt. Zelfs het HTTP/2 protocol, lost dit niet, en door resource hints op deze manier in te zetten, zou je kunnen claimen dat je het effect van HTTP/2 (meerdere HTTP requests parallel afhandelen) juist teniet doet, terwijl juist Wordpress baat heeft bij HTTP/2.

Ook onnodige resource hints komen dus om de hoek kijken. Niet opgenomen in de screenshot, was een resource hint voor het domein v0.wordpress.com. Frappant genoeg werd er geen enkel bestand van die omgeving ingeladen. Het spreekt voor zich dat wij deze resource hints hebben verwijderd uit de broncode van de betreffende Wordpress site.

Resource hint tips uit het veld

In mijn speurtocht naar de Wordpress versie waarin resource hints standaard ingebakken worden, stuitte ik op dit artikel, een hosting-partij uit Groningen toegespitst op onder meer Wordpress hosting. Echter slaan ze in hun resource hint aanbeveling de plank enigszins mis. Hun advies is om in het geval van artikelen, ook het vorig en volgend bericht in te laden middels resource hints, zodat deze pagina's sneller laden. Alhoewel die stelling correct is, vind ik het als advies omtrent het inzetten van resource hints, niet op zijn plaats.

Je veroorzaakt niet enkel een flinke toename van eigen (moeilijk traceerbaar) dataverkeer, ook je gebruikers zadel je op met dataverkeer dat wellicht nooit benut gaat worden. Vooral mobiele gebruikers onderweg, kun je hier pijn mee doen.

Goed gebruik van resource hints

Wanneer de kans erg groot is dat men verder navigeert naar een specifieke pagina (bijvoorbeeld, in een onderverdeeld artikel, inlogscherm, of een inschrijfformulier), dan kun je gericht een prefetch of prerender resource hint inzetten. Is één artikel opgedeeld in meerdere pagina's? Dan is de stap zeer groot dat men doorklikt naar het tweede deel van hetzelfde artikel. Inzetten van deze resource hints valt echter eerder onder misbruik (van zowel je eigen dataverkeer als ook dataverkeer van je bezoeker), wanneer je resource hints gebruikt om op zichzelf staande pagina inlaadt, zoals een vorig of volgend artikel.

Wanneer specifieke bronnen op externe omgevingen per direct benodigd zijn, kun je perfect dns-prefetch of preconnect inzetten. Op blue2blond.nl zijn we voorzichting omgesprongen met resource hint; Het is enkel ingezet waar nodig. We gebruiken bijvoorbeeld de preconnect resource hint voor het domein fonts.gstatic.com. De eerste maal wordt namelijk de font asynchroon ingeladen, en daardoor is de tot stand koming van een verbinding met dat domein, niet van primair belang.

Wel gebruiken we de jQuery framework. Deze wordt vanaf een CDN omgeving gehaald. Om de DNS lookup te bespoedigen, hebben we hiervoor de dns-prefetch resource hint ingezet. Vervolgens, om verder te optimaliseren, hebben we afgedwongen dat ook de FontAwesome bronnen vanaf dezelfde omgeving wordt geserveerd, om DNS lookups en dus ook benodigde resource hints te reduceren.

Conclusie

Wordpress blijkt in het voorschotelen van resource hints dus niet subtiel te zijn, en kan op zichzelf dus juist voor een tegendraads effect zorgen in het versnellen van je website. Probeer hier dus in te snijden, wanneer je gebruik maakt van Wordpress. Overweeg de inzet goed: vaak zijn browsers goed in staat om de prioriteit omtrent te verwerken DNS aanvragen zelf uit te pluizen. Laat een prefetch of prerender van een specifieke pagina of bronbestand dus enkel plaats vinden wanneer het een onontkomelijk vervolgstap is.

Zelf praktische voorbeelden van het inzetten van resource hints, of juist vragen over het toepassingen van een resource hint? Deel ze gerust!