Matomo 4.0 Performance analyse van je WordPress website makkelijk gemaakt

Performance analyse: Waar zit de bottleneck?

Wanneer je WordPress website te wensen over laat, is het vaak lastig te analyseren, waar nu precies het probleem zit. Natuurlijk kan je met een tool als YSlow of PageSpeed pagina voor pagina testen, maar wie doet dat met een website van 100 of meer pagina’s?

Ik gebruik al jaren Matomo als ’tweede analytics tool’. Hoewel voor mij Google Analytics onmisbaar is, ontbreekt hier toch het één en ander aan voor mij onmisbare data. Zo biedt Google Analytics mij te weinig informatie over de performance van mijn website.

Natuurlijk, via de Google Search Console kan ik deze informatie wel krijgen, maar deze informatie is allesbehalve actueel. Hier krijg ik namelijk gerapporteerd welke pagina’s te traag zijn nadat de Google bots de site hebben bezocht. Dat kan soms weken te laat zijn. Ik wil immers niet, dat mijn bezoeker de site als ’traag’ ervaart. Op het moment dat Google mij dit rapporteert, kan ik ervan uitgaan dat mijn site al langere tijd te traag is.

Tot en met Matomo 3.x had dit programma een prachtige indicatieve performance analyse. Er werd namelijk gemeten hoe snel de server in staat was de webpagina’s aan te maken en door te geven aan jouw browser.

Wat komt er allemaal bij de snelheid van mijn webpage kijken?

Indicatief prachtig, maar praktisch heb je er toch iets minder aan. Het goede van een dergelijke rapportage, is dat ik zie wanneer mijn site trager wordt. Voor het bewaken is een dergelijke performance analyse dus geweldig, maar om performance problemen op te kunnen lossen heb je toch meer informatie nodig.

Google stelt dat een responsetijd van 0-2 seconden goed is, tussen de 2-4 seconden acceptabel en meer dan 4 seconden echt te traag. Wanneer ik zie dat mijn gemiddelde generatietijd, ofwel de tijd die nodig is om de pagina aan te maken 0,3 seconden is, zegt dat nog helemaal niets over de snelheid waarmee jij de pagina krijgt te zien.

Kortom, ik heb geen flauw idee hoe snel mijn pagina’s op jouw computer getoond zullen worden.

Een aantal factoren speelt hier namelijk een rol. En op sommige van deze factoren heb ik totaal geen eigen invloed.

Vanaf Matomo 4.0 wordt echter niet meer de gemiddelde generatietijd maar de daadwerkelijke tijd van het opvragen van de pagina tot en met het daadwerkelijk zichtbaar zijn van het geheel bijgehouden. En dat geeft ons behoorlijk wat nuttige handvatten voor een goede performance analyse.

De verschillende ‘snelheidscomponenten’.

Hierboven zie je een overzicht van mogelijke statistieken voor een specifieke URL of een complete website. Omdat ik zelf Matomo 4.0 nog maar enkele dagen in gebruik heb, heb ik ervoor gekozen om een afbeelding uit de documentatie van Matomo zelf te nemen. Deze afbeelding is gebaseerd op een beta versie van de software en de omschrijvingen die je op deze afbeelding ziet staan zullen enigszins verschillen met de uiteindelijke labels.

In dit artikel gebruik ik de uiteindelijke labels.

Network time

De ‘Network time’ is de tijd tussen het moment dat jij de vraag stelt en ook daadwerkelijk contact is gelegd met de server waaraan je deze vraag stelt. Deze tijd wordt onder meer bepaald door hoe snel gegevens gevonden kunnen worden in de DNS.

Op het moment dat jij voor de eerste keer op zoek gaat naar wordxpression.nl dan heeft jouw browser geen flauw idee waar deze site gevonden kan worden. Wat er eerst zal moeten gebeuren is deze domeinnaam om te zetten in een IP adres. En om dat te doen, moet contact gezocht worden met een DNS waar dit adres bekend is. Nu gaat het in het kader van dit artikel iets te ver om uit te leggen hoe DNS werkt, maar in het kort komt het er op neer, dat jij aan jouw Internet provider vraagt, wat het adres van wordxpression.nl is. Op het moment, dat hij dit antwoord niet direct kan geven, vraagt hij het aan een andere partij… en dat net zo lang, tot het adres is gevonden.

Nu is het natuurlijk altijd mogelijk, dat ik het IP adres waaronder ik bereikbaar ben wil veranderen. Omdat deze veranderingen gelaagd worden doorgegeven, kan dit een behoorlijke tijd duren. Daarom heeft ieder gegeven in een DNS een zogenaamde ‘TTL’ ofwel, een ‘Time To Live’. Dat is een tijd in seconden.

Geef ik bijvoorbeeld aan de combinatie van mijn domeinnaam en mijn IP een TTL van 3600 (dat is 3600 seconden, ofwel 60 minuten, ofwel een uur), dan vertel ik ieder DNS wat mijn adres opvraagt: ‘als het meer dan een uur geleden is, dat je het hebt opgevraagd, probeer het opnieuw’.

Hoewel het opvragen van een domeinnaam doorgaans in milleseconden wordt gemeten, kan dit bij een ‘langere keten’ toch al snel wat langer worden. Het verhogen van je TTL brengt echter als risico mee, dat indien je in een noodgeval je site moet verhuizen, het wat langer duurt voor je weer online bent.

Je kan de ‘network time’ dus wel verkorten, maar het komt tegen een zekere prijs. Blijkt in een performance analyse jouw ‘Network time’ ongebruikelijk hoog (0,1 seconde is echt een maximum!), dan kan het goed zijn om de TTL voor jouw domein te verhogen.

Server Time

De ‘Server Time’ is de tijd dat de server bezig is om de informatie samen te stellen. In het verleden zijn er meer dan voldoende blogposts op deze site verschenen die je vertellen, hoe je de server performance kan verbeteren. Eén van de belangrijkste factoren is een goede caching plugin.

Transfer time

De ‘Transfer time’ is de tijd die het kost om de bestanden voor de webpagina te versturen naar de browser van je bezoeker. De invloed die je hier uit kan oefenen is eigenlijk best heel groot. En vooral, omdat in veel gevallen de transfer time de bottleneck is, is het goed om dit serieus te nemen.

Minify it!

Eén van de eerste dingen die je kan doen om de overdracht van bestanden te versnellen is alle ‘onzin’ eruit te halen. Nu moet je die onzin niet te letterlijk nemen. Maar de bestanden voor een webpagina bevatten vaak allerlei informatie die wel van belang is voor degene die de bestanden moet onderhouden, maar niet bevorderend zijn voor de snelheid.

Een ‘standaard’ HTML, CSS of JavaScript bestand bevat onder andere de volgende zaken, om het begrijpelijk te houden voor mensen :

• Witruimte. Het is nu eenmaal makkelijker de inhoud van een bestand te begrijpen, als het keurig is voorzien van nieuwe regels, die liefst inspringen waar nodig. Jij -en ik- als mensen hechten hier veel waarde aan, maar jouw browser heeft dit echt niet nodig.
• Commentaar. Wat is de bedoeling van een specifiek onderdeel van de code? Om dit duidelijk te maken, voegt een ontwerper / programmeur commentaar toe aan de bovengenoemde bestanden. Maar jouw browser heeft dit echt niet nodig
• Menselijk leesbare functienamen. Het maakt voor een browser niet uit of een functie ‘dataOphalenVanServer’ heet of ‘f0a541’. Voor jouzelf is de eerste versie waarschijnlijk makkelijker te onthouden.

Je kan HTML, CSS en JavaScript bestanden vaak een stuk kleiner maken, door alle bovenstaande ‘overbodigheden’ te elimineren. Door de code ‘kleiner’ te maken, ’to minify the code’ in het Engels.

En de meeste caching plugins hebben een ingebouwde mogelijkheid om dit te doen.

Compress it!

Iets anders wat je kan doen is de verschillende bestanden comprimeren. Je verstuurt de bestanden gewoon als ‘zip’ bestand… of iets meer specifiek, als gzip (omdat dit een vrije standaard is) bestand. Jouw eerder al ‘ge-minified’ bestand wordt ook nog eens gecomprimeerd verzonden.

Afbeeldingen geoptimaliseerd en van de juiste grootte

Een grote bottleneck voor het netwerk verkeer zijn vaak de afbeeldingen. Enige tijd geleden heb ik een uitgebreid artikel geschreven over hoe groot je afbeeldingen moeten/mogen zijn. Het kan goed zijn dit nog eens na te lezen.

DOM processing time

Een ander heel belangrijk onderdeel van je performance analyse is de zogenaamde ‘DOM processing time’. DOM staat voor ‘Document Object Model’. Het is de manier waarop de HTML van jouw webpagina wordt omgezet in een pagina met allerlei ‘objecten’ als kopteksten, paragrafen, video’s en meer.

In het kort, het is de manier waarop uit de bestanden die jij ontvangt een voor jou begrijpelijke pagina wordt opgebouwd.

De ‘DOM Processing time’ is de tijd die nodig is om een ‘werkbare pagina’ te krijgen. De pagina hoeft nog niet helemaal geladen te zijn, maar jij moet in ieder geval al interactie kunnen hebben met het deel van de pagina wat je op dat moment bekijkt.

De invloed die jij hierop kan hebben is beperkt. Wanneer ik 30 tabbladen open heb in mijn browser, dan mag ik verwachten, dat mijn computer hier wat trager van wordt. Wanneer ik Premiere Pro en After Effects naast elkaar heb geopend en daarna een webpagina laadt, dan mag ik ook verwachten, dat mijn pagina niet al te snel zal zijn. Ik heb namelijk een groot deel van mijn computer in gebruik voor andere taken.

Toch kan jij er wel voor zorgen, dat deze ‘DOM Processing time’ verkort wordt.

Eén van de dingen die je kan doen, is een aantal scripts niet te laden vanuit de WordPress header, maar vanuit de footer. Dit moet dan wel scripts betreffen die je niet direct nodig hebt om de pagina op te bouwen en het vereist aardig wat kennis om dit goed te doen. Ben je niet bekend met HTML, CSS en JavaScript kan het beter zijn contact te zoeken met iemand met voldoende kennis op dit gebied.

Een andere manier om je ‘DOM Processing time’ in te korten is het nalaten om tijdrovende externe diensten te laden. Zo’n ‘Facebook smoelenboek’ widget mag er cool uitzien, maar het vertraagd gemiddeld het laden van je webpagina met 2-5 seconden, afhankelijk van hoeveel ‘koppen’ je maximaal in wilt laden.

DOM completion time

De DOM completion time is de tijd die nodig is om het complete DOM in te laden. Dus eigenlijk, (bijna) de gehele pagina te laden. Het enige wat hierna nog moet worden geladen zijn de zogenaamde ‘on load’ scripts.

Om de DOM completion time te verbeteren geldt in grote lijnen hetzelfde als in de DOM processing time.

On load time

Je kan jouw webpagina de instructies geven bepaalde JavaScripts pas te starten wanneer de hele pagina geladen is. Deze scripts worden dan gestart in het zogenaamde ‘onLoad’ event, wat wordt ‘afgevuurd’ wanneer de pagina is geladen.

Meestal doe je dat, omdat het script de reeds geladen pagina moet manipuleren. Een aardig voorbeeld vind je op de site van een klant van mij. Op de site van vindiqmobility is een prijscalculator waarmee je kan berekenen hoeveel leasevergoeding je voor een auto zou moeten betalen.

De bedragen in deze calculator zijn afhankelijk van een gekozen auto, een gekozen lease termijn en een gekozen ‘eerste termijn’. Aan het einde van het laden van de complete pagina wordt pas het script voor de prijscalculator geladen.

De tijd onder de ‘onLoad’ valt meestal weinig aan te verbeteren.

Een duidelijke verbetering van de performance analyse

Het zal je duidelijk zijn, dat met zoveel verschillende parameters betrekking hebbend op de performance van je website de performance analyse een stuk eenvoudiger is geworden. Ten eerste heb je niet langer een ‘indicatief getal’, maar een duidelijke serie waarden voor je performance analyse waarmee je concreet aan de slag kan gaan.

Maar je hebt nog meer. Want naast die performance analyse heb je ook nog eens een overzicht van alle opgevraagde webpagina’s met een specifieke performance analyse voor die pagina. Wanner je dus de pagina’s sorteert van ‘langzaam’ naar ‘snel’, dan zie je direct de pagina’s die een bottleneck vormen in de performance.

Wanneer een pagina traag is, ga er niet vanuit, dat je direct met die pagina aan de slag moet gaan. Kijk tijdens je performance analyse eerst eens op hoeveel ‘hits’ het gemiddelde betrekking heeft. Is jouw pagina over die periode bijvoorbeeld maar eenmaal opgevraagd, is het heel goed mogelijk dat het of een tijdelijke hickup was of dat bij een gecachede pagina op dat moment toevallig even geen gecachede versie van de pagina aanwezig was. Steek hier dus geen tijd in tenzij uit een historisch overzicht blijkt dat de pagina structureel traag is.

Maar heeft jouw pagina een representatief aantal hits, dan is het goed om toch eens dieper te kijken, waar het probleem ligt.

En -aangezien deze statistieken per pagina door de tijd heen worden bijgehouden- is het ook goed om eens te kijken, of het probleem structureel is, of alleen op dit moment.

Een goede performance analyse zal je snel duidelijk maken waar je eventueel aan verbetering zal moeten werken.

Het daadwerkelijk verbeteren van je overall performance

Heb je performance problemen met je website, dan is het goed om stap voor stap aan het werk te gaan.

Eén van de allerbelangrijkste eerste stappen is natuurlijk een goede hoster. Een website bij een slechte of middelmatige hoster is even zinvol als een auto met vier lekke banden. Je kan er een zwaardere motor inzetten, maar je bereikt meer met het vervangen van de banden.

Na de hoster is het zaak om te zorgen voor goede caching.

Enkele belangrijke kanttekeningen

Persoonlijk vind ik dat Matomo 4.0 met betrekking tot de performance analyse een duidelijke verbetering is ten opzichte van eerdere versies. Ik ben er dan ook heel blij mee. Het enige wat ik wel jammer vind, is dat de ‘oude’ performance metrics niet meer beschikbaar zijn. Vanaf een upgrade van 3.x naar 4.x kan ik dus geen gebruik meer maken van de oude ‘Gemiddelde generatietijd’. Mijn historische performance gegevens zijn daarmee dus redelijk nutteloos geworden.

Maar ondanks dat, is dat mij de overstap naar 4.0 zeker waard.

Het enige wat ik wel jammer vond, was dat het eigenlijk heel onduidelijk was hoe ik deze nieuwe performance analyse op kon nemen in het dashboard. Mocht je Matomo gebruiken en wil je direct op het dashboard toegang tot deze gegeven, je vindt ze onder ‘Gedrag (Behavior indien je de site in het Engels gebruikt) en daaronder ‘Evolution of Page Performance Metrics’ (op dit moment nog niet vertaald naar het Nederlands).

Mocht je behoefte hebben aan enige hulp bij de interpretatie van de gegevens en enkele handvatten hoe je naar aanleiding hiervan de performance van je site kan verbeteren, kan je altijd een video consult met mij inplannen.

Nog geen Matomo?

Wanneer je jouw website, webshop of online leeromgeving door WordXPression laat bouwen krijg je geheel gratis toegang tot de Matomo Statistics server van WordXPression. Heb je al een website, dan is de op één na beste optie het installeren van de Matomo plugin.