Een developer schrijft code achter een laptop op kantoor bij Netvlies.

Welke impact hebben marketing scripts op website performance?

Het doel van de meeste websites is het genereren van conversies, zoals het verkopen van een product of verzamelen van waardevolle leads. Om zoveel mogelijk rendement uit een website te halen, is het gebruikelijk om data te verzamelen over het gebruik van de website en op basis van deze data de gebruikerservaring te verbeteren. Hier zijn enorm veel tools voor, zoals Google Analytics, Hotjar, Adform, SalesFeed, Criteo, Visual Website Optimizer en Datatrics. 

Deze tools werken via JavaScript op je website. Je voegt een stukje code of extern script van de dienst toe aan je website en de rest valt te regelen in de tools zelf. Het is vaak plug-and-play: het toevoegen van een script is het makkelijkste gedeelte van het proces. Toch is het belangrijk om hier goed over na te denken: de manier waarop je de scripts plaatst en inlaadt, heeft impact op de laadsnelheid van je website. In een tweedelige blogserie leg ik uit hoe dit zit. 

Twee developers bij Netvlies aan het werk.

Google Tag Manager

Tot 2012 was voor het plaatsen van ieder script een developer nodig. Deze extra stap in het proces kostte meer tijd. Om de workflow te versnellen heeft Google op 1 oktober 2012 Tag Manager geïntroduceerd. Voortaan heb je nog maar één script nodig van Google Tag Manager (GTM), die alle andere scripts inlaadt. Een soort trechter voor alle scripts dus. Een marketeer kan dit vervolgens makkelijk zelf beheren door in GTM naar wens script tags toe te voegen. 

Super handig! Maar… niet zonder risico. Het technologie landschap is inmiddels weer veranderd en er zijn steeds meer redenen om deze aanpak in twijfel te trekken. Zoals een groeiend aantal nadelen omtrent performance, privacy en gebruiksvriendelijkheid. Want wat doet een script eigenlijk, zodra je het op een pagina plaatst?

Hoe werkt een script?

Een script wordt meestal geplaatst door gebruik te maken van de externe bron van de betreffende tool, zoals: 

<script src="https://service.company.com/script.js" async></script>

In het bestand script.js kan vervolgens alles gebeuren wat het externe bedrijf wil, bijvoorbeeld:

  • data verzamelen over gebruik van de website;
  • aanpassingen maken in de website (zoals voor een A/B-test);
  • extra functionaliteit toevoegen aan de website;
  • of content tonen/verbergen op basis van het gedrag van de gebruiker.

Het bedrijf kan eigenlijk alles doen wat je maar technisch mogelijk is. Dit heeft wél technische gevolgen voor de website, voornamelijk op deze 3 manieren:

  1. het script moet geladen worden
  2. het script moet geïnterpreteerd worden
  3. het script moet uitgevoerd worden

Het heeft dus impact op de performance (de laadtijd) van de pagina. Dit is voor alle type resources het geval, ook voor CSS en afbeeldingen (IMG), maar JavaScript (JS) heeft veruit de meeste impact. Veel meer dan bijvoorbeeld een afbeelding van dezelfde grootte in KB’s.

Visuele weergave laden, nadenken en uitvoeren van scripts.

Script laden

Een script laden is geen rocket science. Je kan dit makkelijk asynchroon laten verlopen, zodat andere resources ondertussen ook geladen kunnen worden (zie het async woord op de voorbeeld script-tag hierboven). Je moet hierbij wel zicht hebben op de hoeveelheid scripts over heel de website en hoe groot die zijn. Het is zonde om veel extra MB’s aan data in te laden, als dit niet nodig is. Bovendien is de laadsnelheid altijd afhankelijk van het netwerk van de gebruiker, zoals 3G, 4G, wifi of internet via de kabel. De kwaliteit van dit netwerk kan wisselen. 

Script interpreteren

Het script interpreteren is een browser taak die vaak onderschat wordt. De browser denkt dan na over de betekenis van het script. Dit proces is sterk afhankelijk van het type apparaat en is een van de zwaarste stappen die JS doorloopt in je browser. In dit artikel wordt uitgelegd wat dat interpreteren precies inhoudt, en wat het kost (korte antwoord: tijd). Het komt op twee dingen neer: 

  1. Parsing: de betekenis van de aangeleverde code achterhalen. Je kan dit vergelijken met het proces in je eigen hersenen dat een stuk tekst ontleedt en dit vervolgens begrijpt. 
  2. Compiling: de code omzetten in een andere vorm van code die daadwerkelijk uitgevoerd kan worden door een browser.

Je kan dit vergelijken met het proces in je hoofd wat een doel (zoals: iets zeggen tegen aan een ander) omzet in voor de ander begrijpelijke taal. Het uitvoeren (uitspreken) staat hier nog los van.

Het parsen en compilen van JavaScript kost CPU-kracht, en dus tijd. Het kost tijd en energie voor de processor in het apparaat dat je gebruikt om dit uit te voeren. En die CPU-kracht is soms voldoende aanwezig, vooral op de betere apparaten, maar lang niet altijd. Goedkope telefoons (die ook in Nederland populair zijn) hebben een veel minder sterke CPU dan een iPhone of een goede laptop. In onderstaande afbeelding vind je een vergelijking van een aantal populaire apparaten en hun processorkracht bij 1 MB-bundel JavaScript.

Tabel weergave populaire apparaten en hun processorkracht.

Script uitvoeren

Ook het uitvoeren, het executen, kost rekenkracht en dus tijd. Dit houdt in dat de code is begrepen en vertaald en de browser de opdracht nu kan uitvoeren. In tegenstelling tot het laden van een script, is het parsen, compilen en executen van JS wel allemaal blocking. Dit betekent dat de browser de pagina tijdelijk niet kan updaten, omdat het met iets anders bezig is. Voor alle processen op een pagina, ook die te maken hebben met CSS, heeft de browser maar één stel “hersenen”. Er is één main thread dat maar één ding tegelijk kan doen. Bijvoorbeeld: als je browser een while-loop uitvoert in JS, kan de gebruiker niet tegelijkertijd een button aanklikken. Er is ruimte voor letterlijk 1 taak tegelijk.

Tijdlijn weergave van het laden tot excute van een marketing script.

Daarom is het zo nadelig en kostbaar om veel tijd kwijt te zijn aan parse, compile en execute time. De gebruiker ervaart dit als traag: de pagina staat stil, reageert niet en er gebeurt niets. Als dit enkele tientallen milliseconden duurt, is het geen probleem. Maar als dit door meerdere scripts op elkaar te stapelen in de buurt komt van bijvoorbeeld 200 of 300 milliseconden, is het al merkbaar. Voeg je nog meer scripts toe en komt de laadtijd in de buurt van 500 a 600 milliseconden, dan wordt dit echt storend en kan het het gebruiksgemak aantasten, frustratie oproepen en bezoekers wegjagen. Onverantwoord omgaan met scripts kan uiteindelijk misschien wel een omgekeerd effect hebben: door de lange laadtijd jaag je bezoekers weg en nemen de conversies af in plaats van toe!

JavaScript is per KB duurder dan CSS en afbeeldingen

Doordat deze stappen zoveel CPU-kracht kosten, staat de impact van een X aantal bytes van een afbeelding laden niet gelijk aan het laden van een X aantal bytes aan JavaScript. JS komt met extra performance kosten en is “duurder”. Dit is vooral te wijten aan het feit dat performance meer inhoudt dan enkel laadtijd. Het gaat ook om hoe snel een pagina visueel klaar staat, hoe weinig content visueel verschuift, en hoe snel alle interactieve elementen bruikbaar zijn.


Vergelijk een afbeelding van 170kb met een precies even groot JavaScript bestand van 170kb. Deze resources gaan beide door de interpretatiefase en ook beide door de uitvoerfase. Maar in deze vergelijking duurt het wel 31x langer om de JS te interpreteren dan de afbeelding. Het uitvoeren van de JS is wel 53x trager dan het uitvoeren van de afbeelding!

Belangrijke conclusie: het aantal kilobytes van een resource zegt niets over hoeveel impact het heeft op de performance van een pagina.

Tegenwoordig is dit dan ook de meest genoemde reden dat Google een website als “langzaam’ beoordeelt. Ondanks dat een pagina snel gedownload kan zijn, gebeurt er daarna nog zoveel op de pagina dat de bezoeker alsnog moet wachten.

In mijn volgende blog ga ik dieper in op de moderne definitie van performance. Wat is performance volgens Google Precies? En hoe meet je de performance?