Waar op letten

Websitesnelheid testen en verbeteren: de Core Web Vitals-normen van 2026

Websitesnelheid testen en verbeteren: de Core Web Vitals-normen van 2026
Foto: Ralf Pfeifer — CC BY-SA 3.0 · Wikimedia Commons

Drie getallen bepalen of Google uw site 'snel genoeg' vindt

Sinds de update van Core Web Vitals eerder dit jaar zijn de drempelwaarden zelf gelijk gebleven — LCP (laadtijd van het grootste zichtbare element) onder 2,5 seconden, INP (reactiesnelheid op een klik of tik) onder 200 milliseconden en CLS (hoeveel de pagina nog verschuift tijdens laden) onder 0,1 — maar Google meet vooral INP nu strenger en kijkt scherper naar aanhoudend trage interacties in plaats van een gemiddelde. Een site die eerder net over de streep kwam, kan daardoor nu net onder de norm zakken zonder dat er iets aan de code is veranderd. Reden genoeg om de meting opnieuw te draaien, ook als u een tijd geleden nog een voldoende scoorde.

Hoe u de snelheid test

Voer uw URL in bij PageSpeed Insights van Google: dit geeft zowel een labscore (Lighthouse, gemeten onder gecontroleerde omstandigheden) als, als er genoeg bezoekers zijn, echte veldgegevens uit Chrome (CrUX) over de afgelopen 28 dagen. Vul daarnaast GTmetrix of Pingdom Tools in voor een tweede meting vanaf een andere serverlocatie — snelheid verschilt namelijk per meetpunt en per moment van de dag. Test zowel de mobiele als de desktopversie apart; op mobiel valt de score vaak een stuk lager uit door tragere verbindingen en processors.

Een score is een indicatie, geen eindoordeel. Belangrijker dan het cijfer zelf zijn de genoemde knelpunten onderaan het rapport: een te grote hero-afbeelding, een lettertype dat laat wordt geladen, of scripts van derden (chatwidgets, advertentienetwerken, trackingpixels) die de pagina laten wachten. Richt u eerst op de knelpunten die op elke pagina terugkomen — die leveren de grootste winst op met de minste moeite.

De meest voorkomende oorzaken van een trage site

Grote, ongecomprimeerde afbeeldingen, een overvloed aan plugins of scripts die niet meer gebruikt worden, een hostingpakket dat niet meer bij de omvang van de site past, en render-blocking CSS/JavaScript die de browser dwingt te wachten voordat er iets zichtbaar wordt, zijn verreweg de meest voorkomende boosdoeners. Een uitgebreider overzicht met voorbeelden staat in oorzaken van een trage website.

Wat u concreet kunt aanpassen

  • Afbeeldingen comprimeren en in WebP aanbieden in plaats van onbewerkte JPEG's of PNG's van meerdere megabytes.
  • Lazy loading instellen zodat afbeeldingen pas laden op het moment dat een bezoeker ernaar toescrollt.
  • Caching activeren op serverniveau of via een cache-plugin, zodat pagina's niet bij elk bezoek opnieuw worden opgebouwd.
  • Onnodige plugins en scripts verwijderen, vooral widgets die op elke pagina laden maar maar op een paar pagina's nodig zijn.
  • Een CDN inzetten voor sites met internationaal of landelijk verspreid publiek, zodat bestanden vanaf een server dichtbij de bezoeker komen.

Deze vijf punten samen lossen bij de meeste sites het grootste deel van de traagheid op, zonder dat u het hele platform hoeft te vervangen.

Soms zit het probleem niet in de site, maar in de server

Een site die ondanks gecomprimeerde afbeeldingen en minder plugins toch traag blijft, wijst vaak op de hostingomgeving zelf: een verouderde PHP-versie, een gedeeld hostingpakket dat de site moet delen met te veel andere sites op dezelfde server, of een database die na jaren ongebruikte gegevens is opgebouwd en trage zoekopdrachten uitvoert. Controleer bij twijfel of uw hostingpakket nog past bij de huidige omvang van de site, en of de server een recente PHP-versie draait — een verouderde versie is niet alleen trager maar ook een beveiligingsrisico op zichzelf.

Blijf meten, niet alleen eenmalig

Snelheid is geen eenmalig project: een nieuwe plugin, een grotere afbeelding in een blogpost of een drukker wordende server kan de score binnen een paar weken weer laten zakken. Neem een snelheidstest daarom op in de maandelijkse ronde van uw checklist website-onderhoud, en test in ieder geval opnieuw na elke grote wijziging aan de site. Komt u er zelf niet uit welke aanpassing het meeste oplevert, dan analyseert en verbetert Websitechecken de snelheid van uw site gericht, zonder dat u zelf in de techniek hoeft te duiken.

Veelgestelde vragen

Hoe vaak moet ik de snelheid van mijn website testen?
Minstens maandelijks als vast onderdeel van uw onderhoudsronde, en direct opnieuw na een grote wijziging zoals een thema-update, een nieuwe plugin of een verhuizing naar een andere hosting.
Waarom verschilt de score bij elke test?
Snelheidstools meten op verschillende momenten, vanaf verschillende serverlocaties en soms met verschillende netwerkomstandigheden. Kijk daarom niet naar één losse meting, maar naar de trend over meerdere tests en naar de concrete knelpunten die steeds terugkomen.
Telt mobiele snelheid net zo zwaar mee als desktop?
Ja, en voor de meeste sites zelfs zwaarder: Google gebruikt de mobiele meting als uitgangspunt voor de beoordeling, en het merendeel van het verkeer verloopt inmiddels via mobiel.
Kan een goedkoop hostingpakket de oorzaak van traagheid zijn?
Ja. Op gedeelde hosting deelt uw site serverresources met veel andere sites; bij drukte op die server merkt u dat direct in de laadtijd, ook als uw eigen site verder goed geoptimaliseerd is. Een upgrade naar een pakket met eigen resources lost dit vaak sneller op dan verdere optimalisatie van de site zelf.