Je bezoeker landt op je WordPress-homepage en wacht. De server start PHP op, voert zeventien keer een databasequery uit, voert themafuncties uit, laadt plugin hooks, rendert het DOM en toont eindelijk tekst — 2,8 seconden na het klikken. Je hebt al drie cache-plugins geïnstalleerd. Je LCP ligt nog steeds op 3,1 seconden, je CLS schuift de layout heen en weer terwijl lettertypen worden ingeladen, en Google Search Console geeft blijvend dezelfde Core Web Vitals-fouten aan. Het probleem zit niet in je hosting of je CDN. WordPress is in 2003 ontworpen om blogposts met server-side PHP op elk verzoek te renderen. Twee decennia later vraag je dezelfde runtime om marketingsites, e-commerce-platformen en web-apps uit te voeren — terwijl Googles Core Web Vitals-algoritme bepaalt of iemand je content überhaupt vindt. Geen plugin kan het executiemodel herschrijven, maar een Next.js-migratie kan dat wel. Hier is de technische uiteenzetting van wat eraan scheelt en de exacte patronen die het repareren.

Dit artikel legt precies uit waarom WordPress-sites traag zijn, koppelt elk probleem aan de Core Web Vitals-metriek die eronder lijdt, en laat je zien hoe een headless Next.js-architectuur alles vanaf de grond af oplost. Niet met pleister. Vanaf de grond af.

Inhoudsopgave

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

Core Web Vitals in 2026 begrijpen

Google heeft zijn Core Web Vitals in maart 2024 bijgewerkt, waarbij First Input Delay (FID) is vervangen door Interaction to Next Paint (INP). Deze verandering is belangrijker dan veel mensen beseffen. Hier zijn de vier metriek die je siteprestatie bepalen:

Metriek Wat het meet Goed Moet beter 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 laden ≤ 0,1 0,1 – 0,25 > 0,25
TTFB (Time to First Byte) Serverresponstijd ≤ 800ms 800ms – 1800ms > 1800ms

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

Waarom deze metriek eigenlijk uitmaken

Google is duidelijk: Core Web Vitals zijn een rankingfactor. Maar voorbij SEO correleren deze metriek rechtstreeks met conversiepercentages. Vodafone ontdekte dat een 31% verbetering in LCP leidde tot een 8% stijging in verkopen. Shopifys interne data toont aan dat elke 100ms verlaging in paginalaadtijd de conversie met 1,3% verhoogt.

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

Waarom WordPress architectonisch traag is

Laat ik je stap voor stap laten zien wat er gebeurt wanneer iemand een typische WordPress-pagina bezoekt:

  1. DNS-lookup → lost je domein op
  2. TCP/TLS-handshake → brengt beveiligde verbinding tot stand
  3. Verzoek raakt de server → Apache/Nginx ontvangt het
  4. PHP start WordPress op → laadt wp-config.php, initialiseert de WordPress-kern
  5. Plugin-initialisatie → elke actieve plugin haait zich in init, wp_loaded, enzovoort
  6. Thema laadt → functions.php wordt uitgevoerd, template-hiërarchie wordt opgelost
  7. Databasequeries uitvoeren → WP_Query wordt uitgevoerd, vaak 30-100+ queries per pagina
  8. PHP rendert HTML → template-bestanden genereren de volledige pagina
  9. HTML naar browser verzonden → eindelijk begint het antwoord
  10. Browser parseert HTML → ontdekt CSS, JS, lettertypen, afbeeldingen
  11. Render-blocking resources laden → stylesheets van 15 verschillende plugins
  12. Pagina rendert eindelijk → gebruiker ziet inhoud

Stappen 4 tot en met 9 gebeuren op elke uncached-aanvraag. Dat is PHP die meer dan 200 bestanden parseert, tientallen databasequeries uitvoert en HTML genereert — allemaal voordat de browser ook maar één byte krijgt.

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 synchroon, blokerend 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.

Hier is het ding: cache-plugins zoals WP Super Cache of W3 Total Cache werken door dit proces in te korten — ze serveren een vooraf gegenereerd HTML-bestand in plaats daarvan. Maar ze introduceren hun eigen complexiteit, breken met gepersonaliseerde inhoud, en kunnen nog steeds niet repareren wat in de browser gebeurt.

Het Thema-probleem

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

<!-- Typisch WordPress-hoofd op een pagina-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">
<!-- ... 12 stylesheets verder -->

Elk ervan is een render-blocking resource. Je LCP kan niet gebeuren totdat al deze zijn gedownload en geparseerd.

Plugin-rommel: de stille performance-killer

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

  • Zijn eigen CSS- en JS-bestanden toevoegen (vaak op elke pagina, zelfs waar ongebruikt)
  • WordPress-hooks registreren die op elke aanvraag worden uitgevoerd
  • Zijn eigen databasequeries uitvoeren
  • Zijn eigen PHP-bestanden laden tijdens de bootfase
  • Inline scripts en stijlen toevoegen aan de <head>

Een echt voorbeeld

Ik heb onlangs een marketingsite gecontroleerd met 34 actieve plugins. Hier is hoe 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 cache-plugin (LiteSpeed Cache) geïnstalleerd. Zelfs met beide actief, was LCP 4,2 seconden. Nog steeds faalt.

Het kernprobleem? Je kunt niet optimaliseren wegwerken van het fundamentele probleem van het laden van code die je niet nodig hebt. Het minifyen en combineren van 47 CSS-bestanden laat je nog steeds met een massieve CSS-payload die rendering blokkeert.

De plugin-afhankelijkheidsvalkuil

Hier is wat het nog erger maakt: plugins hangen van andere plugins af. Je installeert WooCommerce, dan heb je een betalingsgateway-plugin nodig, dan een verzendcalculator-plugin, dan een productfilter-plugin. Elk ervan voegt gewicht toe. Je kunt geen enkele verwijderen zonder functionaliteit te breken.

Dit is de WordPress-valkuil. De architectuur stimuleert het toevoegen van plugins voor alles, en er is geen mechanisme om ongebruikte code uit te schudden.

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

Databasequery-problemen die plugins niet kunnen repareren

WordPress gebruikt één MySQL-database met een notoir vlak schema. De wp_options-tabel is geladen met autoload='yes'-items op elke aanvraag. Ik heb wp_options-tabellen gezien met meer dan 3.000 autoloaded rijen totaal 8MB gegevens.

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

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

De wp_postmeta-tabel is een ander nachtmerrie. Het slaat alles op als sleutel-waarde-paren, wat betekent dat WordPress geen efficiënte queries kan uitvoeren. Wil je alle producten onder €50 vinden? Dat is een JOIN op wp_postmeta met een tekensvergelijking op een tekstveld dat een getal opslaat. Geen index kan je redden.

Queryaantal realiteitscheck

Installeer de Query Monitor-plugin op je WordPress-site en kijk naar het aantal queries. Een "eenvoudige" WooCommerce-productpagina voert meestal 150-300 databasequeries uit. Een blogbericht met gerelateerde berichten, populaire berichten-zijbalk en kruimelpad? Gewoonlijk 80-120 queries.

Vergelijk dat met een headless-aanpak waarbij je Next.js-frontend exact één API-aanroep doet (of nul, als je statische generatie gebruikt) om alle gegevens die het nodig heeft op te halen.

WordPress-hosting: je betaalt waarschijnlijk teveel voor middelmatigheid

Laat me over hosting spreken, want dit is waar veel geld wordt verspild.

Hostingtype Maandelijkse kosten Typische TTFB Kan architectuur repareren?
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 reparaert de architectuurproblemen. Je betaalt premiumprijs om PHP sneller te laten draaien, terwijl de echte oplossing is om helemaal niet op elke aanvraag PHP uit te voeren.

Kinsta vraagt $35/maand voor hun starterplan met 25.000 bezoeken. Vercels gratis tier verwerkt 100GB bandbreedte. Zelfs Vercels Pro-plan van $20/maand geeft je edge-implementatie over hun globale CDN. De wiskunde liegt niet.

Hoe Next.js elke Core Web Vital oplost

Laat ik specifiek worden. Hier is hoe Next.js (vooral met de App Router in Next.js 14/15) elke metriek aanpakt:

TTFB repareren

Next.js geeft je meerdere renderingstrategieën:

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

// Dit pre-rendert bij builden
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Met statische generatie worden je pagina's vooraf gebouwd als HTML-bestanden geserveerd vanaf edge CDN-knooppunten over de hele wereld. TTFB daalt naar 50-100ms ongeacht waar je gebruikers zich bevinden. Geen PHP-uitvoering, geen databasequeries, geen server-side verwerking op aanvraagmoment.

Voor dynamische inhoud ondersteunt Next.js ISR (Incremental Static Regeneration), die gecachede statische pagina's serveerzt terwijl op de achtergrond opnieuw wordt gevalideerd:

// Elke 60 seconden opnieuw valideren
export const revalidate = 60;

LCP repareren

Next.js bevat het <Image>-component dat alles afhandelt wat WordPress-plugins proberen (en falen) te doen:

import Image from 'next/image';

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

De priority-prop vertelt Next.js om de afbeelding voor te laden, wat LCP rechtstreeks verbetert. De automatische formatonderhandeling serveerrt WebP of AVIF aan ondersteunde browsers, wat afbeeldingsgrootte met 30-50% vermindert ten opzichte van JPEG. Geen plugin nodig.

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

INP repareren

INP meet hoe snel je site op gebruikersinteracties reageert. WordPress-sites falen INP omdat van:

  • Zware JavaScript van plugins die de hoofdthread blokkeren
  • jQuery en zijn plugins die om executietijd strijden
  • Geen codesplitting — alles laadt vooraf

Next.js handelt dit af met automatische codesplitting. Elke pagina laadt alleen de JavaScript die ze nodig heeft:

// Dit 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 componentJavaScript.

CLS repareren

CLS in WordPress komt meestal van:

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

Next.js voorkomt CLS standaard. Het <Image>-component vereist afmetingen (of gebruikt fill met een gegrootte container). De next/font-module voegt lettertypdeclaraties in en gebruikt font-display: swap zonder layoutverschuiving:

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

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

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

Geen FOUT. Geen layoutverschuiving door lettertypen. Het werkt gewoon.

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

Hier is het gedeelte dat veel mensen missen: headless gaan betekent niet dat je WordPress verlaat. Het betekent WordPress gebruiken voor wat het eigenlijk goed kan — inhoudsbeheer — terwijl je Next.js de frontend laat behandelen.

De architectuur ziet er als volgt uit:

[WordPress Admin] → [REST API / WPGraphQL] → [Next.js Frontend] → [Vercel Edge CDN]
     ↑                                              ↑
  Content-editors                              Je gebruikers
  gebruiken het bekende                        krijgen snelle pagina's
  WP-dashboard                                 geserveerd van edge

Je content-team houdt zijn workflow. Je gebruikers krijgen een snelle site. Je krijgt schone, onderhoudbare code.

Wij doen veel van dit soort werk in onze Next.js-ontwikkelingspraktijk en headless CMS-ontwikkeling. Het patroon is goed gevestigd en gevechtstesterd.

Wat dacht je van andere headless CMS-opties?

WordPress is niet de enige optie voor de inhoudslaag. Als je van nul begint, purpose-built headless CMS-platformen zoals Sanity, Contentful of Storyblok zijn vaak betere keuzes. Ze zijn API-first gebouwd, dus er is geen erfenisbagasse.

Maar als je jaren inhoud in WordPress hebt en een team dat ermee is getraind, is headless WordPress met WPGraphQL een volkomen geldige aanpak.

Echte performance-benchmarks: WordPress versus Next.js

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

Metriek 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 Dag en nacht

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

Migratiepad: van monolithisch WordPress naar headless Next.js

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

Fase 1: Beoordeling (1-2 weken)

  • Controleer huidige WordPress-siteprestatie met PageSpeed Insights en CrUX-gegevens
  • Inventariseer alle plugins en wijs deze toe aan frontend versus backend-functionaliteit
  • Identificeer inhoudsmodellen en aangepaste velden
  • Evalueer of je WordPress als headless CMS wilt behouden of inhoud volledig wilt migreren

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

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

Fase 3: Launch en doorverwijzing (1-2 weken)

  • Deploy Next.js-frontend naar Vercel (of Netlify, of Cloudflare Pages)
  • Configureer DNS en omleidingen
  • Verifieer dat alle URL's correct worden omgeleid (SEO-behoud is essentieel)
  • Vergrendel WordPress-admin (verwijder public-facing toegang)

Fase 4: Optimalisatie (lopend)

  • Monitor Core Web Vitals in Google Search Console
  • Fine-tune ISR-revalidatie-intervallen
  • Voeg edge middleware toe voor personalisatie
  • Overweeg migratie naar een purpose-built headless CMS als WordPress een bottleneck wordt

Als je dit soort migratie overweegt, kun je ons prijzenpagina controleren voor ballparkgetallen, of rechtstreeks contact opnemen om je specifieke situatie te bespreken.

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

Veelgestelde vragen

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

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

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

Verliezen content-editors het WordPress-admin als we headless gaan? Nee. In een headless-installatie blijft WordPress dienen als de inhoudsbeheersserver. Editors gebruiken hetzelfde dashboard, dezelfde editor, dezelfde workflow. Ze zien alleen de frontend-thema niet meer — in plaats daarvan gebruiken ze een voorbeeldknop die de Next.js-gerenderde versie toont. Sommige teams vinden dit eigenlijk beter omdat het voorbeeld een nauwkeurige weergave van de productiesite is.

Wat dacht je van WooCommerce — kan Next.js e-commerce aan? Ja, maar het is een groter project. Je kunt WooCommerce headless gebruiken via zijn REST API of WPGraphQL WooCommerce-extensie. Als alternatief migreren veel teams naar Shopifys Storefront API of Saleor voor de commerceserver, met Next.js als frontend. De checkout-stroom vereist voorzichtig omgang omdat het betalingsverwerking en PCI-naleving inhoudt. Het is haalbaar, maar plan voor extra ontwikkelingstijd.

Is Next.js de enige optie voor een snelle frontend? Nee. Astro, Remix, SvelteKit en zelfs Nuxt (voor Vue-teams) zijn allemaal levensvatbaar. Astro in het bijzonder is uitstekend voor content-zware sites omdat het standaard nul JavaScript verzendt. 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, vuurt een webhook af en vertelt je Next.js-implementatie dat specifieke pagina opnieuw moet valideren. De volgende bezoeker krijgt een vers gegenereerde statische pagina, die vervolgens in de cache aan de edge wordt opgeslagen. De revalidatie gebeurt op de achtergrond, dus gebruikers wachten nooit op een build. Je kunt ook op tijd gebaseerde revalidatie instellen (bijv. elke 60 seconden opnieuw bouwen) als terugval.

Wat is de grootste fout die teams maken bij headless-implementatie? Probeert hun WordPress-site 1:1 in Next.js te repliceren. Een headless-migratie is een gelegenheid om je inhoudsarchitectuur opnieuw te overdenken, je paginastructuren te vereenvoudigen en jaren opgehoopte rommel uit te bannen. Teams die het als een frisse start behandelen — inhoud behouden maar presentatie heroverwegen — eindigen met dramatisch betere resultaten dan teams die elk widget en zijbalk van hun oude thema proberen te kopiëren.