Wij werken aan SEO en dat betekent een goede website hebben. Met tools als Pagespeed Insights en de Core Web Vitals is het mogelijk om te meten of je website ‘goed’ is. Maar hoe reflecteert dat op SEO? En nog belangrijker; wat betekenen deze statistieken en hoe kun jij ze als SEO specialist gebruiken om jouw website te verbeteren.
Google Pagespeed Insights (PSI)
Pagespeed Insights is een tool gemaakt door Google om nuttige statistieken over de (technische) prestaties van webpagina’s te testen, te meten en te rapporteren. Het geeft veel informatie, maar de meest opvallende, en meestal hetgeen om over op te scheppen, is de PSI-score.
Hoewel het niet veel zegt, ziet een “perfecte” score er altijd goed uit en een hoge score (90+) betekent wel dat je iets goed doet. Althans vanuit technisch oogpunt, omdat het niet kan controleren of jouw inhoud zinvol is of op welke manier dan ook leesbaar is.
Dus hoewel een goede score helpt bij SEO, omdat het betekent dat jouw website goede prestaties levert, wat goed is voor bezoekers, is het slechts een zeer klein deel van de uiteindelijke positie die zoekmachines berekenen.
Dat gezegd hebbende; Google zegt al enkele jaren dat prestaties en gebruikerservaring een steeds grotere factor worden in hun positionering, vooral voor mobiel. En daarom is het waarschijnlijk belangrijker om een website te hebben die (ook) performant is op mobiele apparaten.
Core Web Vitals
Sinds een paar jaar legt Google de focus op 3 specifieke statistieken, de Core Web Vitals. Deze statistieken zijn Largest Contentful Paint (LCP), First Input Delay (FID) en Cumulatieve Layout Shift (CLS). En zelfs met deze 3 statistieken in de schijnwerpers, is de rest nog steeds even belangrijk, zo niet belangrijker.
Largest Contentful Paint (LCP)
Het LCP meet hoe lang het duurt voordat het grootste element in de viewport (zichtbaar deel) is geladen. Meestal is dit de hero (met afbeelding of video-achtergrond). Het meet niet de tijd voor dit enkele element, maar de tijd totdat het element volledig is geladen. Dus alle scripts en stijlen in de head tellen ook mee, en natuurlijk afbeeldingen en externe middelen die boven de vouw worden gebruikt. Kortom; het meet de tijd totdat de pagina in het scherm is geladen.
Ondanks dat het lastig is om goed in te zien waar het probleem ligt, hebben wij wel een aantal tips om de LCP in WordPress te verbeteren.
First Input Delay (FID)
FID is een tijd metriek die de tijd meet die nodig is om een gebeurtenis te laten reageren. Het duurt bijvoorbeeld de tijd tussen een gebruiker die op een knop klikt en het moment dat de browser de actie uitvoert die aan de knop is gekoppeld. Normaal gesproken doet een browser dit direct (binnen 10 ms), maar als een browser nog steeds bezig is met dingen op de achtergrond, zoals het laden van bestanden of het uitvoeren van scripts, kan dit veel vertraging veroorzaken.
Cumulatieve Layout Shift (CLS)
CLS is niet iets dat je gemakkelijk kunt meten, en is niet gebaseerd op tijd, maar een score. Het controleert op elementen die bewegen of beweging van elementen veroorzaken. Wanneer er bijvoorbeeld een afbeelding laadt, wat uiteraard enige tijd kan duren, verandert de inhoud eronder van positie op het moment dat de afbeelding wordt geladen. Of wanneer er javascript gebruikt om inhoud te positioneren nadat de pagina is geladen. Deze bewegingen geven een hogere, en dus slechtere, score op de CLS. Deze score wordt berekend door de impact (hoeveel verstoort het de lay-out) en de afstand (hoeveel pixels beweegt het).
Andere statistieken
Naast deze 3, die samen de Core Web Vitals vormen, zijn er verschillende andere metrics die worden gemeten door PageSpeed Insights en die net zo belangrijk zijn om in de gaten te houden bij het optimaliseren van je website of pagina.
First Contentful Paint (FCP)
Meet de tijd tot het eerste stuk inhoud (zoals tekst of afbeelding) op de pagina wordt weergegeven. Dus de eerste keer dat “elke” inhoud zichtbaar is in de browser.
Speed Index
Meet de tijd die nodig is om elementen op de pagina weer te geven. Bijvoorbeeld de tijd die nodig is om een afbeelding op een pagina op te vragen, te downloaden en weer te geven.
Time To Interactive (TTI)
Meet de tijd tot de pagina volledig interactief is. Dit betekent dat de volledige pagina wordt geladen, inclusief afbeeldingen, scripts en stijlen, en dat de bezoeker alles kan zien en doen wat de pagina zou moeten doen (zoals op een knop klikken of door de pagina scrollen).
Total Blocking Time (TBT)
De totale tijd van lange taken. Elke taak (zoals een muisklik) die langer dan 50 ms duurt om te reageren, is een lange taak. De TBT zal de tijd boven de 50ms nemen en alle lange taken bij elkaar optellen. Als een taak bijvoorbeeld 70 ms duurt, wordt de TBT met 20 ms verhoogd.
Field Data vs Lab Data
Op PageSpeed Insights zie je 2 soorten data; Field Data (Ontdek wat jouw echte gebruikers ervaren) en Lab Data (Diagnose van prestatieproblemen). En je merkt misschien dat sommige statistieken in beide voorkomen, maar verschillende waarden hebben.
Field Data nemen de gemiddelden van daadwerkelijke bezoekers op jouw website van de afgelopen 28 dagen, die zijn verzameld door Chrome/Chromium-gebruikers die jouw website hebben bezocht. Deze cijfers veranderen niet direct op het moment dat je wijzigingen aanbrengt op jouw website en zijn mogelijk niet erg nauwkeurig. Wel geeft het een goede indicatie van de gemiddelde gebruikerservaring van bezoekers. Zeker als je kijkt naar de percentages, die aangeven hoeveel bezoekers de afgelopen maand een goede, gemiddelde of slechte ervaring hadden.
De Labgegevens worden op dit moment verzameld en zijn werkelijke cijfers. Hoewel het niet 100% nauwkeurig is, omdat het niet op een echte browser draait en verschillende browsers zich anders kunnen gedragen, is het toch de beste lijst om in de gaten te houden bij het werken aan verbeteringen.
Houd er ook rekening mee dat de tests worden uitgevoerd vanaf een lokale server naar de tester, en niet de locatie van de server. Het is dus mogelijk dat als 2 mensen een test uitvoeren op dezelfde pagina, maar vanaf verschillende locaties, de resultaten anders zijn. En zelfs vanaf dezelfde locatie is het mogelijk dat de score een beetje veranderd, aangezien er veel andere factoren zijn die de snelheid van je website kunnen beïnvloeden.
Dus wat is Lighthouse?
Als je rondkijkt in PageSpeed Insights en Core Web Vitals, zie je misschien een andere naam veel opduiken: Lighthouse.
Lighthouse is de tool die Google gebruikt om de metingen en statistieken te verzamelen die het gebruikt voor PSI en CWV. Je kunt er ook Chrome, Opera of een op Chromium gebaseerde browser in vinden als onderdeel van de DevTools (druk op Command+Option+J (Mac) of Control+Shift+J (Windows, Linux, ChromeOS) om er meteen in te springen het control panel).
Het is ook beschikbaar als browser extensie voor Chrome, Opera en Firefox, maar ook als CLI-tool.
Er is zelfs een tool waarmee je je hele website in één keer kunt scannen: Unlighthouse. Als je echter al tools zoals SERanking, AHrefs of Semrush gebruikt, dan is dit al voor je gedaan (met meer gedetailleerde informatie over de problemen).
Lage scores en hoe je ze kunt oplossen
Er kunnen veel redenen zijn waarom de score voor je website niet in het groen staat, maar gelukkig geeft Google ook informatie over wat de problemen veroorzaakt en waar je een oplossing kunt zoeken. Dit kan zo simpel zijn als het toevoegen van een breedte en hoogte aan afbeeldingen of het traag laden van externe bestanden, maar het kan ook betekenen dat de server moet worden geüpgraded of dat er verbeterde caching-methoden moeten worden geïmplementeerd.
De statistieken zijn voornamelijk technische onderwerpen die kunnen worden opgelost op serverniveau (hardware, programmering en cache) of meer frontend gericht zijn (lettertypen, grote afbeeldingen en javascript).
Dit lijkt misschien niet van invloed op SEO, maar dat is het wel. Google houdt deze statistieken bij, omdat dit is hoe de bezoeker de website ziet en erover denkt. Niemand houdt van een trage en niet-reagerende website, dus de positie wordt beïnvloed als deze cijfers allemaal in het rood staan.
Je hoeft zich geen zorgen te maken dat een enkel oranje of rood cijfer je 10 plaatsen terugbrengt in de resultaten, maar als jouw concurrenten het beter doen, kunnen ze boven je worden vermeld.
Om deze cijfers te verbeteren, is het belangrijk om te begrijpen waarom ze niet zo goed zijn als Google zou willen, en of dit iets is dat je kunt en wilt verbeteren.
Snelle winsten
De eerste stap is kijken naar de ‘kansen’, die volgens Google snel en eenvoudig op te lossen zijn en die helpen bij de algehele prestaties van jouw pagina/website.
Het aanbieden van .webp afbeeldingen in plaats van .jpg en .png kan bijvoorbeeld een kleine snelheidsboost geven, omdat ze over het algemeen kleiner zijn. Echter, en dit is iets wat Google je niet vertelt, is het belangrijk om ook een fallback in te stellen, aangezien oudere browsers deze ‘next-gen formaten’ mogelijk niet ondersteunen.
Ook het uitstellen van scripts (= ze indien mogelijk laden zonder de rest van de pagina te blokkeren) is een goede manier om de snelheid van het laden van jouw pagina te verhogen. Maar dit moet met zorg worden gedaan, omdat sommige scripts moeten worden geladen om de pagina goed te laten werken.
‘Render-blocking resources’ worden hierdoor verbeterd, net als het lui laden van afbeeldingen en andere media.
Een belangrijk punt om naar te kijken zijn de verschillen tussen Desktop en Mobile, omdat ze verschillende suggesties kunnen geven, of een veel grotere impact kunnen hebben op mobiel.
Zoals de afbeeldingen laten zien, die van dezelfde pagina zijn, tonen desktop en mobiel enigszins verschillende mogelijke oplossingen. Hoewel degene die bijna altijd op live websites wordt getoond, de mogelijkheid is om ongebruikte Javascript te verminderen. De reden is simpel: Google Tag Manager en Google Analytics.
Dit klinkt misschien vreemd, maar de prestatiedaling voor het gebruik van GTM en GA is eigenlijk verschrikkelijk. Het voegt niet alleen veel extra bestanden toe aan de laad wachtrij, maar ze laden ook veel code die waarschijnlijk nooit wordt gebruikt. En tot slot zijn de caching regels voor deze bestanden verre van optimaal, wat opnieuw door Google als een slechte gewoonte wordt gezien.
En hoewel het toevoegen van veel tracking- en analyse scripts GTM normaal is, dragen deze alleen maar bij aan een algehele slechte prestatie.
Dus alles repareren is niet altijd mogelijk, maar als je weet wat de reden is, kun je een betere beslissing nemen over wat je kunt doen en waar jouw aandacht op kunt richten.
Hoe goed is je pagina
Het volgende deel van het PSI-rapport is de Diagnostiek. Deze duiden op de meer technische problemen met jouw website, die moeilijk te verbeteren zijn zonder code te herschrijven (zowel front- als backend).
“Vermijd een te grote DOM-grootte” wordt bijvoorbeeld veel gezien op WordPress-websites die een thema of pagebuilder gebruiken, die bekend staan om het toevoegen van veel extra elementen aan de HTML. Natuurlijk zijn deze bouwers geweldig om zonder programmeerkennis snel een mooie website te bouwen, maar de kwaliteit van de code is verre van geweldig.
Het kan ook betekenen dat er gewoon te veel elementen op de pagina zijn gecreëerd door een overmatige hoeveelheid gepresenteerde inhoud die slecht is geoptimaliseerd.
Als we naar de mobiele versie van dezelfde pagina kijken, zijn twee van de grootste rode vlaggen “Reduce the impact of third-party code” en “Reduce Javascript execution time”.
Deze worden meestal veroorzaakt door tracking- en analyse scripts van derden, zoals Google Tag Manager en de andere tools die het laadt.
Dit zijn scripts die je niet echt kunt controleren op hoe ze hun werk doen, maar het is mogelijk om de impact te verminderen bij het laden van de pagina, vooral wanneer die scripts niet nodig zijn op die specifieke pagina of op een later tijdstip kunnen worden geladen, door met behulp van aangepaste triggers.
De “First Contentful Paint (3G)” is hetzelfde als de FCP-statistiek, behalve dat deze wordt gemeten bij een mobiele 3G-verbinding, wat betekent dat deze langzamer is dan de gemiddelde internetsnelheden. Dit heeft tot gevolg dat externe bestanden (zoals Javascripts en stylesheets, maar ook afbeeldingen en fonts) langzaam worden geladen en ervoor zorgt dat de website in een later stadium iets laat zien dan gewenst.
Een van de belangrijkste oplossingen is het gebruik van de juiste caching, zodat bestanden sneller van de server worden geladen, en er zijn goede browser cache regels voor terugkerende bezoeken. Maar de test heeft geen browser cache, dus het laadt altijd alle bestanden bij elk verzoek.
Er zijn veel manieren om de laadsnelheid van bestanden te optimaliseren, zoals het verkleinen van scripts en stylesheets, het comprimeren van afbeeldingen, het wisselen van lettertypen en natuurlijk het lui laden van mediabestanden. Al deze optimalisatie technieken zorgen ervoor dat de FCP zo snel mogelijk is (en vele andere statistieken), maar kunnen de CLS verhogen, omdat er dingen zullen gebeuren nadat de pagina is geladen en de lay-out zal veranderen, omdat elementen plotseling meer of minder ruimte innemen dan in eerste instantie beschikbaar.
Specifieke oplossing voor mijn probleem
PageSpeed Insights test veel verschillende dingen, en veel dingen kunnen worden verbroken of moeten worden geoptimaliseerd. Het doornemen van elk mogelijk probleem en het bieden van een oplossing voor elke use-case zou waarschijnlijk nog eens 100 pagina’s met tekst- en codevoorbeelden toevoegen en zal niet genoeg zijn voor alle mogelijke scenario’s.
De meeste problemen die naar voren komen via de Core Web Vitals- en PageSpeed Insights-controles zijn technisch en vereisen een ontwikkelaar of technische oplossing om te worden opgelost. Maar begrijpen wat het probleem is en waar je een antwoord moet zoeken, is de eerste stap naar verbetering.