Waarom website snelheid ertoe doet
Een trage website kost je op twee manieren. Bezoekers haken af voordat ze hebben gezien wat je aanbiedt, vooral op een telefoon met een wisselende verbinding. En wie wel blijft, ervaart een pagina die verspringt of traag reageert als minder betrouwbaar. Dat drukt het aantal aanvragen en aankopen, ongeacht hoeveel verkeer je binnenhaalt.
Telt snelheid ook mee voor je positie in Google? Ja, maar met een kanttekening. Google schrijft in de uitleg over Core Web Vitals en zoekresultaten dat deze statistieken worden gebruikt door de rankingsystemen, en dat een goede score aan te raden is. Tegelijk benadrukt Google dat relevante, nuttige inhoud zwaarder weegt. Een snelle pagina met een zwak antwoord wint het niet van een iets tragere pagina met een uitstekend antwoord.
Snelheid is daarom vooral een kwestie van gebruikerservaring en conversie, met SEO als bijkomend voordeel. In onze eigen websitescore is het een vast onderdeel: Snelheid & Core Web Vitals.
Core Web Vitals: LCP, INP en CLS
Google meet de ervaring van echte bezoekers met drie statistieken, de Core Web Vitals:
- LCP (Largest Contentful Paint): hoe snel het grootste zichtbare element verschijnt, meestal een hoofdafbeelding of kop. Dit is de ‘voelt de pagina geladen’-meting.
- INP (Interaction to Next Paint): hoe snel de pagina reageert als iemand klikt, tikt of typt. INP verving in maart 2024 de oudere meting FID.
- CLS (Cumulative Layout Shift): hoeveel de inhoud onverwacht verspringt tijdens het laden.
Google beoordeelt elke statistiek op het 75e percentiel van de paginaweergaven, apart voor mobiel en desktop. Je haalt de norm dus pas als ten minste drie op de vier bezoeken binnen de grens blijven. Hieronder de grenswaarden zoals Google ze op web.dev publiceert.
| Statistiek | Wat het meet | Goed | Verbetering nodig | Slecht |
|---|---|---|---|---|
| LCP | Laden van het grootste element | 2,5 seconden of minder | Tussen 2,5 en 4 seconden | Meer dan 4 seconden |
| INP | Reactie op interactie | 200 milliseconden of minder | Tussen 200 en 500 milliseconden | Meer dan 500 milliseconden |
| CLS | Visuele stabiliteit | 0,1 of minder | Tussen 0,1 en 0,25 | Meer dan 0,25 |
Website snelheid testen: welke tool waarvoor
Er zijn veel snelheidstests voor websites. Twee gratis tools van Google zijn genoeg voor bijna elke situatie.
PageSpeed Insights
Met PageSpeed Insights test je de snelheid van een losse pagina. Je krijgt twee soorten gegevens:
- Veldgegevens: hoe echte Chrome-gebruikers je pagina de afgelopen 28 dagen ervoeren. Dit is wat telt voor de Core Web Vitals-beoordeling. Bij weinig verkeer zijn er soms geen veldgegevens voor de pagina; dan toont de tool eventueel gegevens voor het hele domein, of niets.
- Labgegevens: een gesimuleerde test met Lighthouse, met een score van 0 tot 100 en concrete verbeterpunten. Handig voor diagnose, maar het is één meting onder vaste omstandigheden.
Google Search Console
Het rapport Core Web Vitals in Search Console groepeert vergelijkbare pagina's en laat zien welke groepen goed, matig of slecht scoren, voor mobiel en desktop. Zo zie je of een probleem één pagina betreft of een heel sjabloon, zoals alle productpagina's. Google legt het rapport uit in de Search Console Help.
Lighthouse in Chrome
Voor ontwikkelaars: Lighthouse zit in de ontwikkelaarstools van Chrome en geeft dezelfde labmeting, plus de mogelijkheid om stap voor stap te zien wat er tijdens het laden gebeurt.
Zo lees je de uitslag van een snelheidstest
- Kijk eerst naar de veldgegevens. Staat er ‘Beoordeling Core Web Vitals: geslaagd’, dan ervaren echte bezoekers de pagina als goed, ook als de labscore niet perfect is.
- Test altijd mobiel. De mobiele test simuleert een tragere telefoon en verbinding; daar zitten de meeste problemen.
- Verwacht schommelingen. De labscore kan per test een paar punten verschillen door netwerk, server en externe scripts. Kijk naar de trend, niet naar één meting.
- Test per type pagina. Een homepage, een dienstpagina, een blog en een productpagina gebruiken vaak verschillende sjablonen met verschillende problemen.
- Lees de diagnose. Onder de score staat welk element de LCP is, welke scripts de pagina blokkeren en welke elementen verspringen. Daar begint de oplossing.
Een score van 100 is geen doel op zich. Een pagina die in de veldgegevens slaagt en prettig aanvoelt, is voor bezoekers en voor Google in orde.
Trage laadtijd (LCP) oplossen
Een slechte LCP heeft bijna altijd een van deze oorzaken. Google beschrijft ze uitgebreid in de gids LCP optimaliseren.
De server reageert traag
Voordat de browser iets kan tonen, moet de server de pagina leveren. Trage hosting, geen caching of zware databasequery's vertragen alles wat daarna komt. Oplossingen: paginacaching, een actuele serveromgeving, een CDN voor bezoekers verder weg en hosting die past bij je verkeer.
De hoofdafbeelding is te zwaar of laat
- Lever afbeeldingen in het juiste formaat en in moderne bestandsformaten zoals WebP of AVIF.
- Gebruik responsive afbeeldingen, zodat een telefoon geen afbeelding voor een groot scherm downloadt.
- Gebruik geen lazy loading voor de afbeelding die direct in beeld staat; geef die juist voorrang, bijvoorbeeld met fetchpriority="high".
CSS en JavaScript blokkeren de weergave
Grote stylesheets en scripts in de kop van de pagina houden de weergave tegen. Laad niet-kritieke scripts uitgesteld, verwijder ongebruikte code en laad lettertypen efficiënt.
De inhoud wordt pas in de browser opgebouwd
Als de pagina pas zichtbaar wordt nadat JavaScript alles heeft opgebouwd, duurt het langer. Waar mogelijk lever je de belangrijkste inhoud direct als HTML.
Trage reactie (INP) oplossen
INP gaat over wat er gebeurt nadat iemand klikt of tikt. Is de browser op dat moment bezig met zwaar JavaScript, dan moet de bezoeker wachten. Zie ook de gids INP optimaliseren.
- Ruim externe scripts op. Chatwidgets, trackingpixels, A/B-testtools, advertentiescripts en social embeds stapelen zich in de loop der jaren op. Vraag bij elk script wie het nog gebruikt.
- Laad scripts pas als ze nodig zijn, bijvoorbeeld een chatwidget pas na een klik op de knop.
- Breek lange taken op. Code die de browser lang bezet houdt, kan in kleinere stukken worden opgesplitst, zodat de pagina tussendoor kan reageren.
- Houd de pagina compact. Een zeer grote hoeveelheid HTML-elementen, vaak door page builders, maakt elke update trager.
- Geef direct visuele feedback bij een klik, en doe het zware werk daarna.
Verspringende inhoud (CLS) voorkomen
Je wilt op een knop tikken en op het laatste moment schuift de pagina omlaag. Dat is layout shift. De meest voorkomende oorzaken en oplossingen, uitgebreider beschreven in CLS optimaliseren:
- Afbeeldingen en video's zonder afmetingen. Geef width en height op, of reserveer ruimte met CSS, zodat de browser vooraf weet hoeveel plek het element inneemt.
- Advertenties, embeds en iframes die zonder gereserveerde ruimte worden geladen.
- Balken en meldingen die bovenaan worden ingevoegd, zoals een actiebalk of een cookiemelding die de inhoud wegduwt. Laat ze over de inhoud heen vallen of reserveer de ruimte.
- Webfonts die bij het laden een andere maat hebben dan het reservelettertype. Kies passende reservelettertypen en laad fonts efficiënt.
- Animaties die de opmaak veranderen. Gebruik transform-animaties, die de rest van de pagina niet verschuiven.
WordPress website sneller maken
WordPress is niet traag van zichzelf, maar wordt het makkelijk. Dit zijn de oorzaken die we het vaakst zien, met de oplossing:
- Te veel plugins. Elke plugin kan scripts en stylesheets toevoegen op elke pagina. Verwijder wat niet meer wordt gebruikt en vervang zware plugins door lichtere alternatieven.
- Een zwaar thema of page builder. Veel visuele bouwers genereren veel extra code. Bij een nieuwe website is een lichter thema of blokken op maat vaak de duurzamere keuze.
- Geen of dubbele caching. Gebruik één goede cachingoplossing, op serverniveau of via één plugin, en niet drie die elkaar in de weg zitten.
- Onbewerkte afbeeldingen. Laat afbeeldingen bij het uploaden automatisch verkleinen en omzetten naar een modern formaat.
- Verouderde serveromgeving. Een actuele PHP-versie en hosting die bij je verkeer past, maken vaak direct verschil in de reactietijd van de server.
- Een opgeblazen database vol revisies, verlopen tijdelijke gegevens en restanten van oude plugins.
Maak altijd eerst een back-up en test wijzigingen op een testomgeving. Snelheid is geen eenmalige klus: elke update of nieuwe plugin kan haar weer verslechteren. Daarom hoort snelheid bij goed website onderhoud. Overweeg je een nieuwe, lichte WordPress-site, kijk dan bij WordPress-website laten maken.
Snelheid blijvend bewaken, en wanneer je hulp inschakelt
- Controleer maandelijks het Core Web Vitals-rapport in Search Console.
- Test na elke grote wijziging: een nieuwe plugin, een nieuw script, een redesign.
- Spreek een grens af voor nieuwe toevoegingen: wat een externe tool aan laadtijd mag kosten, en wie dat beoordeelt.
- Leg eigenaarschap vast: wie mag scripts toevoegen via een tagmanager, en wie ruimt ze op?
Hulp inschakelen loont als de oorzaak in de server of de opbouw van het thema zit, als meerdere sjablonen tegelijk falen of als je website zo afhankelijk is van een page builder dat kleine aanpassingen weinig opleveren. Snelheid is een onderdeel van technische SEO, en een snellere pagina helpt ook bij conversie-optimalisatie.
Wil je weten of snelheid voor jouw website de grootste rem is, of dat er iets anders speelt? In de Beacon-strategiesessie spreek je 50 minuten met de oprichter over je ambitie, je markt en of we bij elkaar passen. Het is een gesprek, geen audit of rapport.