Meet de snelheid van je site in Google Analytics

Toegegeven, het is niet een nieuw idee om de snelheid van je pagina's te meten met javascript. Maar dit vervolgens doorgeven aan Google Analytics middels event tracking is dat wel. Nu Site Speed een officiële SEO ranking factor is, is het belangrijk om inzage te hebben in je snelheid.

De Google Webmaster Tools levert al een mooie grafiek over de tijd die Google over het renderen van je site doet. Zie voor meer uitleg mijn blog over het sneller maken van mijn eigen blog. Maar nog meer cijfers van alle laadtijden bij diverse gebruikers is altijd handig.

De laadtijden in cijfers

Op dit moment kan ik per pagina zien wat de totale laadtijd is geweest, maar ook het gemiddelde. Dat rapport ziet er als volgt uit:

Ik heb nog niet heel veel data, ik had geen zin om te wachten met bloggen 😉 Het leuke is dat je nu ook laadtijden kunt gaan bekijken per regio of type verbinding:

Nadeel van dit "custom report" is dat je zelf de kolom met de gemiddelde tijden moet uitrekenen (Excel) omdat hier alleen de totalen getoond worden. Voor DSL zou dat dan 20.126 / 19 = 1059 millisecondes per pagina worden. Op dezelfde manier kun je ook voor browsers of besturingssystemen kijken wat de laadtijden zijn.

Als kers op de taart kun je de laadtijden ook in een grafiek weergeven om zo het resultaat van je werk over verloop van tijd te zien. Kies daarvoor deze optie boven je grafiek in de gebeurtenissen rapportage:

Het script

Het script is eigenlijk heel eenvoudig. Het bestaat uit 2 delen waarvan de eerste helemaal bovenin de pagina vlak na de <head> geplaatst moet worden:

<script type="text/javascript">loadtimer=new Date();</script>

Het 2de gedeelte is iets geavanceerder en ziet er als volgt uit:

<script type="text/javascript">
window.onload = function()
{
_gaq.push(['timer._setAccount', 'UA-XXXXX-2'],['timer._trackPageview'],['timer._trackEvent', 'Tijdmeting', location.href, , parseInt(new Date() - loadtimer)]);
}
</script>

Of in de oudere versie van het meetscript:
<script type="text/javascript">
window.onload = function()
{
var loadTracker = _gat._getTracker("UA-XXXXX-2");
loadTracker._trackPageview();
loadTracker._trackEvent('Tijdmeting', location.href, , parseInt(new Date() - loadtimer));
}
</script>

Let op dat je een nieuw profielnummer gebruikt en niet het UA nummer van je hoofdmeting. Dit script zorgt er namelijk voor dat anders je bouncerate op nagenoeg 0% komt te staan. Daarnaast moet er vanwege een bug eerst een trackPageview gedaan worden omdat andere het meten van het event niet goed gaat. Deze trackPageview wil je ook niet in je hoofdmeting hebben.

Click to activate social bookmarks

 
  • Oblomov

    Wederom een mooie post Andre!
    Wat is de beste plek om het tweede stukje code te plaatsen? Moet dat in de footer, of kan het gewoon in de header aangezien de code pas wordt aangeroepen "onload"?

  • Goed dat je uitlegt hoe je in GA met Event Tracking de werkelijke laadtijden van je bezoekers kunt meten!
    De methode is goed, maar kan beter:

    1) Gebruik niet window.onload, maar een onload handler.
    Het nadeel van window.onload voor dit script is dat het kan conflicteren met andere scripts die ook het onload event gebruiken. De oplossing van Dean Edwards is een goede en veelgebruikte en vind je hier: http://dean.edwards.name/weblog/2005/10/add-event2/

    2) Meet niet alleen de 'tijd tot pagina geladen is' (dit reik jij aan), maar ook de 'tijd dat het browserscherm zeker wit is' (de zgn. Start Render).
    Dit laatste geeft een nog beter inzicht in de user experience. Bezoekers vinden het prettig als de pagina progressief laadt en zo snel mogelijk 'iets' in het scherm verschijnt.
    Hiervoor dien je een tweede timer te maken. De timer moet direct voor de afsluitende </head> tag te staan. Stel dat de Start Render tijd 4 seconden is en je totale paginalaadtijd 4,5 seconden. Dit zegt veel over de user experience en over hoe je pagina laadt.

  • @Oblomov: zoals je zelf al aangeeft maakt het dus niet uit.

    @Aaron: over de onload handler, bekende techniek die ik vaak inzet. Maar voor het overzicht en de simpelheid heb ik voor het artikel gekozen voor deze versie. Een handige webbouwer is slim genoeg om dit unobtrusive te maken.

    Verder eens met je 2de punt. Je zou het ook nog uit kunnen breiden met de DOMContentLoaded/onreadystatechange functionaliteiten. Dan meet je wanneer de pagina opbouw ingeladen en verwerkt is, en niet pas als ook de plaatjes binnen zijn.

    Het mooiste is misschien nog wel om al deze tijden te meten.

  • Ik mis de server side parse time van de pagina in het script. Deze kan je server side meegeven en op deze manier zo ook doormeten via GA.

    Verder erg handig om dit zo via GA te doen!

  • @Sander: mooie aanvulling, naast de tijden die Aaron al noemt zouden we die ook mee kunnen nemen.

  • Jordy Noll

    Nice, mooie tutorial! Deze ga ik binnenkort ff implementeren! 🙂

  • Harvey

    Er zit volgens mij een dubbele komma bij de _trackEvent call tussen 2e en 4e parameter

  • @Harvey: dat is expres. Het optionele label gebruik ik niet dus die kan leeg blijven 😉

  • @Andre: werkt inderdaad bij de nieuwe code, maar bij de oude code misschien iets van "null" als parameter geven, anders krijg je een js-error.

  • Ik ben niet zozeer om de technische kant te belichten/bediscusieren. Dat neem ik direct van jullie aan. Maar praktisch gezien heb ik twee vragen:
    1. Wat voegt het toe ten opzichte van de grafiek die Google's Webmaster hulpprogramma's biedt?
    2. Hoe belangrijk zal de factor snelheid zijn?

    Verder natuurlijk interessant om in Analytics te meten. Dat staat boven kijf.

  • 1. Analytics geeft een beter gevoel bij de echte laadtijd die je bezoekers ervaren. En niet zozeer de laadtijd van een geoptimaliseerde Google computer die je site geautomatiseerd laadt en bekijkt.
    2. Nog niet heel belangrijk, maar omdat het invloed heeft op zowel SEO/SEA als Usability is het zeker goed om hier naar te kijken.

  • @Mark van Loon
    Hoe belangrijk pagina laadtijd (en servertijd) is, kan je pas goed zien in de context van je analytics data. De Google Bot crawl snelheid biedt die context niet. Bovendien is de Googlebot ook geen gebruiker die een bepaalde taak wil doen op je site.

    Ik heb veel met Oracle RUEI en Moniforce webProbe gewerkt. Daarmee is al snel duidelijk wat de 'kritieke' grens is voor paginalaadtijd door laadtijd tegen client-aborts af te zetten.
    Ook kan je achterhalen wat de invloed is van performance op conversie, task completion rate of clickthrough.

  • De nieuwe grafiek in je WMT is juist niet van de Google bot afkomstig maar van verzamelde gebruikers info (toolbar). Bovendien gaf Matt Cutts aan dat A. Speed alleen nog maar voor een beperkte groep websites (.com meen ik) toegepast wordt en B. dat naar verwachting slechts 1 % van de websites een nadelige invloed zal ondervinden.

    Verder natuurlijk weer een geniale methode om de snelheid van je site te meten zoals die door je gebruikers ervaren wordt André.

  • Had hier ook al mee zitten spelen maar kreeg dit niet aan de praat. Dit voorbeeld zit er een stukje gemakkelijker uit dan hetgeen ik gevonden had. Tnx for sharing André!

  • Hoi Andre, goed artikel en mooie methode. Ik maakte al een tijd gebruik van deze http://panalysis.com/tracking-webpage-load-times.php . Ik ga deze vervangen voor die van jou die is een stuk sneller.

  • Ingo

    Goed artikel zal deze methode zeker gaan uit proberen, ervaar dat veel bezoekers snelheid van de website als belangrijk ervaren. Is een indirect gevolg van de algemene snelheid waarin wij tegenwoordig onbewust zijn beland. Is niet meer terug te draaien....

  • Mooi gedaan, alweer een top hack in Analytics.
    Maar hangt de individuele laadtijd van je site ook niet af van de client?
    Heb je veel plugins in je firefox, wat is de snelheid van je connectie, server configuratie etc.

    Of kijk je slechts naar eerste request, en meet je van deze tot de laatste kb geladen is?

  • @Dennis: de laadtijd hangt inderdaad van meerdere zaken af, de snelheid van de pc van de gebruiker bijvoorbeeld. Maar door het gemiddelde van alle gebruikers te nemen krijg je een goede indicatie van de gemiddelde snelheidsbeleving.

  • Jay

    Interesting 🙂 post bookmarked for later use!

    Dank je, Andre. Sitespeed is door veel webmasters onderschat (naar mijn mening). Vooral bij designers, die kiezen vaak voor hoge kwaliteit plaatjes ipv snelheid.

  • Hey André,

    Alles goed? bedankt dat je het script wil delen.

  • Corne

    Hoi André,

    Ziet er goed uit. Begrijp ik goed dat je een tweede profiel moet aanmaken zodat de ua code wordt voorzien van -2? Levert die dubbele code op de website dan geen conflicten op?

  • @Corne: nee hoor dat is geen enkel probleem. Daar kan GA prima mee omgaan 🙂

  • Marco

    Hoi André

    Ik heb onder ons account meerdere profielen. Als het Profiel-id begint met een 2XXXXXXX, is dat dan het profiel wat de meting van UA-XXXXXXX-2 bij gaat houden? Ik krijg nu namelijk geen meting onder dit profiel dus ik ben zoekende wat er mis is...

    Groet,
    Marco Vrouwenvelder

  • He Marco, het profiel ID wordt eigenlijk alleen gebruikt wanneer je met de Google Analytics API aan de slag gaat. Als je in het profieloverzicht kijkt zou je daar de UA-XXXXX-2 nummers moeten zien staan. En alle metingen van het script waar ook UA-XXXXX-2 in staat zouden in die profielen binnen moeten komen.

    Als je er niet uit komt kun je me mailen zodat ik ook een blik kan werpen 😉

  • Interessant artikel! Ik ga me er in verdiepen. Bedankt voor het delen van je kennis!

  • Ga ik is proberen en kijken of het wat uitmaakt

  • Interessant artikel heb het nu ook en werk prima en heel nuttig

  • mleleers

    Erg handig ja, maak er ook gebruik van.