Elke keer dat iemand jouw WordPress-website bezoekt, begint er achter de schermen een keten van technische stappen. Binnen milliseconden doorloopt een WordPress request een route van browser naar server, door PHP-bestanden en database-tabellen, tot er uiteindelijk een HTML-pagina verschijnt. Maar wat gebeurt er precies in die milliseconden?
Als je begrijpt hoe een WordPress request verloopt, kun je gerichter optimaliseren. Je weet dan waar knelpunten ontstaan, waarom bepaalde plugins je site vertragen en hoe caching echt werkt. In dit artikel nemen we het complete proces stap voor stap door.
Van browser naar server: de reis begint
Voordat WordPress ook maar iets doet, moet de browser van je bezoeker eerst jouw server vinden. Dat begint met een DNS-lookup: de browser vertaalt je domeinnaam (bijvoorbeeld jouwsite.nl) naar een IP-adres.
Daarna maakt de browser een TCP-verbinding met de server. Bij een beveiligde verbinding - en dat hoort tegenwoordig standaard te zijn - volgt ook een TLS-handshake om de versleuteling op te zetten. Dit zijn cruciale stappen die invloed hebben op de websitesnelheid.
Zodra de verbinding staat, stuurt de browser een HTTP-verzoek. Meestal een simpel GET / voor de homepagina, of GET /contact/ voor de contactpagina. De webserver - vaak Apache of Nginx - neemt dit verzoek aan en stuurt het door naar PHP.
Wat de webserver doet
De webserver leest eerst het .htaccess-bestand (bij Apache) of de serverconfiguratie (bij Nginx). Hier staan regels voor redirects, caching-headers en - cruciaal voor WordPress - de rewrite rules. Deze regels zorgen ervoor dat vrijwel elk verzoek wordt doorgestuurd naar een enkel bestand: index.php.
Dit is het startpunt van WordPress.
WordPress opstartroutine: de bootstrap
Het index.php-bestand in de root van je WordPress-installatie is verrassend kort. Het doet eigenlijk maar twee dingen:
- Het definieert de constante
ABSPATH(het pad naar de WordPress-installatie). - Het laadt
wp-blog-header.php.
Vanuit daar begint het echte werk. WordPress doorloopt een reeks bestanden in een vaste volgorde:
wp-config.php
Dit is het eerste configuratiebestand dat geladen wordt. Hier staan je database-credentials, taalinstellingen, beveiligingssleutels en eventuele aangepaste constanten. Alles wat WordPress nodig heeft om te weten waar en hoe het moet draaien.
Je kunt hier ook performance-gerelateerde instellingen definiëren, zoals:
WP_CACHE- schakelt objectcaching inSAVEQUERIES- logt alle database-queries (handig voor debugging, niet voor productie)WP_DEBUG- activeert foutmeldingen
wp-settings.php
Na de configuratie laadt WordPress wp-settings.php. Dit bestand is de dirigent van het orkest. Het initialiseert de gehele WordPress-omgeving:
- Laadt de vereiste PHP-bibliotheken en kernklassen
- Maakt de database-verbinding via
$wpdb - Laadt de must-use plugins (mu-plugins)
- Registreert de standaard post types en taxonomieën
- Laadt het actieve thema en alle geactiveerde plugins
- Vuurt de
init-hook af
Dit is het punt waar je site "tot leven komt". Elke plugin en elk thema haakt hier in via het hooks-systeem - het hart van de WordPress-architectuur.
Het hooks-systeem: actions en filters
WordPress draait op een event-driven systeem van actions en filters. Dit is wat WordPress zo uitbreidbaar maakt, maar het is ook de plek waar performance verloren kan gaan.
- Actions zijn momenten waarop code uitgevoerd wordt ("doe iets op dit moment").
- Filters zijn momenten waarop data aangepast wordt ("verander deze waarde voordat die gebruikt wordt").
Tijdens een request vuurt WordPress tientallen hooks af in een vaste volgorde. De belangrijkste:
muplugins_loaded- must-use plugins zijn geladenplugins_loaded- alle plugins zijn geladenafter_setup_theme- het thema is actiefinit- WordPress is volledig geïnitialiseerdwp- de query is geparsedtemplate_redirect- vlak voor het template geladen wordtwp_head- de<head>sectie wordt opgebouwdwp_footer- de footer wordt opgebouwdshutdown- het request is afgerond
Elke plugin die je installeert, haakt in op een of meer van deze hooks. Hoe meer plugins, hoe meer code er per request uitgevoerd wordt. Dit is een van de redenen waarom het aantal plugins direct invloed heeft op je laadtijd - iets dat ook meespeelt bij de keuze tussen WordPress en maatwerk websites.
De query: welke content moet er getoond worden?
Nadat WordPress is opgestart, moet het bepalen welke content bij het verzoek hoort. Dit gebeurt via de main query - een van de belangrijkste concepten in WordPress.
WordPress neemt de URL, vergelijkt die met de ingestelde permalink-structuur en vertaalt die naar een database-query. Dit proces heet URL parsing of query parsing.
Bijvoorbeeld: de URL /2026/04/mijn-artikel/ wordt vertaald naar een query die zoekt naar een post met die specifieke slug en publicatiedatum.
WP_Query en de database
De klasse WP_Query bouwt de SQL-query op en stuurt die naar de MySQL- of MariaDB-database. Een typische query haalt op:
- De postdata (titel, inhoud, datum, status)
- Bijbehorende metadata (custom fields)
- Taxonomieën (categorieën, tags)
- Auteursinformatie
Een standaard WordPress-installatie voert per paginaweergave 20 tot 50 database-queries uit. Met actieve plugins kan dit oplopen tot honderden. Elke query kost tijd, en een trage database is een van de meest voorkomende oorzaken van een langzame WordPress-site.
Conditional tags
Na het uitvoeren van de query stelt WordPress de conditional tags in. Deze functies - zoals is_single(), is_page(), is_archive() en is_home() - vertellen het themasysteem welk type pagina er getoond moet worden.
Template laden: van data naar HTML
Met de content opgehaald en het paginatype bepaald, gaat WordPress op zoek naar het juiste template. Dit volgt de template hierarchy - een vastgestelde volgorde waarin WordPress zoekt naar het meest specifieke templatebestand.
Voor een enkele blogpost zoekt WordPress bijvoorbeeld:
single-{post_type}-{slug}.phpsingle-{post_type}.phpsingle.phpsingular.phpindex.php
Het eerste bestand dat gevonden wordt, wordt gebruikt. Dit systeem geeft thema-ontwikkelaars fijnmazige controle over de opmaak van elk type pagina.
Het template genereert de HTML
Het geselecteerde template combineert PHP-logica met HTML-output. Het roept functies aan als the_title(), the_content() en the_post_thumbnail() om de content op te halen en weer te geven. Ondertussen worden opnieuw hooks afgevuurd - wp_head() voor stylesheets en scripts in de <head>, wp_footer() voor JavaScript onderaan de pagina.
Het resultaat is een complete HTML-string die de server terugstuurt naar de browser.
De terugweg: response naar de browser
De gegenereerde HTML gaat als HTTP-response terug naar de browser, inclusief:
- HTTP-statuscode (200 voor succes, 301 voor redirect, 404 voor niet gevonden)
- Headers met cache-instructies, content-type en beveiligingsinstellingen
- De HTML-body die de browser kan renderen
De browser ontvangt de HTML en begint met het opbouwen van de pagina. Maar daar stopt het niet - de browser doet nog extra verzoeken voor CSS-bestanden, JavaScript, afbeeldingen en fonts. Elk van die verzoeken doorloopt opnieuw het DNS-en-verbindingsproces, al worden die vaak versneld door caching en HTTP/2.
Waar gaat de tijd verloren?
Nu je weet wat er allemaal gebeurt, wordt ook duidelijk waar het mis kan gaan. De belangrijkste knelpunten:
Te veel database-queries
Elke plugin kan extra queries toevoegen. Sommige plugins voeren tientallen queries uit op elke pagina, zelfs als ze daar niet actief zijn. Met een tool als Query Monitor kun je precies zien welke queries er draaien.
Zware plugins die overal laden
Plugins die JavaScript en CSS op elke pagina laden - ook waar ze niet nodig zijn - vertragen het geheel. Denk aan contactformulier-plugins die hun scripts ook op blogposts laden.
Geen caching
Zonder caching doorloopt WordPress het complete proces bij elk bezoek opnieuw. Een caching-plugin slaat de gegenereerde HTML op, zodat bij een volgend bezoek de PHP-executie en database-queries overgeslagen worden.
Trage server of hosting
De snelheid van je hosting bepaalt hoe snel PHP uitgevoerd wordt en hoe snel de database reageert. Goedkope shared hosting kan een bottleneck zijn, ongeacht hoe goed je WordPress geoptimaliseerd is. Dit hangt nauw samen met technische SEO - een trage server ondermijnt al je andere optimalisaties.
Caching: het request kortsluiten
De meest effectieve optimalisatie is caching. Door de uitkomst van het hele proces op te slaan, hoeft WordPress het niet telkens opnieuw te doorlopen.
Er zijn verschillende niveaus van caching:
- Page caching - slaat de volledige HTML op, zodat PHP niet uitgevoerd hoeft te worden
- Object caching - slaat database-resultaten op in het geheugen (Redis, Memcached)
- Opcode caching - slaat gecompileerde PHP-code op (OPcache)
- Browser caching - laat de browser bestanden lokaal opslaan
- CDN caching - distribueert statische bestanden via servers dicht bij de bezoeker
Page caching heeft het grootste effect: het slaat vrijwel de hele WordPress-bootstrap over. In plaats van tientallen PHP-bestanden te laden en queries uit te voeren, serveert de server een kant-en-klaar HTML-bestand. Dat kan het verschil zijn tussen een laadtijd van 2 seconden en 200 milliseconden.
Wat kun je hiermee als website-eigenaar?
Je hoeft geen developer te zijn om deze kennis toe te passen. Een paar concrete stappen:
- Audit je plugins - deactiveer wat je niet gebruikt en test de impact op je laadtijd
- Installeer een caching-plugin - WP Super Cache of W3 Total Cache zijn goede startpunten
- Kies goede hosting - managed WordPress-hosting biedt vaak ingebouwde caching en optimalisatie
- Monitor je queries - installeer Query Monitor om knelpunten te vinden
- Houd je thema lean - gebruik geen thema's met tientallen ingebouwde features die je niet nodig hebt
Wil je weten hoe je website er technisch voor staat? Een SEO-audit brengt niet alleen je content in kaart, maar ook technische knelpunten die je laadtijd beïnvloeden.
Veelgestelde vragen
Wat is een WordPress request?
Een WordPress request is het volledige proces dat plaatsvindt wanneer iemand een pagina op jouw WordPress-website opvraagt. Dit omvat de DNS-lookup, de serververbinding, het laden van WordPress-bestanden, database-queries en het genereren van de uiteindelijke HTML.
Waarom is mijn WordPress-site traag?
Veelvoorkomende oorzaken zijn te veel of slecht gecodeerde plugins, een traag thema, ontbrekende caching, een langzame hostingomgeving en te veel database-queries. Door te begrijpen hoe een WordPress request werkt, kun je gericht de knelpunten aanpakken.
Wat is de rol van wp-config.php in een request?
wp-config.php is het eerste configuratiebestand dat WordPress laadt. Het bevat je database-inloggegevens, beveiligingssleutels, taalinstellingen en andere fundamentele instellingen die bepalen hoe WordPress functioneert.
Hoeveel database-queries doet WordPress per paginalading?
Een standaard WordPress-installatie voert gemiddeld 20 tot 50 database-queries uit per paginaweergave. Met actieve plugins en een complex thema kan dat oplopen tot honderden queries. Caching kan dit aantal drastisch verlagen.
Hoe kan ik zien wat er tijdens een WordPress request gebeurt?
Gebruik de plugin Query Monitor om live inzicht te krijgen in database-queries, PHP-fouten, hooks, geladen bestanden en laadtijden. Daarnaast kun je met de SAVEQUERIES-constante in wp-config.php alle database-queries loggen.