Bounce rates en laadsnelheid

Laten we allereerst duidelijk hebben waarom een snelle website zo belangrijk is. Omdat we in een mobile-first wereld leven, is een snelle gebruikerservaring op mobiel essentieel. De hoeveelheid tijd die mensen op hun mobiele apparaten doorbrengen, neemt jaar op jaar toe. Maar de aandachtsspanne neemt af. Je wil dus niet dat die mensen je website wegklikken omdat deze te langzaam of incorrect laadt. Wegklikkers kunnen immers geen zaken met je doen. Een trage site, en daarmee een slechte PageSpeed score, is funest voor je bounce rate. Google zelf raadt aan om de algemene laadsnelheid van je pagina onder de 2 seconden te houden. Dat er veel meer is dan alleen laadsnelheid behandelen we in dit blog. Een kijkje onder de motorkap van PageSpeed.

Death by a thousand cuts

Omdat de PageSpeed is opgebouwd uit allemaal verschillende elementen, zijn er een aantal remedies die je kan toepassen om je website uit dat slakkengangetje te helpen. Je kan bovendien op een hoop vlakken de mist in gaan. Gevolg hiervan is dat je aan een hoop zaken moet denken om een goed geoptimaliseerde website te hebben, en houden.

Dat een goede PageSpeed score belangrijk is, is duidelijk. Maar hoe haal je een goede PageSpeed score? Wat komt er allemaal kijken bij het verbeteren hiervan, en wat zijn de hoofd- en bijzaken?

Geef niet meer weer dan nodig

Waarschijnlijk het meest bekende issue wanneer je denkt aan een trage site. Afbeeldingen en video’s inladen met onnodig hoge kwaliteit. Zorg er dus voor dat de getoonde afbeeldingen en video’s niet groter zijn dan nodig. Zorg er ook voor dat ze de juiste bestandsindeling hebben en dat ze zijn gecomprimeerd voor het web. 

Gebruik CSS-sprites om een sjabloon te maken voor afbeeldingen die je vaak op de site gebruikt, zoals knoppen en pictogrammen. CSS-sprites combineren afbeeldingen tot één grote afbeelding die in één keer wordt geladen (wat minder HTTP-verzoeken betekent) en geeft vervolgens alleen de secties weer die je wilt weergeven. Dit bespaart laadtijd omdat de gebruiker niet hoeft te wachten op meerdere afbeeldingen.

Support your local met een Content Delivery Network (CDN)

Duidelijk dus dat een oorzaak van een trage website kan komen door ongecomprimeerde media. Zowel afbeeldingen als video’s kunnen enorm toevoegen aan de laadsnelheid van een pagina. Er zijn dan in principe 2 dingen die je kan doen. De weer te geven media comprimeren (van 5 mb naar bv 100kb) zoals hierboven beschreven, of de media (bron) naar de gebruiker toe verplaatsen. Dat laatste kan met een zogeheten CDN.

Een Content Delivery Network slaat als het ware de website op lokale servers op dicht bij de gebruiker, waardoor de verbinding letterlijk een stuk korter wordt. Dit opslaan, en daarmee een kopie van de website paraat hebben, heet caching. Een CDN heeft als absolute voordeel dat je website overal ter wereld min of meer even snel laadt. Een bekend probleem dat iemand in Indonesië gerust een kop koffie kan halen tijdens het laden van een Nederlandse website is hiermee verholpen. De PageSpeed score is daarmee overal ter wereld ontzettend hoog. Goed voor je Google ranking, en dus goed voor je business.

Een CDN distribueert belangrijke inhoud naar meerdere, wereldwijd geplaatste datacenters, zodat deze dichter bij de eindgebruiker is en de inhoud dus sneller weer te geven is. Het netwerk gebruikt server optimalisaties op basis van inhoudstype om die inhoud zo efficiënt mogelijk bij de gebruiker te krijgen. Lees hier meer over het gebruik van een CDN

Vermijd redirects

Elke keer dat een pagina doorverwijst naar een andere pagina, wacht de gebruiker langer totdat de pagina klaar is met laden. Al deze extra bounces kosten namelijk tijd. Kostbare tijd, weten we inmiddels. Als het mobiele redirect pad er bijvoorbeeld als volgt uitziet:

voorbeeld.com -> www.voorbeeld.com -> m.voorbeeld.com -> m.voorbeeld.com/home

Komt het er dus op neer dat de site effectief pas na 4 redirects verschijnt. Onnodige vertraging die je moet zien te voorkomen.

Gebruik browser caching

Browser caching werkt door de eerder geladen bronnen te laten “onthouden”, zodat ze niet bij elk bezoek opnieuw laden. Wanneer een websitebezoeker naar een nieuwe pagina op uw site gaat, hoeft niet alle content, zoals logo’s en voetteksten, opnieuw te worden geladen. Dit resulteert in een grote snelheidstoename wanneer mensen op een website terechtkomen.

PageSpeed ontleed

En dan PageSpeed zelf. De metrics die Google zelf gebruikt komen in principe neer op wat hierboven behandeld is, maar dan in iets andere bewoording. Google hanteert zelf namelijk 6 behoorlijk technische termen die bij elkaar een PageSpeed score vormen. Maar wat meet PageSpeed eigenlijk precies?

• Largest Contentful Paint (LCP) – In essentie is het de snelheid waarmee de belangrijkste content op de site laadt. Een paar hoofdredenen die een slechte LCP score overleggen zijn langzame server response tijden en trage bron laadtijden. Meer hier.
• First Contentful Paint (FCP) – In tegenstelling tot de LCP gaat het bij de FCP logischerwijs om de tijd die verloopt voordat de eerste contant wordt weergegeven. Het markeert het eerste punt waar de gebruiker iets op het scherm kan zien – een snelle FCP helpt de gebruiker gerust te stellen dat er iets gebeurt. Meer hier.
• Interaction to Next Paint (INP) – Bij INP gaat het om de reactiesnelheid van alle elementen op input van de gebruiker. Een praktisch voorbeeld hieronder waarin niet alleen de snelheid van een element weer wordt gegeven, maar ook de manier van reageren op input. Meer hier.

• First Input Delay (FID) – Waar het bij FCP en LCP om weergavesnelheid gaat, gaat het bij FID om de responsiveness van de website. En dan met name de snelheid van de respons op de eerste interactie van de gebruiker met de site. Meer hier.
• Cumulative Layout Shift (CLS) – CLS behelst het veranderen van de indeling van elementen op een pagina. Onverwachte verplaatsing van pagina-inhoud gebeurt meestal omdat bronnen niet synchroon worden geladen of DOM-elementen dynamisch worden toegevoegd aan de pagina boven bestaande inhoud. De boosdoener kan een afbeelding of video zijn met onbekende afmetingen, een lettertype dat groter of kleiner wordt weergegeven dan oorspronkelijk de bedoeling, of een advertentie of widget van derden dat zichzelf dynamisch aanpast. Meer hier.

• Time to First Byte (TTFB) – TTFB is een metric die de tijd meet tussen het verzoek om een bron en het moment waarop de eerste byte van een antwoord begint te arriveren. Een aantal oorzaken van een slechte TTFB kunnen bijvoorbeeld gezocht worden bij hosting services met inadequate infrastructuur en daardoor geen hoge volumes verkeer aan kunnen. Het verbeteren van TTFB wordt vaak gedaan door een geschikte hostingprovider te kiezen met een infrastructuur die een hoge uptime en responsiviteit garandeert. Dit kan – in combinatie met een CDN – helpen. Meer hier.

Snel, maar toch een matige PageSpeed score

Al de bovengenoemde metrics bij elkaar vormen dus de PageSpeed score van een website. En ondanks dat de naam doet vermoeden dat het allemaal om snelheid gaat, hoeft een tegenvallende score niet per se te betekenen dat je website ook daadwerkelijk traag is. Een supersnel ladende website kan nog steeds een minder goede score overleggen vanwege slecht geladen elementen of elementen die verspringen en niet dynamisch genoeg zijn.

Vergeet ook zeker niet dat de PageSpeed test beschikbaar is voor zowel dekstop als mobiel. Een website kan bijvoorbeeld sublieme scores halen op desktop, maar slechts matig presteren op mobiel.

De gebruiker tevreden houden

Een goede PageSpeed score is dus belangrijk, omdat dat betekent dat je website op meerdere fronten goed presteert. Dat de content snel wordt getoond, maar ook dat de content correct en logisch wordt weergegeven. Opdat de gebruiker een tevreden bezoeker is. En een tevreden bezoeker is immers een converterende bezoeker.

Op https://pagespeed.web.dev/ kunnen bedrijven zelf checken hoe hun site presteert. De test geeft ook meteen weer op welke vlakken er verbetering nodig is. Dit gebeurt op een erg gedetailleerd niveau, waardoor je direct precies weet waar het mis gaat. Of juist goed natuurlijk. Mocht het zo zijn dat deze inzichten je te technisch worden, dan kan je altijd bij de website-bouwer aankloppen om opheldering te vragen.