Ik heb honderden WordPress-sites gecontroleerd over de jaren, en het gesprek begint meestal op dezelfde manier: "We hebben een caching-plugin geïnstalleerd, maar onze scores zijn nog steeds verschrikkelijk." De waarheid die niemand in het WordPress-ecosysteem graag wil toegeven, is dat de meeste prestatieproblemen niet oplosbaar zijn met plugins. Ze zijn architecturaal. WordPress is in 2003 gebouwd om blogberichten met PHP weer te geven. Het is 2025, en we vragen het om complexe marketingsites, e-commerce-platforms en webtoepassingen aan te drijven — terwijl Googles Core Web Vitals steeds meer bepalen of iemand je content überhaupt vindt.

Dit artikel legt uit waarom WordPress-sites traag zijn, wijst elk probleem toe aan de Core Web Vitals-metrics die ervan lijden, en laat zien hoe een headless Next.js-architectuur ze aan de wortel oplost. Niet met pleistertjes. Aan de wortel.

Inhoudsopgave

Waarom je WordPress-site traag is en hoe Next.js het oplost

Core Web Vitals begrijpen in 2025

Google heeft zijn Core Web Vitals in maart 2024 bijgewerkt en First Input Delay (FID) vervangen door Interaction to Next Paint (INP). Deze verandering is belangrijker dan de meeste mensen beseffen. Hier zijn de vier metrics die het prestatiecijfer van je site bepalen:

Metric Wat het meet Goed Verbetering nodig Slecht
LCP (Largest Contentful Paint) Hoe snel je hoofdinhoud laadt ≤ 2,5s 2,5s – 4,0s > 4,0s
INP (Interaction to Next Paint) Responsiviteit op gebruikersinvoer ≤ 200ms 200ms – 500ms > 500ms
CLS (Cumulative Layout Shift) Visuele stabiliteit tijdens het laden ≤ 0,1 0,1 – 0,25 > 0,25
TTFB (Time to First Byte) Serverresponsetijd ≤ 800ms 800ms – 1800ms > 1800ms

Volgens het Chrome UX Report van begin 2025 slaagt slechts 42% van WordPress-origins voor alle drie de Core Web Vitals-drempels. Vergelijk dat met 67% voor origins aangedreven door Next.js. Dat is geen marginaal verschil — het is een ander niveau.

Waarom deze metrics eigenlijk belangrijk zijn

Google is duidelijk: Core Web Vitals zijn een rangsignaal. Maar verder correleren deze metrics rechtstreeks met conversiepercentages. Vodafone ontdekte dat een verbetering van 31% in LCP leidde tot een stijging van 8% in verkopen. Shopifys interne gegevens tonen aan dat elke 100ms-reductie in paginaladtijd de conversie met 1,3% verhoogt.

Je WordPress-site is niet alleen traag. Het kost je geld.

Waarom WordPress architecturaal traag is

Laat me je door stap voor stap walkthrough gaan wat er gebeurt wanneer iemand een typische WordPress-pagina bezoekt:

  1. DNS-opzoeking → lost je domein op
  2. TCP/TLS-handshake → brengt veilige verbinding tot stand
  3. Verzoek bereikt de server → Apache/Nginx ontvangt het
  4. PHP bootstrapt WordPress → laadt wp-config.php, initialiseert de WordPress-kern
  5. Plugin-initialisatie → elke actieve plugin haakt zich in op init, wp_loaded, enz.
  6. Thema laadt → functions.php wordt uitgevoerd, sjabloonhiërarchie wordt opgelost
  7. Databasequery's worden uitgevoerd → WP_Query loopt, vaak 30-100+ query's per pagina
  8. PHP genereert HTML → sjabloonbestanden genereren de volledige pagina
  9. HTML naar browser verzonden → eindelijk begint het antwoord
  10. Browser parseert HTML → ontdekt CSS, JS, fonts, afbeeldingen
  11. Render-blokkerende bronnen laden → stylesheets van 15 verschillende plugins
  12. Pagina wordt uiteindelijk weergegeven → gebruiker ziet inhoud

Stap 4 tot en met 9 gebeuren op elke ongebufferde aanvraag. Dat is PHP dat 200+ bestanden parseert, tientallen databasequery's uitvoert en HTML genereert — alles voordat de browser een enkel byte ontvangt.

Het PHP-probleem

PHP 8.3 is aanzienlijk sneller dan PHP 7.x, en de meeste WordPress-hosts ondersteunen het nu. Maar zelfs met PHP 8.3 en OPcache ingeschakeld, voer je nog steeds een synchrone, blokkerende proces uit. WordPress-kern alleen laadt ongeveer 100.000 regels PHP-code op elke aanvraag. Voeg WooCommerce toe en je bent voorbij 400.000 regels.

Dit is het belangrijke punt: caching-plugins zoals WP Super Cache of W3 Total Cache werken door dit proces kortsluiting — ze serveren in plaats daarvan een vooraf gegenereerd HTML-bestand. Maar ze introduceren hun eigen complexiteit, breken met gepersonaliseerde inhoud, en kunnen nog steeds niet oplossen wat er in de browser gebeurt.

Het theme-probleem

De meeste WordPress-thema's zijn gebouwd voor flexibiliteit, niet voor prestatie. Een thema zoals Avada, Divi of Elementor laadt zijn volledige CSS- en JavaScript-framework op elke pagina, of je die functies nu gebruikt of niet. Ik heb Elementor-sites gezien die 2,5MB CSS en 1,8MB JavaScript op een eenvoudig blogbericht laden.

<!-- Typische WordPress head op een page-builder site -->
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor-pro/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/theme.min.css">
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... nog 12 stylesheets -->

Elk van die is een render-blokkerende bron. Je LCP kan niet gebeuren totdat ze allemaal zijn gedownload en geparseerd.

Plugin-ballast: de stille prestatiemoordenaar

De gemiddelde WordPress-site voert 20-30 plugins uit. Ik heb sites met 70+ gezien. Elke plugin kan:

  • Zijn eigen CSS- en JS-bestanden toevoegen (vaak op elke pagina, zelfs waar niet gebruikt)
  • WordPress-hooks registreren die op elke aanvraag worden uitgevoerd
  • Zijn eigen databasequery's uitvoeren
  • Zijn eigen PHP-bestanden laden tijdens de bootstrap-fase
  • Inline scripts en stijlen aan de <head> toevoegen

Een echt voorbeeld

Ik controleerde onlangs een marketingsite met WordPress met 34 actieve plugins. Hier is wat de netwerkwaterval eruitzag:

  • 47 CSS-bestanden geladen op de homepage
  • 38 JavaScript-bestanden geladen op de homepage
  • Totaal paginagewicht: 4,7MB
  • Totale aanvragen: 127
  • LCP: 6,8 seconden op 4G
  • TTFB: 2,1 seconden

De klant had al een optimalisatieplugin (Autoptimize) en een caching-plugin (LiteSpeed Cache) geïnstalleerd. Zelfs met beide actief, was LCP 4,2 seconden. Nog steeds niet haalbaarbaar.

Het kernprobleem? Je kunt niet optimaliseren weg van het fundamentele probleem van het laden van code die je niet nodig hebt. Minificatie en combinatie van 47 CSS-bestanden leidt nog steeds tot een enorme CSS-payload die rendering blokkeert.

De plugin-afhankelijkheidsvalkuil

Hier wordt het erger: plugins zijn afhankelijk van andere plugins. Je installeert WooCommerce, dan heb je een betalingsgatewayplugin nodig, dan een verzendcalculatorplugin, dan een productfilterplugin. Elk voegt gewicht toe. Je kunt geen van hen verwijderen zonder functionaliteit te breken.

Dit is de WordPress-valkuil. De architectuur moedigt aan om plugins voor alles toe te voegen, en er is geen mechanisme om ongebruikte code weg te schudden.

Waarom je WordPress-site traag is en hoe Next.js het oplost - architectuur

Databaseproblemen die plugins niet kunnen oplossen

WordPress gebruikt een enkele MySQL-database met een notoir vlak schema. De tabel wp_options wordt bij elke aanvraag geladen met autoload='yes'-ingangen. Ik heb wp_options-tabellen gezien met 3.000+ autoloaded rijen totaal 8MB aan gegevens.

-- Controleer de autoloaded optionsgrootte
SELECT SUM(LENGTH(option_value)) as autoload_size 
FROM wp_options 
WHERE autoload = 'yes';

-- Als dit > 1MB retourneert, heb je een probleem

De tabel wp_postmeta is nog een nachtmerrie. Het slaat alles op als sleutel-waardeparen, wat betekent dat WordPress geen efficiënte query's kan doen. Wil je alle producten onder €50 vinden? Dat is een JOIN op wp_postmeta met een stringvergelijking op een tekstveld dat een getal opslaat. Geen index kan je redden.

Reality check aantal query's

Installeer de Query Monitor-plugin op je WordPress-site en kijk naar het aantal query's. Een "eenvoudige" WooCommerce-productpagina voert doorgaans 150-300 databasequery's uit. Een blogbericht met gerelateerde berichten, populaire berichten-zijbalk en broodkruimels? Meestal 80-120 query's.

Vergelijk dat met een headless-benadering waarbij je Next.js-frontend precies één API-aanroep maakt (of nul, bij statische generatie) om alle benodigde gegevens te krijgen.

WordPress Hosting: je betaalt waarschijnlijk teveel voor middelmatigheid

Laten we het over hosting hebben, want dit is waar veel geld wordt verspild.

Hostingtype Maandelijkse kosten Typische TTFB Kan architectuur opfixen?
Gedeeld (GoDaddy, Bluehost) €3-15 1,5-4,0s Nee
Beheerde WordPress (WP Engine, Flywheel) €25-300 400ms-1,2s Nee
Premium beheerd (Kinsta, Pagely) €35-600 200ms-600ms Nee
VPS/Dedicated (DigitalOcean, AWS) €20-500 200ms-800ms Nee
Next.js op Vercel/Edge €0-20 50-150ms Ja

Merk op die laatste kolom. Geen hostingupgrade oplost de architecturale problemen. Je betaalt premiumtarieven om PHP sneller te laten draaien, terwijl de echte oplossing is om helemaal niet PHP op elke aanvraag uit te voeren.

Kinsta rekent €35/maand voor hun startplan met 25.000 bezoeken. Vercel's gratis tier verwerkt 100GB bandbreedte. Zelfs Vercel's Pro-plan op €20/maand geeft je edge-implementatie over hun globale CDN. De getallen liegen niet.

Hoe Next.js elke Core Web Vital oplost

Laten we specifiek worden. Hier is hoe Next.js (vooral met de App Router in Next.js 14/15) elke metric aanpakt:

TTFB repareren

Next.js geeft je meerdere renderingstrategieën:

// Statische generatie - TTFB praktisch nul (geserveerd vanuit CDN)
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  return <Article post={post} />;
}

// Dit genereert vooraf op buildtijd
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Bij statische generatie worden je pagina's vooraf opgebouwde HTML-bestanden die vanuit edge CDN-nodes wereldwijd worden geserveerd. TTFB daalt naar 50-100ms ongeacht waar je gebruikers zijn. Geen PHP-uitvoering, geen databasequery's, geen server-side processing op aanvraagtijd.

Voor dynamische inhoud ondersteunt Next.js ISR (Incremental Static Regeneration), dat gecachte statische pagina's serveert terwijl het op de achtergrond opnieuw genereert:

// Opnieuw valideren elke 60 seconden
export const revalidate = 60;

LCP repareren

Next.js bevat de component <Image> die alles verwerkt wat WordPress-plugins proberen (en niet) te doen:

import Image from 'next/image';

export default function HeroBanner() {
  return (
    <Image
      src="/hero.jpg"
      alt="Hero banner"
      width={1200}
      height={600}
      priority // Preload de LCP-afbeelding
      sizes="100vw"
      // Genereert automatisch srcset, gebruikt WebP/AVIF,
      // laadt lui standaard, voorkomt CLS
    />
  );
}

De prop priority vertelt Next.js de afbeelding voor te laden, wat LCP rechtstreeks verbetert. De automatische formaatonderhandeling serveert WebP of AVIF aan ondersteunde browsers, wat afbeeldingsgrootte met 30-50% reduceert in vergelijking met JPEG. Geen plugin nodig.

Next.js elimineert ook render-blokkerende CSS via CSS Modules en automatische critical CSS-extractie. Alleen de CSS die op een specifieke pagina wordt gebruikt, wordt geladen.

INP repareren

INP meet hoe snel je site reageert op gebruikersinteracties. WordPress-sites mislukken INP vanwege:

  • Zwaar JavaScript van plugins dat de main thread blokkeert
  • jQuery en zijn plugins concurreren om uitvoeringstijd
  • Geen codesplitsing — alles laadt vooraf

Next.js verwerkt dit met automatische codesplitsing. Elke pagina laadt alleen het JavaScript dat het nodig heeft:

// Deze component laadt alleen wanneer de gebruiker ernaar scrollt
import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
  loading: () => <ChartSkeleton />,
  ssr: false, // Render niet op server
});

React Server Components (standaard in de App Router) gaan nog verder: componenten die geen interactiviteit nodig hebben, sturen nul JavaScript naar de browser. Een blogbericht zonder interactieve elementen? Nul KB componentenJavaScript.

CLS repareren

CLS in WordPress komt meestal van:

  • Afbeeldingen zonder expliciete afmetingen
  • Advertenties die laat laden en inhoud naar beneden duwen
  • Webfonts die FOUT/FOIT veroorzaken
  • Door plugins geïnjecteerde banners die na laden verschijnen

Next.js voorkomt CLS standaard. De component <Image> vereist afmetingen (of gebruikt fill met een geschilderde container). De module next/font zet fontverklaringen inline en gebruikt font-display: swap zonder layout shift:

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'] });

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

Geen FOUT. Geen layout shift van fonts. Het werkt gewoon.

De Headless-architectuur: WordPress als CMS, Next.js als frontend

Hier is het deel dat veel mensen missen: headless gaan betekent niet WordPress abandoneren. Het betekent WordPress gebruiken voor wat het eigenlijk goed kan — content management — terwijl Next.js het frontend afhandelt.

De architectuur ziet er als volgt uit:

[WordPress Admin] → [REST API / WPGraphQL] → [Next.js Frontend] → [Vercel Edge CDN]
     ↑                                              ↑
  Content editors                              Jouw gebruikers
  gebruiken de vertrouwde                      krijgen snelle pagina's
  WP-dashboard                                 geserveerd vanuit edge

Je contentteam behoudt hun workflow. Je gebruikers krijgen een snelle site. Je krijgt schone, onderhoudbare code.

We doen veel van dit soort werk in onze Next.js-ontwikkelingspraktijk en headless CMS-ontwikkeling. Het patroon is goed ingeburgerd en battle-getest.

Wat doen andere headless CMS-opties?

WordPress is niet de enige optie voor de inhoudlaag. Als je opnieuw begint, zijn specifiek gebouwde headless CMS-platforms zoals Sanity, Contentful of Storyblok vaak betere keuzes. Ze zijn API-first gebouwd, dus er is geen erfenislast.

Maar als je jaren inhoud in WordPress hebt en een team dat erop is getraind, is headless WordPress met WPGraphQL een perfect valide benadering.

Echte prestatiebanken: WordPress vs. Next.js

Hier zijn echte nummers van migraties die we hebben gedaan en publiek beschikbare casestudies:

Metric WordPress (geoptimaliseerd) Next.js (Statisch) Verbetering
TTFB 650ms 80ms 87% sneller
LCP 3,8s 1,2s 68% sneller
INP 380ms 90ms 76% sneller
CLS 0,18 0,01 94% beter
Paginagewicht 3,2MB 450KB 86% lichter
Aanvragen 85 12 86% minder
Lighthouse-score 45-65 95-100 Nacht en dag

"Geoptimaliseerd" WordPress betekent: PHP 8.3, Redis-objectcache, CDN, afbeeldingsoptimalisatieplugin, caching-plugin, databaseoptimalisatie. Al de dingen die je moet doen. En het is nog steeds niet in de buurt.

Migratiepad: van monolithische WordPress naar headless Next.js

Migratie hoeft niet alles-of-niets te zijn. Hier is de gefaseerde benadering die we doorgaans aanbevelen:

Fase 1: Evaluatie (1-2 weken)

  • Huidigte WordPress-siteprestaties controleren met PageSpeed Insights en CrUX-gegevens
  • Inventariseer alle plugins en wijs ze toe aan frontend vs. backend-functionaliteit
  • Identificeer inhoudsmodellen en aangepaste velden
  • Beoordeel of je WordPress als headless CMS wilt behouden of inhoud volledig wilt migreren

Fase 2: Frontend-bouw (4-8 weken)

  • Stel Next.js-project in met de App Router
  • Installeer en configureer WPGraphQL op WordPress
  • Bouw componentbibliotheek die overeenkomt met huidigte ontwerp (of herontwerp — goed moment)
  • Implementeer statische generatie voor inhoudspagina's
  • Stel preview-modus in voor content-editors

Fase 3: Lancering en omleiding (1-2 weken)

  • Implementeer Next.js-frontend op Vercel (of Netlify, of Cloudflare Pages)
  • Configureer DNS en omleidingen
  • Controleer of alle URL's correct zijn omgeleid (SEO-behoud is kritiek)
  • Vergrendel WordPress-admin (verwijder openbare toegang)

Fase 4: Optimalisatie (doorlopend)

  • Controleer Core Web Vitals in Google Search Console
  • Fijn-afstelling ISR-revalidatie-intervallen
  • Voeg edge-middleware toe voor personalisatie
  • Overweeg migratie naar een specifiek gebouwde headless CMS als WordPress een bottleneck wordt

Als je een dergelijke migratie overweegt, kun je onze prijzingspagina voor ballparcijfers controleren, of rechtstreeks contact opnemen om je specifieke situatie te bespreken.

Voor sites gebouwd met Astro in plaats van Next.js (vooral content-zware blogs en marketingsites), hebben we ook een Astro-ontwikkelingspraktijk die nog agressievere prestaties levert voor statische-first-sites.

FAQ

Kan ik WordPress sneller maken zonder over te stappen naar Next.js? Ja, tot op zekere hoogte. Begin met een kwaliteitshost (Kinsta of Cloudways), zet Redis-objectcaching in, gebruik een licht thema zoals GeneratePress, reduceer plugins tot onder 15, en configureer een CDN. Je kunt op deze manier een WordPress-site in het "verbetering nodig" bereik voor Core Web Vitals krijgen. Maar consistent breken in het "goed" bereik voor alle metrics — vooral INP — is extreem moeilijk met een traditionele WordPress-architectuur.

Hoeveel kost het om van WordPress naar headless Next.js te migreren? Dit hangt af van de complexiteit van de site. Een eenvoudige marketingsite (10-30 pagina's, blog) kost doorgaans €15.000-€40.000 voor een volledige migratie. E-commerce-sites met WooCommerce zijn complexer, variëren van €50.000-€150.000+. De ROI komt meestal uit verbeterde conversiepercentages en gereduceerde hostingkosten. Onze prijzingspagina heeft meer details.

Zullen mijn SEO-rankings dalen als ik naar Next.js switch? Niet als je de migratie correct afhandelt. Juiste 301-omleidingen, identieke URL-structuren (of gemapte omleidingen), geldige metatags, gestructureerde gegevens en een XML-sitemap zijn allemaal essentieel. Next.js heeft eigenlijk SEO-voordelen — snellere Core Web Vitals verbeteren rangschikkingen rechtstreeks, en de Metadata API maakt het gemakkelijk om metatags programmatisch te beheren. De meeste sites zien rangschikkingsverbeteringen binnen 2-3 maanden na migratie.

Verliezen content-editors het WordPress-admin als we headless gaan? Nee. In een headless-setup fungeert WordPress als de beheerde inhoudachterkant. Editors gebruiken hetzelfde dashboard, dezelfde editor, dezelfde workflow. Ze zien alleen het frontend-thema niet meer — in plaats daarvan gebruiken ze een preview-knop die de Next.js-weergegeven versie toont. Sommige teams vinden dit eigenlijk beter omdat de preview een nauwkeurige weergave van de productiesite is.

Wat doen WooCommerce — kan Next.js e-commerce afhandelen? Ja, maar het is een groter project. Je kunt WooCommerce headless gebruiken via zijn REST API of WPGraphQL WooCommerce-extensie. Alternatief migreren veel teams naar de Shopify Storefront API of Saleor voor de commerce-backend, gebruikmakend van Next.js als frontend. De checkoutflow vereist voorzichtige afhandeling omdat het betalingsverwerking en PCI-compliance omvat. Het is haalbaar, maar plan extra ontwikkelingstijd.

Is Next.js de enige optie voor een snelle frontend? Nee. Astro, Remix, SvelteKit en zelfs Nuxt (voor Vue-teams) zijn allemaal lebendig. Astro is vooral uitstekend voor inhoudszware sites omdat het standaard nul JavaScript verstuurt. Next.js wint voor sites die aanzienlijke interactiviteit, dynamische functies of e-commerce nodig hebben. We werken met zowel Next.js als Astro, afhankelijk van de projectbehoeften.

Hoe werkt Incremental Static Regeneration (ISR) met WordPress-inhoud? Wanneer je een bericht in WordPress publiceert of bijwerkt, wordt een webhook geactiveerd en vertelt je Next.js-implementatie om die specifieke pagina opnieuw te valideren. De volgende bezoeker krijgt een vers gegenereerde statische pagina, die vervolgens aan de edge in cache wordt opgeslagen. De revalidatie gebeurt op de achtergrond, dus gebruikers wachten nooit op een build. Je kunt ook tijd-gebaseerde revalidatie instellen (bijvoorbeeld elke 60 seconden opnieuw opbouwen) als fallback.

Wat is de grootste fout die teams maken wanneer ze headless gaan? Proberen hun WordPress-site 1:1 in Next.js te repliceren. Een headless-migratie is een mogelijkheid om je inhoudsarchitectuur opnieuw door te denken, je paginastructuren te vereenvoudigen en jaren verzamelde troep uit te verwijderen. Teams die het als een frisse start behandelen — inhoud behouden maar presentatie heroverwegen — eindigen met dramatisch betere resultaten dan teams die proberen elk widget en zijbalk van hun oud thema te kopiëren.