Geschreven op 6 mei 2024, laatst gewijzigd op 13 mei 2024.

Waarom de snelheid van jouw website verbeteren?

Je bent aan het surfen op internet, op zoek naar informatie, winkelt voor producten, of misschien ben je gewoon op zoek om bij te blijven met het laatste nieuws. Je klikt op een link en hoopt vol verwachting wat erachter ligt. Maar in plaats van begroet te worden met onmiddellijke voldoening, word je begroet met een laadspinner die eindeloos lijkt te draaien. Of misschien nog erger, wanneer je probeert een link op de pagina aan te klikken maar je mist de knop omdat er eindelijk een afbeelding is geladen, niet zomaar een afbeelding, maar een advertentie. Die je nu naar een compleet andere website brengt dan je van plan was te bezoeken. Het is frustrerend, nietwaar?

Als gebruikers hebben we allemaal de ongeduldigheid of de frustratie ervaren die gepaard gaat met langzaam ladende websites. En in een wereld waarin de tijd van een gebruiker meer waard is dan ooit tevoren, kan de prestatiesnelheid van een website het verschil maken voor de gebruikerservaring. Hoelang zou jij op een website blijven die, wat aanvoelt als, eeuwig duurt om te laden of om iets te doen? Als het geen noodzaak is, zal je antwoord vrij kort zijn, toch? Verwacht dus niet hetzelfde van je gebruikers.

In de afgelopen jaren heb ik de mogelijkheid gehad om de prestaties van websites voor honderden bedrijven te verbeteren door een nieuw en snel Content Management Systeem te ontwikkelen, de basis van deze websites. Ik heb dit kunnen doen door naar de problemen vanuit allerlei invalshoeken te bekijken en tal van verbeteringen te vinden. Deze variëren van het veranderen van hoe bronnen worden geladen door de browser aan de voorkant tot het onderzoeken van de databasequeries die aan de achterkant worden gemaakt. Nu wil ik de voordelen delen van het investeren van al deze inspanning, evenals hoe je hetzelfde kunt doen.

Laten we eerst bespreken waarom een verbeterde prestatiesnelheid kan leiden tot een langere retentiegraad. Als een webpagina te lang duurt om te laden, zullen bezoekers vertrekken voordat je je zaak hebt kunnen uiteenzetten, of beter gezegd, een gebruiker zal langer blijven op snellere websites. En hoe langer ze blijven, hoe waarschijnlijker het is dat ze acties ondernemen op de website, wat betekent dat de conversieratio toeneemt. Wat op zijn beurt betekent dat bezoekers de acties zullen ondernemen die je zou willen, waardoor deze bezoekers leads worden voor je bedrijf en potentieel betalende klanten. Maar niet alleen dat, een beter presterende website zal ook de gebruikerstevredenheid verhogen, wat betekent dat er tevreden klanten zijn van je diensten en producten.

Bovendien zullen beter presterende websites ook de toegankelijkheid verbeteren voor bezoekers met bepaalde beperkingen. Zij die bijvoorbeeld op een langzamer mobiel netwerk zitten in een afgelegen gebied waar internettoegang trager is, kunnen nu gebruik maken van jullie website. Hiermee samenhangend is hoe zoekmachines websites belonen met een hogere paginarangschikking wanneer zij een betere prestatiesnelheid hebben. Dit alles betekent dat het jullie in staat stelt om een groter publiek te bereiken.

Hoe wordt slechte prestatie ervaren?

Naast mijn eerdere voorbeelden van een slechte gebruikerservaring door langzaam ladende pagina's, is het goed om te weten welke waarde wordt toegevoegd gedurende het laadproces. Als we dit weten, kunnen we kijken naar onze ervaringen met onze systemen en bepalen waar we ons eerst op moeten richten. De toegevoegde waarde tijdens het laden kan worden onderverdeeld in verschillende vragen die de gebruiker zichzelf zal stellen.

• Werkt het? - Op dit moment vraagt de gebruiker zich af of hun initiatief voor de interactie is geregistreerd en is op zoek naar feedback. Bijvoorbeeld, de spinner bovenaan de browser geeft aan dat de navigatie succesvol is geweest en wacht op gegevens die moeten worden teruggegeven, maar hopelijk is de website zelf al begonnen met laden.
• Is het nuttig? - De eerste zinvolle inhoud is verschenen voor de gebruiker, bijvoorbeeld de tekst van het artikel dat ze willen lezen. En nu willen ze weten of de inhoud relevant voor hen is, als dat niet het geval is, klikken ze misschien al weg.
• Is het bruikbaar? - Terwijl de gegevens worden geladen, is de pagina misschien nog niet interactief; dit kan zijn omdat er nog wat gedrag moet worden geladen, en voordat die knop kan worden ingedrukt, reageert het nog niet op interactie.
• Is het aangenaam? - Nu alles is geladen, is de gebruiker begonnen met de pagina te gebruiken. Tijdens hun bezoek willen ze ook dat de ervaring aangenaam is, niet alleen bij de eerste keer laden. Bijvoorbeeld, wanneer de gebruiker scrolt of op een knop drukt, voelt het dan traag aan om te reageren op hun interacties?

Ik hoop dat je begrijpt dat elk van deze vragen voortkomt uit verschillende gebeurtenissen, niet slechts één ding genaamd laden. Dit betekent op zijn beurt dat prestaties op veel verschillende manieren kunnen worden verbeterd omdat je verschillende problemen aanpakt.

Denk aan twee websites die in dezelfde tijd laden. Maar de ene toont pas al zijn inhoud tegelijk wanneer alles is gedownload en verwerkt, en de andere toont elk item zodra het beschikbaar is. De laatste kan een betere gebruikerservaring bieden omdat de gebruiker de vragen die ik hierboven heb voorgesteld tijdens het laden kan beantwoorden, niet helemaal aan het einde. Hoewel de totale laadtijd technisch gezien hetzelfde was, kan de manier waarop inhoud wordt geleverd een grote impact hebben op het gevoel van een pagina omdat de waarden op een eerder tijdstip kunnen worden beoordeeld.

Maar voordat we overgaan op concrete stappen, moeten we eerst een ander probleem overwinnen. Hoe weet je of je het beter doet als je niet weet hoe goed je het eerder deed en nu doet. Door het te meten natuurlijk, en om dit te doen, denk ik dat het goed zou zijn om te beginnen met de Core Web Vitals van Google.

Wat zijn de Core Web Vitals?

De Core Web Vitals omvatten verschillende metingen waarvoor we ons kunnen afvragen "met hoeveel?" of "hoe lang duurde dat?". Dit zal je een idee kunnen geven van waar je kunt verbeteren en wanneer je probeert te verbeteren hoe goed je werk doet. De eenvoudigste manier voor iedereen om inzicht hierin te krijgen, is door gebruik te maken van Google's PageSpeed Insight. Probeer het eens en voer een website in, mag ik deze aanbevelen?

Bovenaan zie je mogelijk een sectie over de ervaringen van gebruikers in de echte wereld, dit hangt af van de hoeveelheid verkeer die een website ontvangt. Deze sectie bevat informatie over de volgende metingen: Time to First Byte, First Contentful Paint, Largest Contentful Paint, Cumulative Layout Shift, First Input Delay, Interaction to Next Paint. In de volgende sectie zie je enkele cijfers in cirkels, hopelijk zo dicht mogelijk bij 100, maar voor nu maken we ons daar niet al te veel zorgen over. Meer Core Web Vitals zijn te vinden iets verder naar beneden. Deze hebben de volgende labels: Speed Index, First Contentful Paint, Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time. Samen vormen deze metingen het eerste deel van het rapport, verrassend genoeg genaamd Prestaties.

Laten we kort bespreken wat elke metriek betekent voor de ervaring van de eindgebruikers. Later zullen we dieper ingaan op elke metriek om te begrijpen wat er precies wordt gemeten, waarom het belangrijk is om te meten en welke verbeteringen kunnen worden aangebracht aan een website om beter te scoren op elke metriek.

• Time to First Byte - Hoe lang het apparaat van de gebruiker moet wachten voordat het de eerste informatie terugkrijgt van de server van de website wanneer het gegevens ervan opvraagt.
• Speed Index - Hoe lang het duurt voordat inhoud begint te verschijnen op het scherm bij het bezoeken van een webpagina.
• First Contentful Paint - Hoe lang de gebruiker moet wachten om de eerste stukjes inhoud, zoals tekst of afbeeldingen, te zien wanneer zij een webpagina bezoeken.
• Largest Contentful Paint - Hoe lang de gebruiker moet wachten om het grootste stuk inhoud op het scherm te zien verschijnen, zoals de kopafbeelding of de tekst van een artikel, wanneer zij een webpagina bezoeken.
• Cumulative Layout Shift - Hoeveel elementen op de webpagina onverwacht bewegen wanneer de pagina wordt geladen. Bijvoorbeeld, als tijdens het laden van een pagina de tekst is verschenen, maar dan plotseling de afbeelding erboven wordt geladen. Als er geen ruimte was gereserveerd voor die afbeelding om in te verschijnen, verschuift de tekst en ontstaat er een lay-outverschuiving.
• Total Blocking Time - Hoe lang de gebruiker moet wachten voordat de website reageert op de interactie van de gebruiker wanneer de webpagina wordt geladen. Bijvoorbeeld wanneer je op de knop drukt om het menu van de website te openen, moet er eerst wat code worden geladen voordat de webpagina kan reageren op je interactie met het juiste antwoord.
• First Input Delay - Hoe lang de webpagina nodig heeft om te reageren op de invoer van de gebruiker nadat deze de initiële inhoud van de webpagina volledig heeft geladen. Terugkomend op het vorige voorbeeld is dit niet de tijd die het kost voordat de webpagina begint te luisteren naar de ingedrukte knop, maar hoe lang het duurt voordat de website verwerkt dat je op de knop hebt gedrukt en het menu wilt openen.
• Interaction to Next Paint - Hoe lang het duurt voordat de gebruiker de verandering op de webpagina zien nadat zij ermee interactie mee gehad hebben. Als je bijvoorbeeld weer op de menubutton drukt, is dit nu de tijd die het kost voordat het menu verschijnt nadat je op de knop hebt gedrukt. Een ander voorbeeld is bij het scrollen. Laat het scherm onmiddellijk de nieuwe inhoud zien, of is er een vertraging tussen het scrollen en het tonen van het gescrolde deel van de webpagina. Deze metriek meet die vertraging evenals die van andere interacties.

Zijn deze metingen genoeg?

Nee, maar ze kunnen een goed startpunt bieden. Denk na over hoe en waar verschillende applicaties hun waarde bieden. Neem bijvoorbeeld een website voor het delen van afbeeldingen. Het is leuk en aardig dat ik kan interageren met de website, maar zolang er geen afbeeldingen zijn geladen, wordt er geen waarde geleverd. Daarom is het hebben van een korte tijd tot interactiviteit niet zo belangrijk als het laden van de afbeeldingen boven de vouw. Richt je eerst op het verbeteren van deze kern metingen, die een combinatie van verschillende metingen kan zijn. Laten we zeggen dat de website voor het delen van afbeeldingen gebruikers toestaat om deze afbeeldingen in een persoonlijke collectie op te slaan. Nu is interactiviteit ook een belangrijk onderdeel van de applicatie, dus de tijd tot interactiviteit is een goede metriek om te meten en misschien te verbeteren.

De kernboodschap zou moeten zijn dat nadat je enkele basismetingen hebt gedaan, je een metriek kiest die overeenkomt met de gebruikerservaring en daar naartoe werkt. Dit kunnen er meerdere zijn, zolang het er niet te veel tegelijk zijn. Ja, beter presteren in alles zou geweldig zijn, maar je hebt slechts beperkte tijd om eraan te besteden, dus zorg ervoor dat dit budget goed wordt besteed.

Een van de manieren waarop nieuwe metingen kunnen worden gemaakt, is door gebruik te maken van nieuwe API's die in verschillende stadia van beschikbaarheid zijn.

• User Timing API - Biedt toegang tot hoge precisie tijdstempels voor prestatie metingen van applicaties.
• Long Tasks API - Maakt het mogelijk om langlopende taken te detecteren die de gebruikersinterface-thread gedurende langere tijd gebruiken, evenals andere taken blokkeren en verhinderen dat deze kunnen worden uitgevoerd en reageren op gebruikersinvoer.
• Element Timing API - Stelt ontwikkelaars in staat om te monitoren wanneer gespecificeerde afbeeldingen of tekst elementen aan de gebruiker worden getoond.
• Navigation Timing API - Biedt toegang tot timinginformatie met betrekking tot documentnavigatie.
• Resource Timing API - Biedt toegang tot timinginformatie met betrekking tot bronnen in een document.
• Server timing - Specificeert een methode voor een server om prestatie-metingen naar de browser te communiceren.

In de toekomst zullen waarschijnlijk meer Core Web Vitals worden toegevoegd en misschien worden sommige van de bestaande metingen weggehaald. Voor nu zijn dit degenen die gemakkelijk kunnen worden gemeten. Hoe gemakkelijk? Nou, zoals eerder getoond, kan het zo eenvoudig zijn als het bezoeken van een link, maar er is iets meer aan de hand.

Hoe meet ik deze vitale parameters?

Allereerst, denk na over wat je wilt meten. De Kern Web Vitals, toch? Nou, er is meer dan dat. Je kunt specifieker zijn dan dat, en het is waarschijnlijk het beste om meer specifiek te beginnen en, naarmate je verbetert, het bereik te verbreden. Jouw gebruikers hebben te maken met veel verschillende omgevingen in de echte wereld. Sommigen bezoeken misschien de website op hun telefoon die verbonden is met internet via mobiele data, terwijl anderen een desktopcomputer gebruiken met een bekabelde internetverbinding. Dit betekent ook dat er veel variabelen zijn waarvoor je zou moeten - en tot op zekere hoogte kunt - controleren.

We kunnen deze metingen dus in twee omstandigheden meten: in een gecontroleerde omgeving en natuurlijk het tegenovergestelde - een ongecontroleerde omgeving. In een gecontroleerde omgeving kun je, voordat je een applicatie of functie uitbrengt, ervoor zorgen dat deze presteert zoals verwacht en regressie voorkomen. In een ongecontroleerde omgeving zou je, na de release, bijhouden hoe de werkelijke ervaring is voor de eindgebruikers. De resultaten van echte gebruikersmonitoring kunnen natuurlijk sterk verschillen tussen gebruikers vanwege de verschillende omstandigheden die eerder zijn genoemd. Maar desondanks kunnen de veldresultaten waardevol inzicht geven in wat jouw gebruikers tegenkomen, wat labtests niet kunnen laten zien. Maar voor nu zullen we kijken naar het doen van laboratoriummetingen omdat deze gemakkelijker te produceren en te reproduceren zijn zonder een grote bestaande gebruikersbasis te hebben.

Begin met jezelf af te vragen in welke omgeving je gaat meten. Dit moet dicht bij zijn wat jouw werkelijke gebruikers gebruiken; bijvoorbeeld het apparaat. Als de meeste gebruikers via hun telefoon de website bezoeken, begin dan daarmee. Houd ook rekening met de vraag of de server draait op jouw lokale machine of dat het een testomgeving is op een externe server? Het eerste zal beter laten zien welke impact jouw wijzigingen hebben, maar kan misleidend zijn omdat het niet dezelfde latentie bevat voor elk verzoek als gebruikers zullen ervaren in de echte wereld. Hoewel deze latentie vaak kan worden gesimuleerd door de netwerkverbinding opzettelijk te vertragen via throttling.

Als je metingen wilt vergelijken, meet dan altijd meer dan eens, en probeer slechts één ding te veranderen en zie hoeveel impact dit heeft. Dit betekent dus niet overschakelen naar een volledig ander apparaat bij het uitvoeren van deze metingen, overschakelen van Wi-Fi naar mobiele data, of meerdere bewerkingen uitvoeren in de codebase, enzovoort.

Als kleine bijzaak, houd rekening met caching. Ik bedoel hier niet caching op het testapparaat, hoewel dit niet vergeten moet worden om tussen metingen door te wissen. Jouw server moet bijvoorbeeld gegevens creëren bij eerste gebruik, bijvoorbeeld bij het dynamisch genereren van een bijgesneden afbeelding. De eerste keer dat de afbeelding wordt opgevraagd, bestaat deze nog niet, dus duurt het langer. Daarna zal het volgende verzoek aanzienlijk sneller zijn als de afbeelding op de server is opgeslagen. Dit is vaak te zien bij het uitvoeren van een meting meerdere keren voordat er bewerkingen worden uitgevoerd om het te verbeteren. Is de waarde consistent, of is er veel variabiliteit? Als de eerste de langzaamste is, kan dit wijzen op caching. Als allemaal veel variabiliteit vertonen, vraag je dan af hoe goed enige conclusies kunnen zijn die je trekt uit deze tests.

Na al dat gedoe kunnen we eindelijk praten over de tools die je kunt gebruiken. De eerste en eenvoudigste die we al zijn tegengekomen, is PageSpeed Insight, een website die wordt aangeboden door Google. De manier waarop het werkt, is dat je het de URL van de website geeft en het zal wat tests en metingen voor je uitvoeren. Helaas meet het veel tegelijk, wat vertraagt hoe snel je wijzigingen kunt doorvoeren, het cached zijn eigen resultaten, en de webpagina moet al openbaar beschikbaar zijn. Dus uiteindelijk alleen echt nuttig om aan klanten te laten zien en om te valideren wat jij of anderen beweren over hun werk.

PageSpeed Insight maakt gebruik van Lighthouse, het tweede hulpmiddel dat je kunt gebruiken. Dit draait lokaal op je computer en is toegankelijk vanuit de ontwikkelaarstools in verschillende browsers op basis van Chromium, waarvan de meest voorkomende natuurlijk Google Chrome is. Omdat het gebruikmaakt van de hardware en netwerkverbinding van je apparaat, kan het variëren afhankelijk van je locatie en de hardware die je gebruikt. Dit maakt tests die je opneemt niet vergelijkbaar met anderen, maar het is veel sneller dan het gebruik van een externe service. Het stelt je in staat om sneller te itereren en de webpagina niet openbaar beschikbaar te hebben, wat betekent dat het de keuze is bij het lokaal ontwikkelen van de website.

Terwijl we het hebben over de ontwikkelaarstools van Google Chrome, zijn er aanvullende tools die je kunnen helpen meer te leren over wat er binnenin je browser gebeurt. Wat betreft prestaties, zijn dit de tabbladen Netwerk, Prestaties en Geheugen. Deze stellen je in staat inzicht te krijgen in wat de verbinding tussen de server en de browser doet, evenals de processor en het geheugen dat wordt gebruikt.

Sommige van de metingen zoals First Input Delay en Interaction to Next Paint worden niet getest door Lighthouse zelf, omdat deze interacties met de pagina vereisen. Er bestaat wel een Chrome-extensie genaamd Web Vitals die deze, evenals enkele andere metingen, naar de console of een zwevend paneel boven op de website kan loggen.

Wil je weten wat je werkelijke gebruikers ervaren? Dit kan worden gezien bij het gebruik van PageSpeed Insight, maar een betere locatie om dit te zien is de Goole Search Console. Zodra je domeinbezit hebt gevalideerd en voldoende gebruikers de website lang genoeg hebben bezocht, kun je daar ook een overzicht van de werkelijke gebruikerservaring zien.

Tot slot wil ik je aandacht vestigen op Unlighthouse, dat vergelijkbaar is met Lighthouse, maar in plaats van een enkele pagina te meten, kan dit voor elke pagina op de website. Dit maakt het een ideaal hulpmiddel om specifieke pagina's te vinden die mogelijk unieke problemen ervaren en kan helpen bij het valideren dat de verbeteringen over de hele website worden doorgevoerd en niet slechts op één pagina.

Hoe verbeter je de prestaties van een website?

Nu we weten waarom prestaties belangrijk zijn en hoe we ze kunnen meten, komt het neer op het daadwerkelijke werk om ze te verbeteren. Dit is, nou ja, een zeer uitgebreid antwoord dat in veel delen zal komen omdat een enkel artikel niet alle belangrijke informatie kan bevatten.

De belangrijkste reden hiervoor is dat elke site anders is; je kunt problemen ervaren die iemand anders niet zou kunnen hebben. Soms zijn dit eenvoudige oplossingen, terwijl het andere keren een fundamenteel probleem van de architectuur van de website kan zijn dat de prestaties beperkt. Denk aan de verschillende manieren waarop websites kunnen worden gebouwd. Sommige maken gebruik van verschillende architecturen, elk met verschillende sterke en zwakke punten op basis van verschillende behoeften van de gebruikers en het team dat eraan werkt. Een scenario kan zijn twee websites die content tonen in dezelfde tijd, maar waarvan de ene veel trager aanvoelt. Een bron van het probleem kan zijn dat het veel langer duurt voordat de pagina interactief wordt. De pagina kan er zijn in dezelfde tijd als de andere, maar als je er niets mee kunt doen, kan dat frustrerend zijn. De reden hiervoor kan zijn dat er rijkere gebruikersinteracties vereist zijn en er veel meer code moet worden overgedragen en geladen voordat dat kan gebeuren. Dus onthoud, schijn bedriegt, en de oorzaak van deze verschillen kan te wijten zijn aan fundamentele beslissingen en behoeften waarvoor niet elke oplossing van toepassing zou kunnen zijn, of zelfs zou moeten zijn.

Al met al betekent dit dat een eenvoudige one-size-fits-all-oplossing niet mogelijk zal zijn.

Meer lezen

• Hoe laden browsers websites?
• Verbeteren van de core web vitals van het NC-CMS2