
Hoe definieer en meet je performance?
scripts slim gebruiken
Minimale impact op de performance
Eerder schreef ik een blog over scripts in Google Tag Manager en de impact op de website performance. Ik heb uitgelegd hoe een JavaScript-bestand werkt en welke impact dit heeft op de performance van je website. Waar ik het nog niet over heb gehad is hoe deze performance wordt gedefinieerd en gemeten. In dit blog ga ik hier uitgebreid op in. Ook tackel ik een aantal mythes rondom scripts van externe partijen en doorloop ik 4 concrete stappen om de performance te verbeteren. Kortom: ik neem je mee in hoe je scripts kunt gebruiken met een minimale impact op de algehele website performance.
Wat is website performance?
Allereerst is het belangrijk om te bedenken dat er grofweg 2 gebieden van website performance zijn: alles voordat je browser HTML ontvangt van een server en alles wat er gebeurt nadat je browser HTML ontvangt van een server.- Voordat de browser HTML ontvangt
- Nadat de browser HTML ontvangt
Frontend performance
Het is tegenwoordig steeds makkelijker om een backend en server infrastructuur op te zetten, waarmee je out-of-the-box al een prima performance bereikt. Hierin is al veel vooruitgang geboekt. Het ‘probleem’ zit hem dan ook steeds minder in het versnellen van de Time to First Byte (de tijd die het kost om als bezoeker de eerste byte van een HTML pagina te ontvangen). Uiteraard blijft dit zeker belangrijk, maar de complexiteit van performance verschuift de laatste jaren steeds meer naar de frontend. Deze verschuiving zie je ook terug in de manier waarop populaire tools je performance score meten. Waar eerder een grote focus lag op de Time to First Byte, wordt dit nu ingehaald door andere metrics, zoals:- Largest Contentful Paint: de tijd totdat het grootste blok aan content zichtbaar wordt.
- First Input Delay: de tijd totdat een gebruiker echt interactie met de website kan hebben (en niet geblokkeerd wordt door uitvoerende scripts).
- Cumulative Layout Shift: een score die aangeeft hoeveel layout na het initieel laden van de website verschuift, wat irritaties bij gebruikers opwekt.
Core Web Vitals
De Core Web Vitals zijn 3 kenmerken die op dit moment de belangrijkste indicatoren zijn voor de performance van een pagina. Ze zijn bedoeld om duidelijkheid te scheppen over waar perfomance en gebruiksvriendelijkheid nou écht over gaat. Google heeft voor de namen Largest Contentful Paint, First Input Delay en Cumulative Layout Shift gekozen, zodat ook niet-developers begrijpen waar het over gaat. Dat is niet voor niets: gebruiksvriendelijkheid wordt een steeds belangrijkere ranking factor om (hoog) te scoren in de zoekresultaten van de zoekmachine.
Hoe meet je performance?
De bekendste methode om je website performance te meten is altijd Google PageSpeed geweest. Gooi in deze tool de url van de pagina die je wilt meten en je krijgt de performance score te zien op een schaal van 100 punten. Vroeger was deze score meer gericht op server performance. Hoe snel ontvangt de gebruiker data? Tegenwoordig heeft Google dit onderdeel gemaakt van een nieuwe tool: Lighthouse. Ook de Lighthouse test kun je eenvoudig online uitvoeren. De verandering naar Lighthouse heeft een paar belangrijke gevolgen:- de performance focus is verschoven van backend naar frontend performance;
- de tips en uitleg in de tools zijn veel uitgebreider en beter;
- en de performance score is niet langer het enige cijfer dat de pagina krijgt. De pagina krijgt ook een score voor hoe goed de SEO, toegankelijkheid en best practices geïmplementeerd zijn. Ook wordt een Progressive Web App (PWA) score gegeven, hoewel dit niet voor elke website van toepassing is.
Hogere ranking door Lighthouse
Lighthouse is momenteel de meest toegankelijke, handigste en belangrijkste tool. Google gebruikt deze tool om je website te positioneren in de zoekresultaten. Een goede Lighthouse score betekent dus een grotere kans om hoog in de zoekresultaten te komen. Dit alles maakt Lighthouse vandaag de dag de beste, belangrijkste en meest complete en uniforme manier om website performance te meten.Scripts hebben impact op Lighthouse score
Welke impact hebben scripts op de Lighthouse score? Met een simpel voorbeeld kan ik laten zien dat vooral JavaScript een enorme impact heeft op de performance score. Kijk maar eens naar de resultaten van FIFA.com. We draaien Lighthouse en kijken alleen naar het performance gedeelte. Na het draaien van drie tests kom ik op een gemiddelde performance score van 30 uit 100. Dit is, zonder een oordeel over de developers te geven, vrij laag te noemen.

Wel of geen JavaScript gebruiken?
Het internet heeft nogal een haat-liefdeverhouding met JavaScript. Developers hebben verschillende voorkeuren en benaderingen van hoe een website het beste kan worden gebouwd. Verschillende belangen worden afgewogen om te bepalen of voor een functionaliteit wel of geen (stukje) JavaScript gebruikt wordt. Soms heb je geen keuze en ben je gebonden aan een technische keuze van een klant: ‘Ik wil een webapplicatie gemaakt in Vue.js’. In dat geval sta je qua performance al 1-0 achter en moet je waarschijnlijk andere, belangrijkere afwegingen maken. Toch is het ook prima mogelijk om een website te bouwen zónder ook maar een letter JavaScript. JavaScript is géén verplichting. Het is zelfs veel effectiever om het aantal KB’s JavaScript tot een minimum te beperken. Net zoals het in het algemeen sowieso beter is om het aantal KB’s van de hele voorkant van je website zoveel mogelijk te beperken. Gebruikers profiteren hiervan in de vorm van snelheid. En dus profiteer je hier als bedrijf van, omdat je website gebruiksvriendelijker is.Waarom zoveel scripts?
Als JavaScript niet verplicht is, waarom zijn er dan zoveel scripts? Scripts kunnen grofweg worden opgedeeld in functionele scripts en ‘andere soorten scripts’. Functionele scripts heb je zeer waarschijnlijk nodig. Ze zorgen dat je website goed werkt. Bijvoorbeeld de hoofdnavigatie op de mobiele layout die opent en sluit door een menuknop. Dit werkt met JavaScript. Natuurlijk zijn er manieren om een website te bouwen zonder scripts, zoals een website die niet al te complex is qua interactie, maar in de praktijk is een minimale hoeveelheid interactie en daarmee scripts vaak wel nodig.Marketing scripts
Alle andere niet-functionele scripts kunnen over van alles gaan, maar de grootste categorie is marketing. Marketeers willen gedrag meten en de website optimaliseren op basis van data. Gedrag kun je tegenwoordig meten in kliks, scrolls, navigatie en zelfs muisbewegingen en volledige schermopnames zijn mogelijk. Sta je een script van een externe partij toe op je website, dan kan bijna alles door die partij worden gemeten én aangepast. Op basis van de bedrijfsnaam die op jouw IP-adres in een database geregistreerd staat, kan andere website content worden getoond en middels een A/B-test kun je meten welk design meer conversies oplevert. Kortom: marketing scripts worden aan website toegevoegd om uiteindelijk meer geld te verdienen. Dat is natuurlijk super aantrekkelijk, dus heb je er best wat voor over. En natuurlijk heeft Google iets super handigs bedacht…Google Tag Manager
Google Tag Manager bestaat uit een container script dat alle andere marketing scripts inlaadt. Je krijgt een soort open invulveld waar je zelf scripts kunt toevoegen van een oneindig aantal partijen. Zoveel je wilt… zónder je website aan te moeten passen! Een heel aantrekkelijk en inmiddels zeer succesvol systeem. Toch is er vanuit verschillende hoeken inmiddels steeds meer kritiek en ook Google’s eigen Lighthouse ontdekt steeds meer en vaker problemen die voortkomen uit Tag Manager.Geen limiet en geen controle
Het probleem is dat een aantal dingen ontbreken, in het bijzonder:- geen limiet;
- en geen controle.
Negatieve invloed op je website
Gebrek aan controle en geen script limiet hebben een negatieve invloed op je website. De laadtijd wordt langer, er komen security errors naar voren, de performance score gaat omlaag, de website wordt lager beoordeeld door Google en gebruikers zijn sneller gefrustreerd en gaan in het ergste gevoel op zoek naar alternatieven. De slechtere gebruikerservaring zorgt op deze manier voor minder conversies. Inmiddels vindt Google zelf ook dat dit niet de beste manier is. In Lighthouse, de tool die ze nota bene zelf hebben gebouwd, komen steeds vaker fouten naar voren die te maken hebben met Tag Manager of de scripts die in Tag Manager zitten. In Lighthouse wordt bijvoorbeeld het volgende aangegeven:- op deze pagina wordt te veel JavaScript code uitgevoerd, verminder dit;
- op deze pagina wordt te veel JavaScript werk op de main thread uitgevoerd, verminder dit;
- op deze pagina staat te veel ongebruikte JavaScript, verwijder dit;
- op deze pagina staan teveel derde-partij scripts, verminder dit;
- of ergens in de JavaScript wordt het verouderde document.write() gebruikt, verwijder dit.
Script gebruik verbeteren
We zullen bepaalde ingeslepen denkwijzen echt moeten loslaten. Ook de denkwijzen die misschien ooit kloppend waren, maar dat tegenwoordig niet meer zijn. Er zijn nog steeds bepaalde mythes over scripts, met name als die worden aangeleverd door externe partijen of tools.Mythes tackelen
Een externe partij wil graag de eerste en belangrijkste tool op jouw website zijn. Dat heeft gevolgen voor hun eisen voor het plaatsen van hun script en dat is niet altijd terecht. Kijk bijvoorbeeld eens naar de volgende argumenten.- “Mijn script is noodzakelijk voor de website.” Is dat echt zo? Bedenk dat de gebruiker naar een website komt voor de content en dat doet de gebruiker niet “koste wat kost”. Als de gebruiker de content met minder moeite bij een andere website kan halen, dan doet hij dat. Je script is een risico, dus is het écht noodzakelijk?
- “Mijn script moet via Tag Manager geladen worden.” Klopt dat wel? De meest controleerbare manier is om het script in de code van de website te plaatsen. De developers weten er dan van en kunnen de positie in de code controleren. Tag Manager is mooi, maar zou eigenlijk de laatste optie moeten zijn.
- “Mijn script moet als eerste geladen worden.” Nee, dat moet niet. Er zijn misschien wel tientallen externe partijen op één website. De volgorde van die scripts doet niet ter zake. Als je een script goed schrijft, werkt het altijd, ongeacht de volgorde op een pagina.
- “Mijn script werkt alleen als het bovenaan de pagina geladen wordt.” Dat klopt niet. JavaScript kent geen beperkingen die bovenaan of onderaan een pagina gelden. Het werkt overal even goed. Vaak werkt het zelfs beter om het onderaan te zetten, omdat de content van de pagina dan voorrang krijgt. Als een script echt niet functioneert onderaan een pagina, ligt dat aan de manier waarop het script is geschreven.
- “Als mijn script niet z.s.m. laadt dan loop ik data mis.” Er is een minuscule kans dat dit gebeurt. Bovendien is de vraag welke data je dan zou missen. Het verschil tussen laden bovenaan of onderaan de pagina is vaak enkele tienden van een seconde. In een tijdsbestek van 100 milliseconden doet een gebruiker niets wat van waarde is. Of het is een robot, die je sowieso niet wil meten. Dit is een verwaarloosbaar tijdsbestek en dus in 99% van de gevallen geen geldige reden om iets met voorrang te laden.