Onder de motorkap: webserver, PHP en database

Module 1: Hoe WordPress werkt · Leestijd: 8 minuten

Leerdoel: Na deze les kun je stap voor stap uitleggen hoe een paginaverzoek bij WordPress tot een HTML-pagina wordt, en waar een cache dat pad inkort.

Kernbegrippen: webserver (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, query, index.php, template-hiërarchie, dynamisch vs statisch, TTFB

Een statische en een dynamische pagina

Bij een statische website staat elke pagina als kant-en-klaar bestand op de server. De webserver pakt het bestand en stuurt het op. Dat is snel en eenvoudig, maar elke wijziging betekent een nieuw bestand.

WordPress is dynamisch: de pagina bestaat pas op het moment dat iemand erom vraagt. Er is geen bestand contact.html. Er is een stuk tekst in de database, een thema met sjablonen en een stapel PHP-code die die twee samenvoegt. Dat geeft gemak (je past de tekst in je browser aan), maar het kost bij elk bezoek rekenwerk. Begrijp je dat rekenwerk, dan begrijp je later ook waarom een site traag is, waarom caching zo veel uitmaakt en waarom een PHP-upgrade iets kan breken.

De reis van een paginaverzoek

Stel: een bezoeker opent https://example.com/contact/. Dit gebeurt er:

1. DNS: de browser zoekt het IP-adres van example.com op (zie de DNS-cursus). Hij maakt een beveiligde verbinding met dat adres.
2. Webserver: op de server draait een webserver, bijvoorbeeld LiteSpeed, Apache of nginx. Die ontvangt het verzoek. Bestaat er een echt bestand of map met die naam (een afbeelding, een stylesheet), dan stuurt hij dat direct op. Zo niet, dan geldt de regel uit .htaccess (bij LiteSpeed en Apache) of uit de nginx-configuratie: "geef alles wat niet bestaat aan index.php".
3. PHP: index.php is een PHP-bestand. De webserver laat het uitvoeren door PHP, de programmeertaal waarin WordPress is geschreven. PHP laadt eerst wp-config.php (de instellingen, met de databasegegevens), dan de rest van WordPress, dan alle actieve plugins en het actieve thema.
4. Database: WordPress kijkt welke inhoud bij /contact/ hoort en stelt de database (MariaDB of MySQL) vragen: welke pagina heeft de slug contact, wat zijn de instellingen van de site, welk menu hoort erbij? Zo'n vraag heet een query. Een eenvoudige pagina kost al snel tientallen query's; met plugins kunnen het er honderden worden.
5. Thema: WordPress kiest welk sjabloon van het thema de pagina opmaakt. Dat gaat volgens de template-hiërarchie: voor een pagina met slug contact zoekt WordPress eerst een sjabloon page-contact, dan page-<id> (het nummer van de pagina), dan page, dan singular en uiteindelijk index. Het eerste dat bestaat, wint.
6. HTML terug: het resultaat is een HTML-pagina die PHP aan de webserver geeft, en de webserver aan de browser.
7. De browser leest de HTML en haalt daarna nog de stylesheets, scripts, lettertypen en afbeeldingen op. Die zijn wel gewone bestanden, dus die komen direct van de webserver (of uit een cache).

Tussen stap 2 en stap 6 zit de tijd die de server nodig heeft om de pagina te maken. Dat zie je terug als TTFB (time to first byte): de tijd tussen het verzoek en de eerste byte van het antwoord. Bij een goed ingerichte site ligt die ruim onder een seconde. In module 6 meet je dat zelf.

Waarom elke plugin meetelt

Bij stap 3 worden alle actieve plugins geladen, bij elk verzoek. Ook als die plugin op deze pagina niets doet. Een plugin voor een fotogalerij wordt dus ook geladen als iemand je contactpagina opent. Elke plugin kan extra query's doen, extra code laden en extra scripts aan de pagina toevoegen.

Dat verklaart twee dingen die je in deze cursus vaker tegenkomt:

• Minder plugins is meestal sneller. Niet omdat het aantal op zich telt, maar omdat elke plugin bij elk verzoek werk kan doen.
• Eén kapotte plugin kan de hele site platleggen. Gaat er in stap 3 iets fout (bijvoorbeeld een plugin die niet werkt met de nieuwe PHP-versie), dan komt PHP nooit bij stap 6. De bezoeker krijgt een witte pagina of de melding "Er is een kritieke fout op deze website" (les 5.4).

Waar PHP en de database vandaan komen

PHP en de database draaien op de server van je hoster. Jij kiest meestal zelf de PHP-versie in het controlepaneel (bij DirectAdmin heet dat Select PHP version, zie les 8.4). De database maak je aan bij de installatie; de installer doet dat vaak voor je (les 2.2).

Een paar dingen om te onthouden:

• PHP-versie: elke nieuwe PHP-versie is sneller en veiliger, maar oude code kan erop stuklopen. wordpress.org adviseert op dit moment PHP 8.3 of hoger (stand november 2026).
• Database: wordpress.org adviseert MariaDB 10.11 of hoger, of MySQL 8.0 of hoger. MariaDB is een afsplitsing van MySQL; voor WordPress maakt het geen verschil.
• De database staat meestal op dezelfde server (DB_HOST is dan localhost). Bij grotere hosting kan hij op een aparte server staan.

Cache: het pad inkorten

Als honderd bezoekers dezelfde contactpagina opvragen, maakt WordPress hem zonder cache honderd keer opnieuw. Elke keer dezelfde query's, hetzelfde sjabloon, dezelfde HTML. Een paginacache bewaart de HTML na de eerste keer. De volgende bezoeker krijgt de opgeslagen versie: stap 3 tot en met 6 vallen weg.

Zonder cache:  browser > webserver > PHP > WordPress + plugins > database > thema > HTML
Met cache:     browser > webserver > opgeslagen HTML

Dat is waarom caching de grootste snelheidswinst geeft (les 6.2). Het verklaart ook een veelgehoorde verwarring: "ik heb de tekst aangepast, maar ik zie de oude versie." Dan krijg je een opgeslagen versie; na het legen van de cache zie je de nieuwe.

Niet alles mag uit een cache komen. Een ingelogde beheerder, een winkelwagen of een afrekenpagina is voor elke bezoeker anders. Een goede cacheplugin slaat die over.

Kopregels: wat de server je vertelt

Elk antwoord van een webserver begint met kopregels (headers), vóór de HTML. Die zie je niet op de pagina, maar wel in de ontwikkelhulpmiddelen van je browser (F12, tabblad Netwerk, klik op het eerste verzoek). Een voorbeeld:

HTTP/2 200
server: LiteSpeed
content-type: text/html; charset=UTF-8
link: <https://example.com/wp-json/>; rel="https://api.w.org/"
x-litespeed-cache: hit

• server zegt welke webserver antwoordt.
• link met wp-json verraadt dat het WordPress is.
• x-litespeed-cache: hit betekent dat deze pagina uit de LiteSpeed-cache kwam. Andere caches gebruiken andere namen, zoals x-cache: HIT of cf-cache-status: HIT bij Cloudflare.

Je hoeft deze regels niet uit je hoofd te kennen. Maar wie ze kan lezen, kan veel problemen zelf vinden.

Samenvatting

• WordPress maakt elke pagina op het moment van het verzoek: webserver, PHP, plugins, database, thema, HTML.
• Bij elk verzoek worden alle actieve plugins geladen; één kapotte plugin kan de hele site stoppen.
• De template-hiërarchie bepaalt welk sjabloon van het thema een pagina opmaakt.
• Een paginacache slaat het rekenwerk over door opgeslagen HTML te geven. Ingelogde gebruikers en winkelwagens horen niet in die cache.
• De kopregels van een antwoord vertellen welke webserver antwoordt en of de pagina uit een cache kwam.

Quiz

Opdracht

Opdracht A1.2: Lees de kopregels van je site. Open je eigen site (of wordpress.org) met de ontwikkelhulpmiddelen van je browser (F12, tabblad Netwerk, ververs de pagina, klik op het eerste verzoek). Vul in welke webserver er in de kopregel server staat (of "geen" als die er niet is) en of er een kopregel is die zegt dat de pagina uit een cache kwam (welke naam en welke waarde). Het programma vraagt dezelfde pagina op en vergelijkt.

Verder lezen

Deze artikelen beschrijven de stappen in de panelen van WebOké; in andere panelen werken ze vergelijkbaar.

• DirectAdmin handleiding 1.9: Begrippen uitgelegd: domein, subdomein, pointer, DNS, mailbox en database
• DirectAdmin handleiding 14.1: De PHP-versie kiezen (Select PHP version)
• Gratis DNS-cursus 1.4: De reis van een DNS-vraag
• Template-hiërarchie (developer.wordpress.org, Engels): https://developer.wordpress.org/themes/basics/template-hierarchy/