Websitesnelheid verbeteren: Core Web Vitals in gewone taal

Core Web Vitals zijn drie metingen waarmee Google bekijkt hoe snel en prettig je website aanvoelt voor echte bezoekers: hoe snel de belangrijkste inhoud verschijnt, hoe snel de pagina reageert als iemand klikt, en of de opmaak stil blijft staan. Je hoeft geen programmeur te zijn om ze te begrijpen. In dit artikel lees je wat de drie metingen betekenen, hoe zwaar ze wegen, hoe je ze meet en wat je kunt doen om je website sneller te maken.

Wat zijn Core Web Vitals?

Snelheid is een vaag begrip. Een pagina kan snel beginnen met laden en toch traag aanvoelen, omdat de foto bovenaan pas na vier seconden verschijnt of omdat de knop waar je op tikt een halve seconde niets doet. Google heeft daarom drie metingen gekozen die elk een ander deel van de ervaring vangen. Samen heten ze de Core Web Vitals.

LCP: wanneer zie je de hoofdzaak?

LCP staat voor Largest Contentful Paint. Het meet hoe lang het duurt voordat het grootste zichtbare stuk inhoud op het scherm staat. Meestal is dat de grote foto bovenaan, soms een videobeeld of een blok tekst. Volgens web.dev is een LCP van 2,5 seconden of minder goed en is alles boven de 4 seconden slecht.

In gewone taal: LCP is het moment waarop een bezoeker denkt “ah, ik zie waar ik ben”.

INP: reageert de pagina meteen?

INP staat voor Interaction to Next Paint. Het meet hoe snel de pagina zichtbaar reageert als iemand klikt, tikt of een toets indrukt. Scrollen en met de muis over iets heen bewegen tellen niet mee. De uiteindelijke waarde is ongeveer de traagste reactie tijdens het bezoek, waarbij uitschieters worden weggelaten. Goed is 200 milliseconden of minder, slecht is meer dan 500 milliseconden.

In gewone taal: INP gaat over het gevoel dat een knop “hangt”. Je tikt op het menu en er gebeurt even niets, dus je tikt nog een keer.

INP is sinds 12 maart 2024 de officiële meting voor reactiesnelheid. Het verving FID (First Input Delay), dat alleen naar de eerste klik keek. Kom je in een oudere handleiding nog FID tegen, dan is die op dat punt verouderd.

CLS: blijft alles op zijn plek?

CLS staat voor Cumulative Layout Shift. Het meet hoeveel de inhoud onverwacht verschuift terwijl de pagina laadt. Je kent het waarschijnlijk: je wilt op een link tikken, er schuift ineens een banner of foto in beeld en je tikt op iets anders. web.dev geeft het voorbeeld van iemand die per ongeluk een bestelling bevestigt die hij juist wilde annuleren. Een CLS van 0,1 of minder is goed, boven de 0,25 is slecht.

CLS is geen tijd maar een getal zonder eenheid. Hoe hoger, hoe meer en hoe grotere stukken van de pagina verspringen.

De grenzen op een rij

Bron: web.dev en het rapport Site-vitaliteit in Search Console. Belangrijk detail: Google kijkt naar het 75e percentiel, apart voor mobiel en desktop. Drie op de vier bezoeken moeten dus binnen de grens blijven. Een pagina slaagt pas als alle drie de metingen goed zijn.

Hoe belangrijk zijn Core Web Vitals voor Google?

Hier wordt online veel over overdreven, in beide richtingen. Google is er zelf vrij duidelijk over. In de uitleg over pagina-ervaring staat dat Core Web Vitals worden gebruikt door de rankingsystemen. In dezelfde tekst staat ook dat Google altijd de meest relevante inhoud probeert te tonen, zelfs als de pagina-ervaring matig is, en dat een goed rapport niet garandeert dat je bovenaan komt. Google schrijft zelfs dat een perfecte score najagen alleen voor SEO misschien niet de beste besteding van je tijd is.

Wat betekent dat voor jou?

• Inhoud gaat voor. Een trage pagina die precies beantwoordt wat iemand zoekt, kan het beter doen dan een snelle pagina met een vaag verhaal.
• Snelheid kan het verschil maken tussen pagina’s die verder vergelijkbaar zijn. Google beveelt het daarom aan voor succes in Search.
• Je bezoekers merken het direct. Een foto die lang op zich laat wachten, een menu dat niet reageert of een knop die wegspringt, maakt een slechte eerste indruk. Dat raakt je aanvragen, ook als je ranking gelijk blijft.

Zie Core Web Vitals dus als onderhoud aan de winkel, niet als geheim wapen voor Google. Hoe snelheid past in het grotere geheel van technische SEO, lees je in de technische SEO-checklist voor WordPress.

Zo meet je de snelheid van je website

Er zijn twee soorten metingen, en het verschil zorgt voor veel verwarring.

• Labdata komt uit een test die een computer nu uitvoert, met een gesimuleerde telefoon en verbinding. Handig om problemen te vinden, want je ziet precies wat er gebeurt.
• Velddata komt van echte bezoekers die Chrome gebruiken, verzameld in het Chrome User Experience Report (CrUX). Google beoordeelt je Core Web Vitals op deze gegevens.

PageSpeed Insights

Ga naar PageSpeed Insights, vul een adres in en je krijgt twee blokken. Bovenaan staat, als er genoeg bezoek is, de beoordeling van de Core Web Vitals op basis van echte bezoekers over de afgelopen 28 dagen. Daaronder staat de prestatiescore van 0 tot 100 uit Lighthouse, een labtest. Volgens de documentatie van PageSpeed Insights is 90 of hoger goed, 50 tot en met 89 vraagt om verbetering en onder de 50 is slecht.

Die score van 0 tot 100 is niet hetzelfde als slagen voor de Core Web Vitals. Een site kan een labscore van 60 hebben en bij echte bezoekers prima scoren, en andersom. Google zegt er zelf bij dat goede labdata niet betekent dat echte bezoekers ook een goede ervaring hebben. Gebruik de labscore dus als diagnose, niet als rapportcijfer. Let ook op dat Lighthouse INP niet kan meten, omdat er in de test geen echte gebruiker klikt. Het toont in plaats daarvan Total Blocking Time als benadering.

Search Console: het rapport Site-vitaliteit

In Google Search Console heet het rapport in het Nederlands Site-vitaliteit. Het groepeert pagina’s die op elkaar lijken en geeft per groep de status Goed, Verbetering nodig of Slecht, apart voor mobiel en desktop. De slechtste meting bepaalt de status: een groep met een goede LCP maar een slechte CLS staat op Slecht.

Heb je iets opgelost, dan kies je bij het probleem voor Bijhouden starten. Google houdt de pagina’s dan 28 dagen in de gaten. Verbeteringen worden dus niet de volgende dag zichtbaar in dit rapport.

Weinig bezoek? Dan zie je vaak geen velddata

Veel kleine bedrijven openen het rapport en zien “Geen gegevens beschikbaar”. Dat betekent meestal niet dat er iets mis is. Er zijn dan te weinig Chrome-bezoekers om een betrouwbare meting te maken. PageSpeed Insights valt in dat geval terug op de gegevens van je hele domein, en als ook die er niet zijn, toont het alleen de labtest. Voor een kleine site is de labtest op mobiel dan je beste houvast. Test je belangrijkste pagina’s: de homepage, je dienstpagina’s en de contactpagina.

LCP verbeteren: de hoofdzaak sneller in beeld

Bij de meeste mkb-sites is het LCP-element een grote foto bovenaan de pagina, de zogenaamde hero. De snelste winst zit daar. Volgens de LCP-handleiding van web.dev zijn dit de belangrijkste knoppen:

• Maak de foto niet groter dan nodig. Een foto rechtstreeks van je telefoon kan duizenden pixels breed zijn, terwijl het vak op je site veel kleiner is. Verklein en comprimeer voor je uploadt, en gebruik een modern formaat zoals WebP.
• Laat de bovenste foto niet “lazy” laden. Lazy loading betekent dat afbeeldingen pas laden als je ernaartoe scrolt. Goed voor foto’s verderop, maar web.dev zegt letterlijk dat je de LCP-afbeelding nooit lazy moet laden. WordPress houdt hier sinds versie 6.3 zelf rekening mee en geeft de waarschijnlijke LCP-foto automatisch voorrang, wat volgens het WordPress-team de LCP doorgaans 5 tot 10 procent verbetert. Een optimalisatieplugin of paginabouwer kan dat weer ongedaan maken, dus controleer het.
• Vermijd sliders bovenaan. Een carrousel met vijf grote foto’s en een script dat ze laat wisselen is zwaarder dan één goede foto. Vaak kijkt niemand verder dan de eerste dia.
• Kijk naar je server. De tijd tot de eerste byte (TTFB) telt mee in de LCP. web.dev noemt 0,8 seconden of minder als ruwe richtlijn. Is je server traag, dan helpen paginacaching, een actuele PHP-versie of betere hosting meer dan het schaven aan afbeeldingen. Een CDN brengt bestanden dichter bij de bezoeker.
• Minder blokkerende bestanden. CSS en scripts die bovenin de pagina staan, houden de weergave op. Dit is werk voor je webbouwer of een goed ingestelde optimalisatieplugin.

INP verbeteren: een site die meteen reageert

INP-problemen hebben bijna altijd met JavaScript te maken. Als de browser druk is met het uitvoeren van scripts, moet jouw klik wachten. web.dev noemt elke taak die langer dan 50 milliseconden duurt een lange taak. Een paar van die taken achter elkaar en een bezoeker merkt het.

Waar komt dat JavaScript vandaan op een gewone bedrijfssite?

• Scripts van derden. Chatwidgets, social-media-embeds, video’s, advertentie- en trackingcodes, A/B-testtools. web.dev noemt scripts van derden een veelvoorkomende oorzaak van vertraging en geeft een eenvoudig advies: voegt een script geen duidelijke waarde toe, haal het weg.
• Te veel plugins. Elke plugin die op elke pagina eigen scripts laadt, telt op. Een plugin die je niet meer gebruikt, hoort niet actief te zijn.
• Zware paginabouwers en thema’s. Veel animaties, effecten en geneste blokken maken de pagina groot. Volgens web.dev wordt het bijwerken van het scherm na een klik duurder naarmate de pagina meer elementen bevat.

Wat je zelf kunt doen: maak een lijst van alles wat er via plugins, Google Tag Manager of losse codes op je site draait, en vraag bij elk onderdeel: wie gebruikt dit nog, en waarvoor? Je zult vaak oude trackingcodes van een campagne van jaren geleden vinden. De rest, zoals scripts later laten laden of code opsplitsen, is werk voor je webbouwer.

CLS verbeteren: niets mag verspringen

CLS is vaak het makkelijkst op te lossen, omdat de oorzaken goed te zien zijn. Open je site op je telefoon, liefst via mobiele data, en kijk of er iets verschuift tijdens het laden. De meest voorkomende oorzaken volgens de CLS-handleiding van web.dev:

• Afbeeldingen zonder afmetingen. Weet de browser niet hoe hoog een foto wordt, dan schuift de tekst eronder op zodra de foto binnen is. Breedte en hoogte in de code, of een vaste beeldverhouding in de CSS, lost dit op.
• Banners en meldingen die bovenin verschijnen. Een balk met een actie of een cookiemelding die de hele pagina naar beneden duwt. Reserveer er vooraf ruimte voor, of laat hem over de inhoud heen zweven in plaats van ertussen.
• Embeds en advertenties. Een kaart, video of widget die pas later zijn hoogte krijgt. Geef het vak vooraf een vaste hoogte.
• Lettertypen. Als een webfont later binnenkomt en groter of kleiner is dan het lettertype dat eerst werd getoond, verspringt de tekst. web.dev adviseert onder meer een reservelettertype dat qua maat dicht bij het webfont ligt, en belangrijke lettertypen vroeg te laden.

Stappenplan: zo maak je je website sneller

Je hoeft niet alles tegelijk te doen. Werk in deze volgorde en meet na elke stap opnieuw. Maak voor je begint een back-up, zeker als je plugins gaat verwijderen of instellingen gaat veranderen.

1. Nulmeting. Test je homepage en twee of drie belangrijke dienstpagina’s in PageSpeed Insights, op mobiel. Noteer de velddata (als die er is) en de labwaarden. Kijk in Search Console of het rapport Site-vitaliteit gegevens toont.
2. Kijk welke meting faalt. Alleen LCP rood? Dan begin je bij afbeeldingen en server. INP slecht? Dan bij scripts en plugins. CLS? Dan bij wat er verspringt.
3. Doe eerst de grote, eenvoudige dingen. Foto’s verkleinen, ongebruikte plugins en oude scripts weghalen, caching aanzetten.
4. Daarna het technische werk. Scripts uitstellen, CSS opschonen, hosting of thema heroverwegen. Dat laat je doen door iemand die weet wat hij aanpast.
5. Meet opnieuw en houd het bij. Labdata zie je meteen veranderen. Velddata loopt 28 dagen achter. Herhaal de check na elke nieuwe plugin, thema-update of grote wijziging.

Een waarschuwing over plugins die beloven alles in één klik op te lossen: ze kunnen veel goeds doen, maar ook dingen breken, zoals een formulier dat niet meer verstuurt of een menu dat niet meer opent. Test na het instellen altijd je formulieren, je menu op mobiel en je knoppen. Een snelle site die geen aanvragen meer doorstuurt, schiet zijn doel voorbij. Waar je verder op let als bezoekers wel komen maar geen contact opnemen, lees je in waarom je website geen aanvragen oplevert.

Wanneer is opnieuw bouwen logischer?

Soms zit de traagheid in de basis: een zwaar thema met een paginabouwer, tientallen plugins die van elkaar afhankelijk zijn, of een site die jaren niet is bijgewerkt. Dan kost blijven repareren soms meer dan een lichte nieuwe opzet. Dat is geen automatisme. Kijk eerst wat de grootste oorzaken zijn en wat het kost om die weg te nemen. Wat een nieuwe site gemiddeld kost, lees je in wat kost een website laten maken.

Hulp bij een snelle, goed onderhouden website

Snelheid is geen klus die je één keer afrondt. Elke nieuwe plugin, elke grote foto en elk extra script kan je scores weer laten zakken. Daarom hoort het bij gewoon websiteonderhoud. Bij VelaVen bouwen en onderhouden we WordPress-sites: updates, back-ups, beveiliging, snelheid en kleine aanpassingen elke maand. Onze eigen sites, zoals tuinkeuzehulp.nl en boekenreeks.nl, onderhouden we op dezelfde manier. AI helpt ons om problemen snel te vinden, een mens beslist wat er wordt aangepast en test het resultaat. Wil je weten wat dat voor jouw site betekent, kijk dan bij website en onderhoud.