Core Web Vitals voor WordPress: Optimalisatiehandleiding (2026)

WordPress en Core Web Vitals: de stand van zaken

WordPress heeft een performanceprobleem. Volgens het Core Web Vitals Technology Report (gebaseerd op CrUX-data) scoort WordPress op mobiel structureel slechter dan Shopify, Wix en Squarespace qua slagingspercentage voor Core Web Vitals. Eind 2025 slaagde op mobiel slechts zo'n 44% van de WordPress-sites voor alle drie de Core Web Vitals. Vergelijk dat met Shopify op circa 65% en Wix boven de 60%.

Dat ligt niet aan WordPress zelf. De WordPress-core is compact en snel. Het probleem zit in wat er bovenop komt: zware thema's, trage pagebuilders, tientallen plugins die elk hun eigen JavaScript en CSS injecteren, niet-geoptimaliseerde afbeeldingen en goedkope shared hosting met trage serverresponstijden.

Het mooie is: doordat WordPress je volledige controle geeft over je code, hosting en optimalisatiestrategie, levert slim optimaliseren hier juist het meeste op. De sites die ik optimaliseer, slagen standaard op elke pagina voor Core Web Vitals. Je moet alleen weten welke WordPress-specifieke factoren elke metric beïnvloeden en die systematisch aanpakken.

WordPress Core Web Vitals in cijfers

Het CrUX Technology Report en HTTP Archive houden de CWV-slagingspercentages bij voor elk groot CMS. Dit is hoe WordPress er eind 2025 voor staat:

Bron: CrUX Technology Report via HTTP Archive, juni 2025. INP-ranglijst afkomstig uit analyse van SearchEngineJournal.

De belangrijkste conclusie uit deze data: het probleem van WordPress is niet INP (85,9% slaagt, slechts iets onder het gemiddelde). Het probleem van WordPress is LCP, veroorzaakt door een trage TTFB. Slechts 32% van de WordPress-sites heeft een goede TTFB volgens CrUX-data, vergeleken met fully-hosted platforms zoals Shopify waar TTFB op infrastructuurniveau is geregeld. Dit is een kwestie van hostingkwaliteit, niet van het platform zelf.

Bij WordPress-sites die CoreDash monitort, is het patroon consistent: vóór optimalisatie ligt de mediane mobiele LCP tussen 3,5 en 4,5 seconden. Voer je de hosting-, caching- en beeldoptimalisaties uit deze handleiding door, dan zakt die mediaan naar 1,6 tot 2,1 seconden. De ingreep met veruit de meeste impact is vrijwel altijd de overstap van shared hosting zonder page caching naar managed hosting met server-level caching en een CDN. Die stap alleen al verlaagt de TTFB doorgaans van 800 ms+ naar minder dan 200 ms.

Waarom WordPress moeite heeft met Core Web Vitals

Voordat we naar de fixes kijken, moet je begrijpen waarom WordPress-sites zakken voor Core Web Vitals. Elk probleem dat ik in mijn adviespraktijk tegenkom, is terug te leiden naar een of meer van deze vijf hoofdoorzaken:

1. Pagebuilder-bloat

Pagebuilders zoals Elementor, Divi en WPBakery voegen aan elke pagina een enorme hoeveelheid extra HTML, CSS en JavaScript toe. Elementor alleen al kan meer dan 21 MB aan uitgepakte code toevoegen aan een WordPress-installatie. Elk widget, elke animatie en elke stylingoptie vergroot de DOM en zorgt voor meer render-blocking resources.

Het resultaat: overladen pagina's met honderden overbodige <div>-wrappers, meerdere CSS-bestanden die op elke pagina laden ongeacht of de widgets worden gebruikt, en JavaScript dat tijdens het laden de main thread blokkeert. Dit raakt LCP direct (meer render-blocking resources), verslechtert INP (meer JavaScript die vecht om de main thread) en veroorzaakt CLS (layout-herberekeningen zodra de CSS van de builder binnenkomt).

Gutenberg (de standaard block editor van WordPress) levert aanzienlijk schonere HTML met een veel kleinere DOM. Bouw je een nieuwe WordPress-site, overweeg dan Gutenberg met een lichtgewicht thema zoals GeneratePress, Astra of Kadence in plaats van een zware pagebuilder.

2. Te veel plugins

De gemiddelde WordPress-site heeft 20 tot 30 actieve plugins. Elke plugin kan zijn eigen CSS en JavaScript op elke pagina injecteren, zelfs op pagina's waar die plugin helemaal niet nodig is. Een contactformulier-plugin die scripts op je homepage laadt. Een WooCommerce-script dat meedraait op je blogartikelen. Een slider-plugin die overal laadt terwijl je hem maar op één pagina gebruikt.

Ik heb WordPress-audits gedaan waarbij het verwijderen van ongebruikte plugin-scripts het totale volume aan JavaScript met ruim 40% terugbracht. De fix is niet per se het compleet verwijderen van plugins. Het draait om conditioneel laden: zorgen dat de assets van een plugin alleen laden op pagina's waar ze echt nodig zijn. Met plugins zoals Perfmatters en Asset CleanUp bepaal je per pagina welke scripts en styles mogen laden.

3. Niet-geoptimaliseerde afbeeldingen

WordPress dwingt standaard geen beeldoptimalisatie af. Redacteuren uploaden foto's van 3000x2000 pixels rechtstreeks vanaf hun camera, en WordPress serveert ze op volledige resolutie, zelfs wanneer het thema ze maar op 800 pixels breed toont. Op de meeste WordPress-pagina's is het LCP-element een afbeelding. Een niet-geoptimaliseerde hero image is de meest voorkomende oorzaak van een onvoldoende op LCP.

Vanaf WordPress 5.8 is er standaard WebP-ondersteuning en vanaf 5.5 native lazy loading, maar die functies vereisen een goede configuratie. Veel thema's en plugins overschrijven dit of gebruiken hun eigen (vaak slechtere) versies. Bekijk onze handleiding over afbeeldingen optimaliseren voor Core Web Vitals voor de complete strategie.

4. Trage hosting en serverrespons

De Time to First Byte (TTFB) van je server bepaalt de ondergrens voor je LCP. Geen enkele frontend-optimalisatie kan compenseren voor een server die er 800 ms over doet om te antwoorden. Goedkope shared hosting (waarbij honderden sites één server delen) is de meest voorkomende oorzaak van een slechte TTFB bij WordPress-sites.

WordPress is een dynamisch CMS dat bij elk request PHP uitvoert en een MySQL-database raadpleegt (tenzij er caching is ingesteld). Zonder page caching is WordPress altijd trager dan een statische site. Met goede caching en een degelijke host blijft de TTFB onder de 200 ms. Zonder caching is 500 ms tot 1500 ms eerder regel dan uitzondering. Lees meer in onze handleiding voor Time to First Byte-optimalisatie.

5. Problemen met het laden van fonts

Veel WordPress-thema's laden Google Fonts vanaf de servers van Google. Dat vereist een DNS-lookup en een verbinding met een extern domein voordat de fonts überhaupt kunnen downloaden. Dit vertraagt de tekst-render (wat LCP schaadt bij tekstgebaseerde LCP-elementen) en kan een Flash of Unstyled Text (FOUT) veroorzaken zodra het webfont binnenkomt en de fallback vervangt, met een layout shift als gevolg.

De fix: host je fonts lokaal en gebruik font-display: swap of font-display: optional met een zorgvuldig afgestemd fallback-font om layout shifts te minimaliseren.

LCP aanpakken in WordPress

Largest Contentful Paint meet hoe snel je belangrijkste content zichtbaar is. Bij WordPress zijn onvoldoendes voor LCP vrijwel altijd terug te leiden naar afbeeldingen, render-blocking resources of een trage serverrespons. Dit is de prioriteitsvolgorde om LCP aan te pakken:

Stel je LCP-element vast

Haal je pagina door PageSpeed Insights en kijk onder 'Diagnostische gegevens' naar 'Element voor Largest Contentful Paint'. Op de meeste WordPress-pagina's is dit de hero image, de uitgelichte afbeelding of het eerste grote tekstblok. Pas als je weet wat je LCP-element is, bepaal je de juiste optimalisatiestrategie.

Preload de LCP-afbeelding

Is je LCP-element een afbeelding, voeg dan een preload-hint toe in de <head> van je thema. In WordPress doe je dit via de functions.php van je thema:

// Preload de hero image op de homepage
function preload_lcp_image() {
    if ( is_front_page() ) {
        echo '<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" fetchpriority="high">';
    }
}
add_action( 'wp_head', 'preload_lcp_image', 1 );

Zet ook fetchpriority="high" direct op de <img>-tag van je LCP-afbeelding. Vanaf WordPress 6.3 gebeurt dit automatisch voor de eerste afbeelding in de content, maar controleer altijd of je thema dit goed oppakt. Voor de volledige strategie bekijk je hoe je de LCP-afbeelding preloadt.

Elimineer render-blocking resources

WordPress-thema's en -plugins laden regelmatig CSS en JavaScript in de <head> die het renderen blokkeren. Gebruik een performance-plugin om niet-kritieke JavaScript te deferren en niet-kritieke CSS asynchroon te laden. De meest effectieve opties:

• WP Rocket: stelt JavaScript-uitvoering uit tot interactie van de gebruiker, genereert automatisch critical CSS
• FlyingPress: lichtgewicht alternatief met vergelijkbare mogelijkheden voor defer en critical CSS
• Perfmatters: scriptbeheer tot in detail per pagina, ongebruikte functies uitschakelen
• Onze WP Core Web Vitals-plugin: specifiek gebouwd voor CWV-optimalisatie met LCP-detectie en geavanceerde timing voor afbeeldingen

Wil je dit handmatig oplossen, bekijk dan 14 methoden om JavaScript te deferren en hoe je critical CSS genereert en inzet.

Schakel page caching in

Page caching slaat de volledig gerenderde HTML van elke pagina op, zodat WordPress niet bij elk bezoek PHP hoeft uit te voeren en de database hoeft te bevragen. Dit verlaagt de TTFB enorm, wat direct je LCP verbetert. De meeste goede managed WordPress-hosts (Kinsta, SiteGround, WP Engine, Cloudways) leveren server-level caching standaard mee. Biedt jouw host dit niet, installeer dan een caching-plugin.

Stel daarnaast een CDN in om gecachte pagina's vanaf edge-locaties dicht bij je bezoekers te serveren. Zie hoe je Cloudflare configureert voor maximale prestaties.

INP aanpakken in WordPress

Interaction to Next Paint meet hoe snel je site reageert op klikken, tikken en toetsaanslagen. WordPress-sites zakken voor INP door een overdaad aan JavaScript op de main thread. De grootste boosdoeners:

Het JavaScript-probleem van plugins

Elke geïnstalleerde plugin kan JavaScript toevoegen die bij elke page load wordt uitgevoerd. Zelfs als een bezoeker een functie nooit aanraakt, concurreert de JavaScript van die feature toch om tijd op de main thread. Klikt een bezoeker op een knop, dan kan de browser pas reageren als de main thread vrij is.

Wees meedogenloos bij het nalopen van je plugins. Vraag je bij elke plugin af: moet dit wel laden op dit type pagina? Gebruik het Coverage-tabblad in Chrome DevTools om te zien hoeveel ongebruikte JavaScript er op elke pagina wordt ingeladen. Gebruik vervolgens een scriptmanager-plugin om specifieke scripts uit te schakelen waar ze niet nodig zijn.

Scriptbeheer in WooCommerce

WooCommerce is een van de grootste veroorzakers van INP-problemen binnen WordPress. Standaard laadt WooCommerce zijn JavaScript en CSS op werkelijk elke pagina, inclusief blogposts en statische pagina's zonder enige shopfunctionaliteit. Gebruik een plugin zoals Disable WooCommerce Bloat of Perfmatters om te voorkomen dat WooCommerce-assets op niet-winkelpagina's laden.

Third-party scripts deferren en uitstellen

Google Analytics, Facebook Pixel, Google Tag Manager, chatwidgets en marketingtools voegen allemaal JavaScript toe die de main thread blokkeert. De meest effectieve strategie is om deze scripts te vertragen tot de eerste interactie van de gebruiker (scrollen, klikken of een toetsaanslag). Zo hebben third-party scripts geen enkele invloed op hoe snel de pagina in eerste instantie reageert.

De functie 'Delay JavaScript Execution' in WP Rocket doet dit automatisch. Je kunt dit ook handmatig inrichten met onze handleiding over JavaScript deferren.

CLS aanpakken in WordPress

Cumulative Layout Shift meet onverwachte verschuivingen van de content. WordPress-sites zakken voor CLS door ontbrekende afmetingen bij afbeeldingen, het wisselen van fonts en dynamisch geïnjecteerde content.

Stel afmetingen in voor afbeeldingen

Elke <img>-tag heeft expliciete width- en height-attributen nodig, zodat de browser al vóór het laden de juiste ruimte kan reserveren. WordPress voegt deze sinds versie 5.5 automatisch toe, maar veel thema's overschrijven dit of gebruiken afwijkende markup zonder afmetingen. Controleer de image-templates van je thema en check of de afmetingen er echt instaan.

Reserveer ruimte voor advertenties en dynamische content

Advertentieblokken, cookiebanners, pop-ups voor nieuwsbrieven en notificatiebalken die pas na de page load verschijnen, zijn de meest voorkomende oorzaken van CLS bij WordPress-sites. Reserveer vooraf vaste ruimte voor deze elementen met min-height in CSS, zodat de omringende content niet verschuift zodra ze in beeld komen.

Voorkom layout shifts door fonts

Zodra een webfont laadt en het fallback-font vervangt, kan de tekst verspringen en omringende elementen wegduwen. De oplossing bestaat uit twee stappen: host je fonts lokaal (zodat de externe DNS-lookup vervalt) en stel in je CSS font-display: optional in of gebruik een nauwkeurig afgestemd fallback-font met de CSS-eigenschap size-adjust. Zelfs als het webfont dan te laat binnenkomt, verschuift de tekst niet. Bekijk onze handleiding voor CLS-optimalisatie voor de volledige aanpak.

WordPress-hosting en Core Web Vitals

Je hostingprovider bepaalt het absolute plafond voor de prestaties van je WordPress-site. Dit is de invloed van de belangrijkste hostingtypen op Core Web Vitals:

Ligt je TTFB structureel boven de 400 ms, dan helpt geen enkele frontend-optimalisatie je aan een goede LCP. Upgrade eerst je hosting. Managed WordPress-hosts zoals SiteGround, Kinsta en Cloudways bieden server-level caching, PHP 8.x en CDN-integratie die de TTFB drastisch omlaag brengen.

CrUX-data bevestigt dat hier het grootste probleem van WordPress ligt: slechts 32% van de WordPress-sites heeft een goede TTFB, vergeleken met fully-hosted platforms zoals Shopify en Wix waar het beheer van de infrastructuur uit handen wordt genomen. Field data uit CoreDash laat exact hetzelfde patroon zien. WordPress-sites op shared hosting noteren gemiddeld een p75 TTFB van 900 ms tot 1400 ms. Verhuis je diezelfde site naar managed hosting met server-level caching, dan daalt dit naar 120 ms tot 250 ms. Die ene verandering tilt de LCP vaak al van 'slecht' naar 'goed', zonder enige andere optimalisatie.

Pagebuilders: prestaties vergeleken

Je keuze voor een pagebuilder (of het weglaten daarvan) is de belangrijkste architectuurbeslissing voor je Core Web Vitals op WordPress. Dit is wat ik telkens weer zie tijdens mijn audits:

Gebruik je al Elementor of Divi en is migreren geen optie? Zet dan de functies 'Optimized DOM Output' en 'Optimized Asset Loading' aan, verwijder ongebruikte widgets en animaties, en zet een caching-plugin zoals WP Rocket in om de extra overhead te compenseren.

Field data uit CoreDash voor WordPress-sites bevestigt dit beeld. Sites gebouwd met Gutenberg en lichte thema's halen op mobiel consistent een mediane LCP onder de 2,0 seconden. Bij Elementor-sites zien we vóór optimalisatie typisch een mediane mobiele LCP van 3,8 tot 5,2 seconden. Dat verschil is bijna volledig toe te schrijven aan extra render-blocking CSS en JavaScript. Na optimalisatie (critical CSS, deferred JS, kleinere DOM) kunnen Elementor-sites 2,0 tot 2,8 seconden halen. Wel vereisen ze continu onderhoud, omdat updates van plugins en de builder vaak opnieuw bloat introduceren.

De checklist voor WordPress Core Web Vitals-optimalisatie

Dit is de systematische aanpak die ik gebruik bij het optimaliseren van WordPress-sites voor Core Web Vitals. Werk deze punten op volgorde af:

Infrastructuur (pak dit als eerste aan)

• Stap over naar managed WordPress-hosting met server-level caching en PHP 8.x
• Configureer een CDN (Cloudflare-handleiding)
• Schakel page caching in (op serverniveau of via WP Rocket / LiteSpeed Cache)
• Activeer GZIP- of Brotli-compressie

Thema en builder

• Stap indien mogelijk over naar een lichtgewicht thema (GeneratePress, Astra, Kadence)
• Gebruik je een pagebuilder, activeer dan de geoptimaliseerde DOM-output en asset-loading
• Verwijder ongebruikte thema-functies, widgets en animaties
• Update de WordPress-core, je thema en alle plugins naar de nieuwste versies

Afbeeldingen

• Preload de LCP-afbeelding met fetchpriority="high"
• Converteer afbeeldingen naar WebP of AVIF met ShortPixel, Imagify of Smush
• Serveer responsive afbeeldingen met de juiste srcset- en sizes-attributen
• Voeg expliciete width- en height-attributen toe aan alle <img>-tags
• Gebruik GEEN lazy loading voor afbeeldingen above the fold (dit schaadt je LCP)

JavaScript en CSS

• Defer niet-kritieke JavaScript
• Stel third-party scripts uit tot interactie van de gebruiker
• Genereer en inline critical CSS
• Verwijder ongebruikte plugin-scripts per pagina met behulp van Perfmatters of Asset CleanUp
• Schakel WooCommerce-assets uit op pagina's buiten de shop

Fonts

• Host Google Fonts lokaal
• Preload kritieke font-bestanden
• Gebruik font-display: swap of optional
• Beperk je tot maximaal 2 font-families

Monitoring

• Stel CoreDash Real User Monitoring in om continu field data te monitoren
• Controleer wekelijks het Core Web Vitals-rapport in Google Search Console
• Test opnieuw na elke update van je thema, plugin of content

Voor de complete cross-platform checklist met alle onderdelen van optimalisatie bekijk je onze Ultimate Core Web Vitals Checklist.

Core Web Vitals meten bij WordPress

WordPress heeft zelf geen ingebouwde rapportage voor Core Web Vitals. Je hebt externe tools nodig om je prestaties te meten:

• Google Search Console: toont welke pagina's over je hele site slagen of zakken, gebaseerd op echte CrUX-field data. Bekijk het rapport 'Core Web Vitals' onder 'Functionaliteit'.
• PageSpeed Insights: test individuele URL's met zowel field data (CrUX) als lab data (Lighthouse). Gebruik dit voor analyses van specifieke pagina's.
• CoreDash: Real User Monitoring die real-time field data levert, uitgesplitst naar pagina, apparaat, land en individuele elementen. Anders dan het voortschrijdend venster van 28 dagen bij CrUX, toont CoreDash direct de impact van je wijzigingen.
• Chrome DevTools: gebruik het Performance-paneel om long tasks op te sporen die INP blokkeren, en het Coverage-tabblad om ongebruikte JavaScript en CSS te vinden.

Voor een complete vergelijking van deze tools bekijk je ons overzicht van Core Web Vitals, inclusief een vergelijkingstabel van meetinstrumenten.

Veelgemaakte fouten bij Core Web Vitals in WordPress

In de honderden WordPress-audits die ik heb uitgevoerd, kom ik deze fouten steeds weer tegen:

• De LCP-afbeelding lazy loaden. WordPress voegt standaard loading="lazy" toe aan afbeeldingen. Is je hero image het LCP-element, dan vertraagt lazy loading de weergave juist. Zorg dat de LCP-afbeelding is uitgesloten van lazy loading en voorzien is van fetchpriority="high".
• Te veel optimalisatie-plugins tegelijk. WP Rocket, Autoptimize, LiteSpeed Cache en W3 Total Cache tegelijkertijd draaien levert geheid conflicten op. Kies één goede caching- en optimalisatie-plugin en configureer die goed.
• Field data negeren. Een Lighthouse-score van 95 betekent niet automatisch dat je slaagt voor Core Web Vitals. Google kijkt naar field data van echte bezoekers. Jouw echte bezoekers op echte apparaten ervaren de site vaak heel anders. Controleer altijd Search Console of gebruik RUM.
• Niet meer testen na updates. Een update van een thema of plugin kan je Core Web Vitals ongemerkt weer om zeep helpen. Blijf continu monitoren, niet alleen direct na de initiële optimalisatie.