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
Een verzoek van een pagina gaat door allerlei systemen heen: DNS servers, eventueel ook load balancers, misschien een firewall, een WAF, PHP servers (in ons geval) en misschien nog wel meer. Al die systemen samen zorgen dat je browser met een bepaalde snelheid de HTML response van een pagina verzoek ontvangt. Ik noem dit voor het gemak ‘backend performance’.
- Nadat de browser HTML ontvangt
De browser heeft de eerste HTML bytes ontvangen en kan zijn ding gaan doen. Content tonen, styling toepassen, resources inladen, JavaScript uitvoeren en nog veel meer. Ik noem dit voor het gemak ‘frontend performance’.
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.
Dit gaat allemaal over hoe een pagina zich gedraagt nadat je de HTML al hebt ontvangen. Google maakt deze metrics zelfs dusdanig belangrijk door er een nieuwe naam aan te geven: Core Web Vitals.
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.
Google zegt dat deze kenmerken de komende jaren heel belangrijk gaan worden en hun tools ook naar de Core Web Vitals zullen verwijzen. Volgens Google kunnen de kenmerken in de toekomst veranderen. Misschien vallen sommige kenmerken zelfs weg of komen er nieuwe bij.
Mijn marketing collega’s schreven eerder al een uitgebreide blog over de Core Web vitals, inclusief praktische tips om je website te verbeteren.
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.
Je kunt performance nog steeds meten met PageSpeed, maar dit geeft exact hetzelfde resultaat als de performance score in Lighthouse. PageSpeed draait namelijk op de achtergrond een Lighthouse test.
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.
We doen nog een test met precies dezelfde pagina, maar schakelen alle JavaScript op de pagina uit. Via Network request blocking in de Developer Tools van Chrome kun je alle verzoeken voor JavaScript bestanden automatisch laten blokkeren. Als ik nu weer drie Lighthouse tests uitvoer, kom ik op een gemiddelde performance score van 92 van de 100.
Belangrijk: het enige verschil tussen de tests is de aanwezigheid van alle scripts op de pagina. Alle andere factoren, zoals latency, snelheid van servers, netwerk, CSS rendering en fonts laden, zijn gelijk gebleven. Door alléén JavaScript uit te schakelen, is de performance score van de FIFA website gestegen van 30 naar 92. Meer dan 3 keer zoveel!
Ik heb hiermee wel de FIFA website kapot gemaakt. Zoals je op de screenshots kunt zien, heb ik bijvoorbeeld de slider in de header kapot gemaakt. Dat roept de volgende vragen op:
Welke van de geblokkeerde scripts waren écht noodzakelijk? Hoeveel functionaliteiten kunnen niet anders worden gerealiseerd dan met scripts? Hoeveel code van de scripts wordt daadwerkelijk gebruikt? Kan je bijvoorbeeld uit de voeten met minder scripts? Waarom staan er überhaupt zoveel scripts op de FIFA website?! Dat zit zo…
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.
Niet alleen een limiet aan het aantal scripts ontbreekt. Ook op het aantal KB’s of zelfs MB’s die je toevoegt zit geen limiet, net als dat er geen limiet is op het inladen van extra externe resources. Scripts kunnen zelf ook scripts laden, die kunnen weer scripts laden, die vervolgens weer scripts laden… enzovoorts. En niet alleen scripts: ook CSS of afbeeldingen. De browser weet van tevoren niets over deze tweede- of derdehands resources en kan er ook niet voor optimaliseren.
Met het toevoegen van een enkele GTM <script> tag wordt de deur geopend naar een oneindige stroom externe bronnen. De developers van de website zijn hier niet van op de hoogte, terwijl vaak naar developers wordt gekeken om performance problemen op te lossen.
Bovendien mist er controle. Iedereen, die kan inloggen in Tag Manager, kan binnen enkele minuten nieuwe scripts toevoegen. Security en performance worden hierin vaak niet meegenomen. Terwijl een script super zwaar of zelfs kwaadaardig kan zijn, al dan niet per ongeluk. Het beïnvloedt je website op manieren die je liever niet hebt. Dat is overigens niet altijd even duidelijk. Aan alleen de regels van aan elkaar gebreide JavaScript code zie je niet wat het precies doet.
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:
In mijn ervaring komt dit vrijwel altijd voort uit ‘iets in Tag Manager’ en dat heeft een negatief effect op je performance score en je positionering in de zoekresultaten van Google.
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.
De performance in 4 stappen verbeteren
Een performance issue oplossen, is in essentie makkelijk. Met deze vier stappen kom je al een heel eind.
#1 Check of het script daadwerkelijk nodig is
Zo niet: verwijder het. De snelste en beste manier om een langzame pagina te verbeteren, is door onnodige scripts weg te halen. Ben hier heel kritisch op. Misschien zijn er ook dingen die gemeten kunnen worden aan de server-kant van de website.
#2 Script wel of niet inladen via Tag Manager
Als het script noodzakelijk is, is het echt noodzakelijk om het via Tag Manager in te laden? Zo niet, zet het script in de HTML onderaan de pagina. Het insluiten van de directe script tag heeft veel performance voordelen ten opzichte van Tag Manager.
#3 Op welke pagina’s komt het script
Moet het script terugkomen op iedere pagina? Of gaat het om specifieke pagina’s op je website? Voeg het script dan alleen toe op de pagina’s waar je het nodig hebt. Hiermee ontlast je alle gebruikers die het niet nodig hebben.
#4 Wel of niet per direct inladen
Tot slot moet je jezelf afvragen of het nodig is dat het script blokkerend wordt ingeladen. Als dat niet nodig is, gebruik je ‘async’ attributen op de script tag, waardoor de pagina niet blokkeert tijdens het laden van het script. Of zorg je dat het pas enkele seconden na het laden van de pagina geladen wordt via een eigen (veel kleiner) stukje JavaScript.
Wees kritisch en bedenk wat écht noodzakelijk is
Tag Manager was een heel goed idee, in 2012. Uiteraard kan het ook vandaag de dag nog goed gebruikt worden, maar helaas wordt het ook erg veel misbruikt. Dit gebeurt vaak onbewust: Tag Manager maakt het te makkelijk om ongecontroleerd een pagina te overladen met scripts. De ongelimiteerde vrijheid om allerlei externe scripts toe te voegen, was achteraf gezien misschien toch niet zo’n goed idee.
Wees kritisch en bedenk wat écht noodzakelijk is. Moeten echt 6 externe marketing of social partijen jouw verkeer meten? Doet dat nog steeds meer goed dan kwaad? Is het het waard om de pagina te vertragen? Zeker als je niet actief aan de slag gaat met de data die je verzamelt.
Kijk of je bruikbare data los kunt zien van nutteloze data. Niet alle data is nodig, en niet alle data is bruikbaar. En zeker niet alle data is wenselijk, ook vanuit security oogpunt. Alles meten is geen goede standaard. Meet en test heel selectief, per domein, per pagina, per tijdsvak. De vuistregel zou moeten zijn: standaard meten we niks. En ga vanuit daar heel bewust om met wat je wél toevoegt en wat je daarmee wil bereiken.
Meer weten?
Wil je meer weten over website performance of wil je eens sparren over de performance van jouw website? Neem contact met me op via [email protected] of 076 530 2525 en ik help je op weg!