Een trage WordPress-site is wat een bezoeker ervaart in de eerste paar seconden nadat hij op een link klikt. De hero-afbeelding komt te laat in beeld, de pagina springt nog rond terwijl fonts laden, scrollen hapert, of de link die hij tikte doet even helemaal niets. Dit artikel gaat over de publieke voorkant van een WordPress-site, het deel dat bezoekers en zoekmachines zien. Het dashboard is een ander probleem met andere oorzaken, en dat staat in het artikel over een trage WordPress admin.
Wat "traag" eigenlijk betekent voor een bezoeker
Een moderne bezoeker ervaart paginasnelheid via een handvol meetbare momenten, niet via één enkel cijfer. Google's web.dev-richtlijnen voor Core Web Vitals definiëren de drie die ertoe doen: Largest Contentful Paint (LCP) voor laden, Interaction to Next Paint (INP) voor reactiesnelheid, en Cumulative Layout Shift (CLS) voor visuele stabiliteit. LCP is degene die mensen meestal bedoelen als ze zeggen "de site is traag".
LCP meet de tijd vanaf het moment dat iemand op een link klikt tot het moment dat de grootste zichtbare afbeelding, tekstblok of video in de viewport is gerenderd. De drempelwaarden die web.dev publiceert zijn concreet: 2,5 seconde of minder is goed, tussen 2,5 en 4 seconden moet beter, boven 4 seconden is slecht. Als een bezoeker zegt dat een site traag aanvoelde, dan zat de LCP op de pagina waar hij landde vrijwel altijd in de "moet beter" of "slecht" zone.
LCP is zelf weer een optelsom. web.dev splitst het op in vier delen: Time to First Byte (wachten op de server), resource load delay, resource load duration (het downloaden van de LCP-afbeelding of het LCP-font), en element render delay. Op een goed geoptimaliseerde pagina is grofweg 40% van de LCP TTFB en 40% resource load duration. Die verhouding is meteen ook de meest bruikbare diagnose in het hele artikel. Zit het grootste deel van je LCP in de TTFB, dan is de bottleneck de server. Zit het grootste deel in resource load, dan is de bottleneck de voorkant.
Waar de tijd in een WordPress-pagina werkelijk heen gaat
Een WordPress-pagina wordt opgebouwd in drie lagen. Elke laag kan de trage zijn, en aan de buitenkant zien de symptomen er verdacht hetzelfde uit.
De eerste laag is het netwerk. DNS-resolutie, de TCP-verbinding, de TLS-handshake en eventuele redirects gebeuren allemaal voordat WordPress überhaupt aan zet is. Voor een bezoeker uit dezelfde regio is dat meestal 50 tot 150 ms. Voor een bezoeker op een ander continent kan het flink meer worden, zeker bij een single-region origin zonder edge-aanwezigheid.
De tweede laag is de server. nginx of Apache geeft het verzoek door aan PHP-FPM, een worker boot WordPress, alle actieve plugins worden geladen, de database wordt bevraagd (vaak tientallen keren voor één pagina), en de HTML wordt opgebouwd. Op een gecachete pagina wordt deze laag volledig overgeslagen: een full-page cache levert de HTML direct terug zonder dat PHP überhaupt aan de bak hoeft. Op een uncached pagina draait de hele WordPress-build alsnog, en die build is precies waar het artikel over hoge TTFB in detail op ingaat.
De derde laag is de browser. Zodra de HTML binnen is, gaat de browser parsen, vraagt CSS, fonts, JavaScript en afbeeldingen op, draait de scripts, en schildert de pagina. Zware thema's, grote ongeoptimaliseerde afbeeldingen, render-blocking scripts, third-party embeds (analytics tags, chat widgets, ingebedde video's) en trage custom fonts zitten allemaal in deze laag. Geen daarvan heeft iets met de server te maken. Een site kan een TTFB van 200 ms hebben en een LCP van 6 seconden, en het hele gat van 5,8 seconden zit dan in de browser.
De valkuil is dat alle drie de lagen aan de buitenkant hetzelfde symptoom geven. "De site is traag." Zonder het verzoek op te splitsen in zijn drie lagen is elke fix gewoon een gok.
Hoe je je eigen site in de praktijk diagnosticeert
De verdeling van traagheid over pagina's en bezoekers vertelt je naar welke laag je moet kijken. Een paar patronen kom je vaak genoeg tegen om ze meteen te herkennen.
- Traag op elke pagina, elke keer, elke regio. Bijna altijd de server. Of het PHP-pad is zwaar (uncached requests die de hele pagina opbouwen), of de database is traag, of de hosting is gewoon te krap. Caching ontbreekt of staat verkeerd ingesteld. Begin met het artikel over hoge TTFB.
- Snelle HTML, trage paint. TTFB is prima, maar de pagina doet er alsnog seconden over om in beeld te komen. De bottleneck zit in de browserlaag: te grote hero-afbeeldingen, render-blocking JavaScript van page builders of sliders, third-party tags. De server heeft zijn werk gedaan en de browser zit nu vast op assets.
- Snel voor bezoekers, traag voor mij als ik ben ingelogd. De front-end cache doet zijn werk, maar voor ingelogde gebruikers wordt de cache bewust omzeild. Dit is hetzelfde mechanisme dat het dashboard traag laat aanvoelen terwijl de publieke site snel is. Staat in het artikel over een trage WordPress admin.
- Snel 's nachts, traag overdag. Concurrency. De site kan het prima alleen, maar valt om onder belasting. Of PHP workers staan in de wachtrij, of de server tikt zijn CPU-plafond aan. Allebei leveren een site op die meebeweegt met het verkeer.
- Traag op sommige pagina's, snel op andere. Meestal een specifiek query-pad. Een categorie-archief met duizenden producten, een tag-pagina met een trage ORDER BY, een zoekpagina die de database hard raakt. Hoort bij het artikel over een trage database.
- Random traag, geen helder patroon. Een ander soort probleem. Het artikel over wisselende traagheid loopt cron jobs, achtergrondscans en externe API-calls langs die een page build kunnen blokkeren.
- Pas traag sinds een recente wijziging. Traag na een update en traag na een plugin-installatie zijn aparte varianten die je beter even uitsluit voordat je de oorzaak structureel gaat noemen.
Wat "een trage WordPress-site" niet is
De meeste verwarring rond een trage WordPress-site komt doordat mensen het probleem reduceren tot één van de onderdelen. Dit zijn de verwisselingen die het meeste tijd kosten.
- Niet hetzelfde als een hoge TTFB. TTFB is één van de vier sub-onderdelen van LCP. Een site met een perfecte TTFB en een LCP van 6 seconden voelt voor een bezoeker nog steeds traag, en de fix heeft niets met de server te maken. Andersom: een site met een TTFB van 1.500 ms en een LCP van 2 seconden heeft wel een serverprobleem, maar de bezoeker merkt er amper iets van omdat de rest van de pagina snel rendert. Behandel TTFB als diagnose, niet als verdict.
- Niet een functie van het aantal plugins. "Hoeveel plugins is te veel" heeft geen antwoord, want plugins zijn niet gelijk. Eén slecht geschreven analytics-plugin die op elke page build een synchrone remote API-call doet, kost meer dan dertig kleine plugins die op de voorkant niets uitvoeren. Plugins tellen is gewoon de verkeerde eenheid. Wat elke plugin daadwerkelijk doet op het request-pad, dát is de juiste.
- Niet één getal dat je kunt najagen. LCP varieert per pagina, per locatie van de bezoeker, per cache-status en per device. Een homepage die je test vanaf een snelle desktop op hetzelfde continent als de origin, is niet representatief voor een echte bezoeker met een mid-range telefoon drie tijdzones verderop. Real-user field data, opgesplitst per percentiel en per route, is de eerlijke meting. Eén synthetische test vanaf één locatie zegt bijna niks.
- Niet "je hebt een sneller thema nodig". Thema's verschillen wel, maar het verschil tussen een zwaar commercieel thema en een licht thema is op een echte productiesite zelden de doorslaggevende factor. Plugins, uncached database queries, grote afbeeldingen en third-party scripts wegen bijna altijd zwaarder dan het thema zelf. Van thema wisselen om performance te fixen, breekt meestal de layout zonder dat het onderliggende probleem weggaat.
- Niet opgelost door er een CDN voor te zetten. Een CDN cachet statische assets aan de edge, en dat helpt de browserlaag voor afbeeldingen, fonts, CSS en JavaScript. Voor dynamische, niet-cachebare WordPress-responses doet een CDN bijna niets: ingelogde pagina's, de cart, de checkout, REST API-calls, zoekopdrachten. Die gaan nog steeds naar de origin, draaien door PHP-FPM en komen weer terug. Verwachten dat een CDN een trage PHP-origin redt op dynamische pagina's is de meest voorkomende misvatting over wat een CDN eigenlijk doet. Zie hoe WordPress-caching werkt voor het gedetailleerde gelaagde cachingmodel. Als de bottleneck in WordPress zelf zit, brengt een CDN het probleem dichter bij de bezoeker, maar het haalt het er niet weg.
- Niet hetzelfde als een trage admin. Het dashboard is by design niet cachebaar en draait per request een zwaarder plugin-pad dan de voorkant. Een site kan tegelijk een snelle publieke voorkant én een traag dashboard hebben, en de fixes zijn anders. Voorkant-traagheid draait vooral om caching, asset-gewicht en het LCP-pad. Admin-traagheid draait vooral om uncached PHP-uitvoering, database queries en worker pool-capaciteit.
Waar je verder moet kijken
Zit het symptoom vooral in de serverresponstijd, dan loopt het artikel over hoge TTFB door wat TTFB meet en waarom WordPress-sites er vaak een hoge hebben. Komt het symptoom alleen onder belasting boven, dan legt het artikel over PHP workers het wachtrijmodel uit dat dit veroorzaakt. Voelt het dashboard traag aan terwijl de publieke site snel is, dan vertelt het artikel over een trage WordPress admin waarom de admin als eerste resources opslokt.