Het evalueren van de prestaties van je eigen website is tegenwoordig heel eenvoudig. Eén of twee klikken en Google of een andere dienst spuugt resultaten uit met concrete suggesties voor oplossingen. Prachtig. Tenminste voor de eerste optimalisatieslag. Maar op het laatst, bij het fine-tunen, het veranderen van hoster of het opschonen van WordPress, wordt het belangrijk om te begrijpen welke tools nu eigenlijk de laadtijd meten en hoe je met deze gegevens om moet gaan.
Een paar jaar geleden schreef een klant ons over de supportchat. Hij was net verhuisd en vergeleek de prestaties van zijn website bij de oude hoster met zijn website bij Raidboxes. Hij vertelde ons dat de verhuizing niet echt de moeite waard was voor een prestatieverhoging van slechts 9 punten bij Google PageSpeed Insights .
In feite krijgen we voortdurend dergelijke verzoeken. Daarom heb ik eens gekeken welke informatie tools zoals Google PageSpeed Insights eigenlijk bieden voor interpretatie en hoe ze prestaties of laadtijd meten. Eerlijk gezegd verbaasde het resultaat me een beetje. Want: de betekenis van de waarden wordt meestal heel goed en gedetailleerd uitgelegd. Op twee punten gaan de helppagina's van de testaanbieders echter niet in detail:
- Welk gereedschap is geschikt voor welk doel?
- Welke gegevens kunnen worden geïnterpreteerd en gebruikt en hoe?
Tools zoals Google PageSpeed Insights meten de snelheid van je website niet
Het is al besproken in een andere blogpost: tests zoals Google PageSpeed Insights meten niet de laadtijd van je website, maar het optimalisatiepotentieel ervan. Ze bepalen hoe goed je website voldoet aan een vooraf gedefinieerde set prestatiecriteria. Bovendien geven de tests aanwijzingen voor het optimaliseren van het prestatiepotentieel. Er is echter één ding dat dergelijke tests expliciet niet doen: de laadtijd meten.
Op Google klinkt het als volgt:
PageSpeed Insights meet manieren om de prestaties van een site op de volgende manieren te verhogen:
- Tijd die nodig is om de inhoud zichtbaar te laden zonder te scrollen: Tijd die nodig is vanaf het aanvragen van een nieuwe pagina totdat de browser de inhoud zichtbaar maakt zonder te scrollen.
- Tijd die nodig is om de pagina volledig te laden: tijd vanaf het aanvragen van een nieuwe pagina totdat de browser de pagina volledig weergeeft.
Je ziet het: Google meet niet de snelheid, maar de "mogelijkheden om de prestaties te verhogen". Een cruciaal verschil. En dat betekent ook dat je aan de resultaten niet kunt zien hoe snel de pagina of het gedeelte dat zichtbaar is zonder te scrollen, daadwerkelijk laadt.
Prestatiehulpmiddelen zoals PageSpeed Insights laten zien waar je snel veel prestatiewinst kunt behalen.
Maar ook dat is geen probleem, want de tools leveren nog steeds waardevolle gegevens op voor optimalisatie, ook al meten ze de laadtijd niet. De verklaringen van dergelijke tests hebben de grootste toegevoegde waarde voor grote optimalisatiestappen, zoals het gebruik van caching of beeldcompressie.
Zodra het echter gaat om het optimaliseren van de laadtijd van een al geoptimaliseerde website, kunnen deze tests slechts beperkte inzichten bieden. In zo'n geval moet je een echte prestatiemeting uitvoeren. Dit geldt vooral als je van hostingprovider verandert. Want hoe goed de webserver zelf ook is, als de website vol staat met bouwsites, heeft zelfs een verandering van infrastructuur weinig zin.
Voor zo'n "echte" prestatiemeting kun je bijvoorbeeld de volgende hulpmiddelen gebruiken:
Met een van deze tests had de klant in een vergelijking precies kunnen zeggen waar zijn site welke prestatiewinst had na de verandering.
En dat brengt me bij het tweede punt van deze post: vooral hulpmiddelen als PageSpeed Insights verleiden je om voor een vergelijking waarden te gebruiken die maar beperkt of helemaal niet geschikt zijn. Want als je met puntenscores of beoordelingssystemen werkt, kom je al snel in een situatie die ik in dit artikel het schoolcijfer-dilemma noem.
Het dilemma van de schoolcijfers: cijfers zijn niet geschikt voor vergelijkingen
Tools als Google PageSpeed Insights, of Yahoo's YSlow geven twee soorten gegevens weer:
- een score voor de prestaties van de website
- concrete adviezen om dit cijfer te verbeteren
De scores zijn op een schaal van 0 tot 100, waarbij 100 de beste score is. Tot zover duidelijk. En intuïtief toegankelijk. Vooral omdat de scores worden ondersteund door een stoplichtsysteem.
Maar als het gaat om het vergelijken van twee partijen op basis van deze beoordelingen, is het interpreteren van de meetresultaten niet meer zo eenvoudig. In feite is het ongelooflijk moeilijk, zo niet onmogelijk. Want iedereen kan zien dat de pagina met de 90 waardering beter is dan die met de 80 waardering. Maar de volgende uitspraak kan niet meer worden gedaan: Door welke factor is de pagina met de 90 waardering beter dan de andere?
En dit beschrijft het probleem in de kern: Beoordelingssystemen staan zulke uitspraken eenvoudigweg niet toe. Je kent dit uit je schooltijd: degene die naast je zit heeft een C, maar jij hebt zelf een B. Zelfs als slechts één of twee punten jullie scheiden: Het resultaat is fundamenteel anders. En zonder de cijfersleutel van het papier te kennen, is het onmogelijk te zeggen hoe dicht het resultaat erbij lag.
De reden voor deze beperkte significantie is het zogenaamde schaalniveau van de meetgegevens. Ik wil daar hier echter niet in detail op ingaan. Kijk voor meer details over schaalniveaus en de toegestane rekenkundige bewerkingen op Wikipedia.
Terug naar ons voorbeeld van het begin: niemand kan precies zeggen met welke factor de oude en de nieuwe kant verschillen. Alleen met een echte snelheidsmeting is zo'n uitspraak mogelijk.
Tijdmetingen leveren de beste laadtijdgegevens op
De meest waardevolle gegevens voor vergelijkingen, het opstellen van optimalisatiemaatregelen enz. zijn in elk geval tijdmetingen. Want die hebben een nulpunt waarop men zich kan oriënteren. Hulpmiddelen die de laadtijd meten maken dus allerlei verklaringen en vergelijkingen mogelijk.
Dus als je vóór een optimalisatiemaatregel een laadtijd van de pagina meet van 2,712 seconden en na de conversie een waarde van 2,133 seconden, dan kun je op basis van deze gegevens de volgende uitspraken doen:
- De site is na de conversie 21 procent sneller dan voor de conversie
- Het geoptimaliseerde aspect is verantwoordelijk voor meer dan een vijfde van de paginaprestaties. (een van de belangrijkste stukjes informatie ooit!)
- Alle verdere optimalisatiemaatregelen kunnen in relatie tot deze waarde worden ingesteld. Zo kan een optimalisatie die 9 procent meer snelheid zou opleveren, maar onevenredig veel meer inspanning zou betekenen, een andere prioriteit krijgen dan een maatregel die navenant meer laadtijd bespaart.
Als de klant uit het voorbeeldgeval vanaf het begin had gemeten met een tool als webpagetest.org, dan had hij gezien dat de prestaties van zijn site op de relevante gebieden meer dan verdubbeld waren.
Conclusie: Kennis over soort en kwaliteit van meetgegevens is slechts het begin
Voor een zinvolle vergelijking van twee of meer websites moet dus ten minste aan de volgende twee voorwaarden worden voldaan:
- De gebruikte tool moet de juiste dingen meten - de relevante onderdelen van de website. Wanneer je bijvoorbeeld van hoster verandert, moet je niet uitsluitend vertrouwen op een test die voornamelijk kijkt naar onpage factoren.
- De gebruikte gegevens moeten een zinvolle vergelijking mogelijk maken. Normaal gesproken zou je willen weten met welke factor een optimalisatie de eigen website vooruit heeft geholpen. Alleen met deze informatie kun je bijvoorbeeld een voorspelling doen over de verbetering van het conversiepercentage.
Toegegeven: De juiste gegevens kennen is nog maar het begin. Natuurlijk moet je ook weten hoe je de paginaprestaties op de juiste manier test en hoe je de gegevenssets uitleest. Daarom behandelen we deze twee onderwerpen in detail in andere blogposts.
Inzicht in de gegevens en de toelaatbare conclusies die daaruit kunnen worden getrokken, vormen echter de basis voor alle verdere optimalisatiestappen. En het helpt om de juiste en meest verstandige optimalisatiemaatregelen te nemen.
"*" geeft verplichte velden aan
