Gisteren heeft Google een nieuwe asynchrone tracking code (natuurlijk in bèta) voor Google Analytics aangekondigd. Ik zal proberen uit te leggen waarom dit een interessante ontwikkeling is.

Allereerst een korte uitleg wat er allemaal qua communicatie tussen de browser en het datacenter van de betreffende website plaatsvindt, op het moment dat er een pagina wordt opgevraagd. Ik gebruik hierbij een aantal plaatjes uit de presentatie van Sean Power en Alistair Croll waarover ik al eerder schreef.

communicatie tussen browser en server

Nadat er eerst met elkaar is afgesproken (veilig) met elkaar te praten, vraagt de browser bijvoorbeeld de homepagina op, waarop de server deze verstuurt. Hierbij worden ook alle objecten die op deze pagina worden genoemd, één voor één verstuurd. En zoals het plaatje al aangeeft, kan hierbij een soort file ontstaan. In hun aankondiging vergelijkt Google het met een snelweg: Hoe meer auto’s op dezelfde rijbaan rijden, des te langzamer het verkeer gaat. En file op internet zorgt voor langzamere pagina laadtijden en dat wil je niet.

De Google Analytics tracker code wordt opgevraagd bij Google, net zoals eventuele mashup informatie bij derden wordt opgevraagd.

Meerdere verbindingen vanuit de browser

Het opvragen van de Google tracker vond tot nu toe synchroon (één voor één) plaats met de overige content, waardoor het tonen van de pagina content weleens langer kon duren.

Geen file door extra rijbaan

Met deze nieuwe asynchrone tracker van Google Analytics wordt het javascript door een aparte ‘http thread’ afgehandeld, of zoals Google het zelf noemt, het gebruikt een andere rijbaan op de snelweg, waardoor het laden (van de gehele pagina) veel sneller gaat:

“Think of the asynchronous tracking code snippet as a script that uses a “separate lane” to handle part of the processing of your webpage. As the number of cars (or in this case, scripts on your webpage) increases, the asynchronous tracker uses this lane to reduce webpage load time. Websites that use many scripts or rely on rich media content will especially benefit from this new method, but even lightweight sites will see improvements”

Zoals ik al in mijn eerste posting schreef: Conversie optimalisatie begint met performance optimalisatie. Snellere paginas verkopen meer.

Positieve bijwerkingen

Naast dat deze nieuwe tracker dus mee helpt om pagina’s sneller te laten laden, zijn er nog twee zeer interessante ‘bijwerkingen’:

  • Nauwkeurigere metingen
  • Vermindering van meetfouten die ontstaan omdat de javascript code niet volledig geladen is.

Wie heeft er nu inzicht in de meetfouten van zijn/haar site? En wie zou deze nieuwe bèta tracker code willen testen en met ons de verschillen in metingen willen delen? 

Sla op bij favorieten of deel dit artikel:
  • del.icio.us
  • Facebook
  • Google
  • NuJIJ
  • StumbleUpon
  • E-mail this story to a friend!
  • LinkedIn