Een snelle homepage maar trage campagnepagina

De eerste fout zit meestal in de proefopzet. Je test de homepage, terwijl je campagne verwijst naar een aparte pagina, vaak met tracking-parameters achter de URL. Verzamel daarom eerst de echte instap-URL's:

1. Haal uit je advertentieaccount of nieuwsbriefmail de exacte bestemmings-URL, inclusief parameters.
2. Kijk in je analysetool welke pagina's het meeste verkeer als eerste pagina krijgen.
3. Noteer per URL het paginatype: homepage, campagnepagina, productpagina, blogartikel.
4. Test elk type apart. Een homepage vergelijken met een landingspagina met formulier, video en chatwidget is geen eerlijke proef.

Test ook de versie met tracking-parameters. Sommige tagconfiguraties laden alleen extra scripts wanneer een parameter aanwezig is. Dan meet je zonder parameter een lichtere pagina dan je bezoeker ziet. Meet bovendien op een mobiel toestel of met mobiele emulatie, want veel campagneverkeer komt via telefoon.

Volgens de cursus Learn Performance van web.dev begint elke site met een aanvraag voor een HTML-document, en die eerste aanvraag speelt een grote rol in de laadsnelheid. Dezelfde cursus behandelt ook render-blocking en parser-blocking resources, afbeeldingen, video, webfonts en het opsplitsen van JavaScript. Dat zijn precies de onderdelen die per paginatype verschillen.

Een campagnepagina bevat vaak een grote headerafbeelding of achtergrondvideo, een formulier van een externe tool, een chatwidget, een cookiebanner en extra trackingscripts. Een homepage heeft soms net minder van die onderdelen, of laadt ze later. De MDN-pagina over webprestaties beschrijft dat prestaties zowel objectieve metingen omvatten (laadtijd, tijd tot interactief) als de ervaren snelheid van de gebruiker. Je kijkt dus naar twee dingen: wanneer verschijnt zichtbare inhoud, en wanneer reageert de pagina op een tik of klik.

1. Kies twee URL's: de homepage en de belangrijkste campagnepagina, beide op dezelfde manier getest (zelfde toestel of emulatie, zelfde netwerkprofiel, zelfde browser).
2. Bewaar de metingen als vaste uitgangssituatie. Noteer datum, URL, toestel en gebruikte tool. Zonder uitgangspunt kun je later niets vergelijken.
3. Open het netwerkpaneel van je browser (de ontwikkelaarstools; de exacte menunamen verschillen per browser) en laad de pagina met uitgeschakelde of eerst leeggemaakte cache, zodat je meet wat een nieuwe bezoeker ziet.
4. Sorteer de aanvragen op grootte en op starttijd. Zoek de grootste bestanden en de aanvragen die pas laat starten.
5. Groepeer per herkomst: eigen server, externe widget, advertentie- of trackingdienst, lettertypen.
6. Verwijder of stel uit, één ding tegelijk, in een testomgeving of via je tagbeheer, en meet opnieuw. Wijzig nooit vijf dingen in één keer, anders weet je niet wat gewerkt heeft.
7. Controleer ook of de pagina nog functioneert: formulier verstuurbaar, knop bruikbaar, meting nog actief.

Resultaten uit dit proces gelden voor jouw pagina op dat moment. Meetwaarden schommelen van run tot run, dus herhaal elke meting meerdere keren voordat je conclusies trekt.

Gebruik dit blad om per gevonden onderdeel een keuze te maken. Het zijn werkregels, geen universele wetten.

De cursus van web.dev bespreekt resource hints als hulp om bronnen eerder te laten laden. Zet ze alleen in na een meting, want een hint op het verkeerde bestand kan bandbreedte kosten zonder dat het iets oplost.

Dit is een fictief voorbeeld met alleen invoer en te verwachten controles. De getallen dienen om de werkwijze te tonen, niet als uitkomst.

Invoer: een kmo heeft een homepage en een campagnepagina voor een najaarsactie. De homepage bevat een tekstblok, drie kleine afbeeldingen en één script. De campagnepagina bevat een grote achtergrondafbeelding, een ingesloten video, een chatwidget, een extern aanmeldformulier en drie trackingscripts.

Telling van externe aanvragen (fictief): homepage 6 aanvragen, campagnepagina 23 aanvragen, waarvan 14 van externe domeinen.

Redenering: het verschil in aantal aanvragen en in herkomst is al een aanwijzing dat de twee pagina's niet vergelijkbaar zijn. Je kiest de meest verdachte onderdelen: de video en het formulierscript.

Te voeren controles:

• Meet beide URL's met dezelfde instellingen en bewaar de uitgangswaarden.
• Vervang de video tijdelijk door een stilstaand beeld op een testkopie en meet opnieuw.
• Laad de chatwidget pas na een klik en meet opnieuw.
• Controleer of het formulier en de meting nog werken.

Het resultaat per stap kan je alleen zelf vaststellen; het scenario voorspelt het niet.

Een lichtere pagina mag niet ten koste gaan van bruikbaarheid. De tutorials van W3C WAI tonen hoe je webinhoud toegankelijk maakt, onder meer voor afbeeldingen en formulieren, en wat dat ook voor andere bezoekers oplevert. Controleer dus bij elke aanpassing het volgende:

• Een vervangende afbeelding heeft een passende alternatieve tekst.
• Een uitgestelde chatwidget blijft met toetsenbord bereikbaar.
• Het formulier behoudt zichtbare labels en foutmeldingen.

Voor de overdracht aan een bureau of collega: geef de exacte URL's mee (met parameters), het toestel en de testmethode, de uitgangswaarden, de lijst met onderdelen en je beslissing per onderdeel. Zo kan iemand anders je proef herhalen. Wil je ook zien welke signalen je website publiek toont, bekijk dan Marketing Scan. Een publieke scan meet zichtbare signalen en vervangt geen volledige technische analyse van je campagnepagina.