Website snelheid optimaliseren: Core Web Vitals, WordPress en wanneer maatwerk sneller is (2026)
Trage website kost klanten. Zo verbeter je LCP, INP en CLS stap voor stap — voor WordPress, WooCommerce en nieuwe projecten.
- Google beoordeelt websitesnelheid via Core Web Vitals: LCP (Largest Contentful Paint, laadtijd hoofdinhoud) moet onder 2,5 seconden liggen, INP (Interaction to Next Paint, interactiviteit) onder 200 milliseconden en CLS (Cumulative Layout Shift, lay-outverschuivingen) onder 0,1. Meet gratis via PageSpeed Insights (pagespeed.web.dev).
- Voor WordPress-websites zijn drie ingrepen samen verantwoordelijk voor het grootste rendement: een cachingplugin (WP Super Cache, W3 Total Cache of LiteSpeed Cache), conversie van afbeeldingen naar WebP of AVIF-formaat, en een audit van onnodige plugins. Gezamenlijk reduceren ze de laadtijd in de meeste gevallen met 30-60 procent.
- Een op maat gebouwde website (Next.js of vergelijkbare moderne stack) heeft standaard hogere prestaties dan een WordPress-thema: geen overbodige CSS/JS, static rendering en een performance budget ingebakken in de bouw. Dit is relevant wanneer WordPress-optimalisaties hun plafond hebben bereikt.
Waarom websitesnelheid telt voor mkb: omzet, SEO en gebruikerservaring
Een trage website kost direct klanten. Google meet websitesnelheid via Core Web Vitals en gebruikt de scores als rankingfactor voor organische zoekresultaten en Google AI Overviews. Uit onderzoek van Google blijkt dat 53% van mobiele bezoekers afhaakt als een pagina langer dan 3 seconden laadt. Voor mkb-websites — webshops, dienstverleners, bureaus — betekent elke vertraging minder aanvragen, minder bestellingen en een lagere positie in Google. De goede nieuws: de drie meest impactvolle verbeteringen (caching, afbeeldingsoptimalisatie en plugin-audit) zijn voor de meeste WordPress-websites zelf door te voeren zonder grote investering. Wanneer de prestaties daarna nog steeds achterblijven, is een nieuw gebouwde website op een moderne stack de meest effectieve oplossing.
De drie Core Web Vitals: wat meten ze en wat zijn de drempelwaarden?
Core Web Vitals zijn de drie door Google gedefinieerde meetpunten voor laadprestaties, interactiviteit en visuele stabiliteit. Google gebruikt ze als directe rankingfactor.
LCP — Largest Contentful Paint: laadtijd van de hoofdinhoud
LCP meet hoe lang het duurt voordat het grootste zichtbare element op de pagina (meestal een hero-afbeelding of koptekst) volledig geladen is. De drempelwaarde: goed is onder 2,5 seconden, verbetering nodig is 2,5–4 seconden, slecht is boven 4 seconden. LCP wordt het meest beïnvloed door grote afbeeldingen, trage serverrespons (TTFB) en blokkerende JavaScript of CSS. Preload het hero-element met <link rel="preload"> en gebruik next-gen afbeeldingsformaten (WebP of AVIF) met een vaste breedte- en hoogte-attribuut.
INP — Interaction to Next Paint: responsiviteit bij klikken en tikken
INP (vervangt CWV-maatstaf FID per maart 2024) meet de vertraging tussen een gebruikersinteractie — klikken, tikken, typen — en de zichtbare reactie van de pagina. Drempelwaarde: goed is onder 200 milliseconden, verbetering nodig is 200–500 ms, slecht is boven 500 ms. INP-problemen komen vooral voor op WooCommerce-pagina's met veel JavaScript (sliders, livechat, chat-widgets). Defer of async laden van niet-kritische scripts en verwijderen van onnodige plugins verbetert INP direct.
CLS — Cumulative Layout Shift: visuele stabiliteit zonder verrassingen
CLS meet hoe veel de lay-out onverwacht verschuift terwijl de pagina laadt. Een hoge CLS-score ontstaat wanneer afbeeldingen zonder breedte- en hoogte-attribuut geladen worden, weblettertypen de tekst doen verspringen of advertenties content naar beneden duwen. Drempelwaarde: goed is onder 0,1, verbetering nodig is 0,1–0,25, slecht is boven 0,25. De fix is in de meeste gevallen eenvoudig: voeg width en height toe aan alle img-elementen en gebruik font-display: swap voor weblettertypen.
TTFB — Time to First Byte: hoe snel reageert de server?
TTFB is geen Core Web Vital maar wel een directe voorloper: hoe lang duurt het voordat de browser de eerste byte van de server ontvangt? Google beschouwt TTFB onder 800 milliseconden als goed. Een hoge TTFB wijst op een trage hostingserver, gedeeld hosting met te veel mede-gebruikers, geen server-side caching of een verre serverlocatie zonder CDN. Overstappen naar managed hosting (indicatief — controleer bij aanbieder) of een caching-laag toevoegen (bijv. Cloudflare gratis tier) zijn de meest effectieve ingrepen.
Vijf ingrepen die de meeste WordPress-websites 30-60% sneller maken
WordPress-websites hebben van nature meer gewicht dan nodig — thema's laden standaard CSS en JavaScript die je niet gebruikt. Dit zijn de vijf ingrepen met het hoogste rendement.
1. Cachingplugin installeren: WP Super Cache, W3 Total Cache of LiteSpeed Cache
Een cachingplugin slaat HTML-pagina's op als statische bestanden, zodat PHP en de database niet bij elk paginaverzoek opnieuw draaiend hoeven. Dit verlaagt de serverbelasting en TTFB direct. WP Super Cache (gratis) is eenvoudigste optie; W3 Total Cache (gratis) heeft meer instellingen; LiteSpeed Cache (gratis) is alleen beschikbaar op LiteSpeed-hostingservers maar geeft de beste resultaten. Activeer paginacaching en aanbevolen instellingen na installatie. Gebruik altijd maar één cachingplugin tegelijk.
2. Afbeeldingen naar WebP of AVIF converteren en lazy loading inschakelen
Afbeeldingen zijn verantwoordelijk voor het grootste deel van de paginagrootte op de meeste mkb-websites. WebP-bestanden zijn gemiddeld 25-34% kleiner dan JPEG bij vergelijkbare kwaliteit; AVIF is nog kleiner maar heeft minder brede browserondersteuning. Plugins als Imagify, ShortPixel of EWWW Image Optimizer (alle indicatief — controleer prijzen bij aanbieder) converteren bestaande afbeeldingen automatisch. Zorg dat alle afbeeldingen buiten het zichtbare scherm lazily geladen worden (WordPress 5.5+ ondersteunt dit standaard via loading="lazy"). Voeg width en height toe aan elk img-element om CLS te vermijden.
3. Plugin-audit: verwijder alles wat je niet actief gebruikt
Elke actieve WordPress-plugin laadt extra code — JavaScript, CSS, PHP-functies — bij elk paginaverzoek, ook als hij alleen op de achtergrond draait. Maak een lijst van alle geïnstalleerde plugins en deactiveer alles wat je niet actief gebruikt. Vervang meerdere losse plugins door gecombineerde alternatieven waar mogelijk (bijv. een SEO-plugin met sitemap-functie in plaats van twee aparte). Gebruik de Browser DevTools (tab Network) of GTmetrix om te zien welke scripts het zwaarst wegen.
4. WooCommerce-optimalisaties: cart fragments uitschakelen
WooCommerce laadt standaard een AJAX-verzoek (cart-fragments.min.js) op elke pagina om de winkelwagen actueel te houden — zelfs op pagina's zonder winkelwagenfunctionaliteit. Dit blokkeert het laden en verslechtert INP en LCP. Schakel cart fragments uit via je cachingplugin of via een lichte snippet als je geen persistente winkelmand nodig hebt. Verkleins ook productafbeeldingen voor cataloguspagina's (gebruik WooCommerce-beeldformaten met vaste breedte en hoogte, bijv. 300×300 px voor productthumbnails).
5. CDN en betere hosting: serverlocatie en snelheid dichter bij de bezoeker
Een Content Delivery Network (CDN) zoals Cloudflare (gratis tier voor kleine sites) slaat statische bestanden op in servers dichter bij de bezoeker, waardoor laadtijden in heel Nederland en Europa dalen. Voor websites op goedkope gedeelde hosting (€1–3/maand) is overstappen naar managed WordPress-hosting (indicatief — controleer bij aanbieder) de meest impactvolle stap: betere server-hardware, snellere PHP-versie en ingebouwde serverside caching. Kies een hostinglocatie in Amsterdam of Frankfurt voor Nederlandse bezoekers.
Wanneer is een nieuwe website op maat sneller dan een geoptimaliseerde WordPress-site?
WordPress-optimalisatie heeft een plafond. Wanneer een website een hoge LCP, INP of CLS blijft houden na caching, afbeeldingsoptimalisatie en plugin-audit, dan is het thema of de bouw zelf de bottleneck. Een op maat gebouwde website lost dit fundamenteel op.
Statische rendering: geen database-aanroep bij elk verzoek
Een website gebouwd met Next.js (de stack die Delahaye Solutions gebruikt) rendert pagina's bij deploy als statische HTML. Er is geen PHP, geen database-aanroep en geen server-side verwerkingstijd bij elk bezoek. De TTFB is daardoor structureel lager dan bij WordPress, ook zonder cachingplugin. Statische sites zijn ook inherent veiliger: er is geen PHP-kwetsbaarheid of database te compromitteren.
Performance budget: alleen de code die je echt gebruikt
Een WordPress-thema laadt honderden kilobytes CSS en JavaScript die niet gebruikt worden op elke individuele pagina. Een maatwerk Next.js-website laadt uitsluitend de code die die specifieke pagina nodig heeft (code splitting per route). Gecombineerd met optimalisaties als next/image (automatische WebP-conversie en lazy loading), font-display: swap en preload-hints resulteert dit in structureel betere Core Web Vitals zonder handmatige aanpassingen.
Wanneer maatwerk te overwegen: na drie signalen
Drie signalen dat een nieuwe website financieel verstandiger is dan verdere WordPress-optimalisatie: (1) PageSpeed Insights scoort na optimalisatie nog steeds onder 70 op mobiel, (2) het thema of paginabouwer (Elementor, Divi, WPBakery) veroorzaakt zware JavaScript-blokkades die niet opgelost worden door cachingplugins, of (3) de website heeft een hoog conversiedoel (webshop, leadformulier) waarbij elke extra seconde laadtijd direct omzetimpact heeft. Delahaye Solutions bouwt websites vanaf €1.250 (Starter, enkelvoudig project) en €2.950 (Business, uitgebreidere projecten) — indicatief, zie prijzenpagina voor actueel overzicht.
Website snelheid optimaliseren: veelgestelde vragen
Hoe meet ik de Core Web Vitals van mijn website gratis?
Wat is een goede PageSpeed-score voor een mkb-website?
Welke cachingplugin is het beste voor WordPress?
Helpt een CDN echt voor een Nederlandse mkb-website?
Wanneer kies ik een nieuwe website in plaats van mijn WordPress-website te optimaliseren?
Trage website? Wij optimaliseren of bouwen opnieuw.
Van een snelheidsaudit tot een volledig nieuwe website op Next.js — we kijken samen wat het meeste oplevert voor jouw situatie.
Plan mijn gratis gesprek →Gratis · binnen één werkdag · niet goed = niet betalen