Een contentupdate controleren met een snelheidsmeting

Snelheid is geen vast getal. De MDN-pagina over webprestaties (MDN: webprestaties) beschrijft performance als zowel objectieve metingen, zoals laadtijd en tijd tot interactiviteit, als de ervaren gebruikerservaring. Beide kunnen veranderen met netwerk, toestel en wat er op het moment van meten in de cache zit.

Een meting na je contentupdate vergelijken met een herinnering van 'het was vroeger sneller' levert dus niets op. Je hebt een nulmeting nodig die je vóór de wijziging vastlegt, en daarna een herhaling onder gelijke omstandigheden. Je beantwoordt zo een afgebakende vraag: is deze pagina, met deze taak en deze condities, na deze ene wijziging merkbaar trager of anders opgebouwd?

Bedenk ook wat een snelheidsmeting niet kan: ze toont geen oorzaak als je meerdere dingen tegelijk wijzigde, en ze bewijst niets over zoekresultaten of omzet.

Doe dit voor je iets aan de pagina wijzigt, en noteer alles in een eenvoudig document.

1. Kies de pagina en de exacte URL die je gaat aanpassen.
2. Definieer de taak: bijvoorbeeld 'pagina laden tot de hoofdafbeelding zichtbaar is' of 'pagina laden en naar het contactformulier scrollen'. Een vaste taak maakt metingen vergelijkbaar.
3. Leg de omstandigheden vast: toestel of emulatie, browser, netwerkprofiel en of de cache leeg is. Gebruik bij elke herhaling exact dezelfde instellingen.
4. Voer de meting meerdere keren uit en bewaar alle uitkomsten, niet enkel het beste. Verschillen tussen runs tonen hoe groot de ruis is.
5. Maak een schermafbeelding of export van de netwerkoverzicht-weergave, zodat je later per resource kunt vergelijken.

De MDN-pagina wijst erop dat je, om te testen voor gebruikers met trage of onbetrouwbare verbindingen, de prestaties onder hoge latentie kunt emuleren. Kies zelf een profiel dat bij je doelgroep past en houd het constant.

Voer nu één wijziging door. Voeg bijvoorbeeld de afbeeldingen toe, of de embed, maar niet allebei tegelijk, en pas niet tegelijk je thema aan. Een gecombineerde wijziging maakt de uitkomst onleesbaar.

Laat daarna de herhaalmeting volgen:

• Dezelfde pagina, dezelfde taak, dezelfde toestel- en netwerkinstellingen.
• Dezelfde stand van de cache als bij de nulmeting, bijvoorbeeld telkens leeg.
• Hetzelfde aantal herhalingen.
• Leg ook nu de resource-weergave vast.

Bekijk bij embeds vooral wat er extra gebeurt: een ingesloten video of widget van een derde partij haalt vaak scripts en bestanden van externe domeinen op. Het web.dev-leertraject over performance (web.dev: webprestaties leren) besteedt aparte modules aan afbeeldingen en video. Over afbeeldingen zegt de bron dat ze op veel pagina's een groot deel van de overgedragen data vormen; voor video en embeds meet je dat zelf in de resource-weergave. Kijk dus naar extra bestanden, hun grootte en het moment waarop ze starten, niet enkel naar het eindgetal.

Vergelijk nulmeting en herhaalmeting en gebruik onderstaande matrix om een volgende stap te kiezen. De richtlijnen zijn werkregels voor je eigen controle, geen vaste drempels.

Bij twijfel draai je de wijziging terug en meet je opnieuw onder dezelfde omstandigheden. Komt het resultaat dan terug op de nulmeting, dan heb je een sterke aanwijzing dat de wijziging de oorzaak was, hoewel externe factoren altijd mee kunnen spelen.

Een fictief voorbeeld, zonder verzonnen resultaten. Stel dat je een dienstenpagina uitbreidt met zes foto's van afgewerkte projecten en een ingesloten video van een externe videodienst.

Invoer:

• Pagina: de dienstenpagina.
• Taak: laden tot de eerste afbeelding volledig zichtbaar is.
• Omstandigheden: dezelfde browser, een emulatie van een trager mobiel netwerk, lege cache, vijf herhalingen.
• Eerste ronde: alleen de zes foto's toevoegen. Tweede ronde: de video erbij.

Verwachte technische controles:

1. Noteer na de nulmeting en na elke ronde de uitkomsten van alle vijf runs.
2. Tel in de resource-weergave hoeveel bestanden er bijkwamen en hoe groot de grootste afbeelding is.
3. Controleer of de foto's ver onder de bovenkant van de pagina pas laden wanneer de bezoeker dichterbij scrolt, en of er geen onnodig groot bronbestand voor een klein getoond beeld wordt gebruikt.
4. Controleer bij de video of er aanvragen naar het externe domein vertrekken voordat de bezoeker de video start.

Er is hier bewust niets over verbetering of verslechtering beweerd: je eigen meting beslist. Door twee afzonderlijke rondes te doen, kun je het effect van de foto's en van de video uit elkaar houden.

Een snelle pagina is niet automatisch een bruikbare pagina. Controleer na de update ook of de nieuwe afbeeldingen een zinvolle tekstalternatief hebben waar ze inhoud dragen, en of de embed met het toetsenbord bediend kan worden. De W3C-tutorials over webtoegankelijkheid (W3C: tutorials over webtoegankelijkheid) behandelen onder andere toegankelijke afbeeldingen met verschillende webtechnologieën. Neem een korte toegankelijkheidscheck mee in dezelfde sessie, zodat snelheid en toegankelijkheid niet tegen elkaar uitgespeeld worden. Zo'n check bewijst geen volledige WCAG-conformiteit.

Maak er een gewoonte van: bij elke contentupdate met zwaardere elementen noteer je een korte nulmeting en een herhaalmeting in hetzelfde document. Na enkele maanden zie je welke soort wijzigingen vaker problemen geven, en kun je een interne richtlijn opstellen, bijvoorbeeld over maximale afbeeldingsafmetingen of het uitstellen van embeds.

Wil je zien welke zichtbare signalen je website nu al uitstraalt, bekijk dan de publieke signalen via Marketing Scan. Een publieke scan meet wat van buitenaf te zien is en vervangt je eigen herhaalde snelheidsmeting op een gecontroleerd toestel niet.