OPcache en preloading: PHP sneller voor WordPress

PHP is geen snelle taal van zichzelf. Elke keer dat een bezoeker je WordPress-site opent, moet PHP tientallen bestanden inlezen, parsen, compileren naar bytecode en pas dán uitvoeren. Doe dat honderden keren per minuut en je server ligt op zijn knieën. Met OPcache en preloading elimineer je een groot deel van dat werk en maak je je WordPress-site direct meetbaar sneller.

In dit artikel duik je in beide technieken. Je leert hoe ze werken, hoe je ze configureert voor WordPress en welke valkuilen je moet vermijden. Of je nu een eenvoudige blog of een drukbezochte webshop draait, de winst is significant.

Waarom PHP traag is zonder OPcache

PHP is een geïnterpreteerde taal. Bij elk request gebeurt er iets dat veel mensen onderschatten: PHP leest het bronbestand, ontleedt de syntax, bouwt een interne representatie en vertaalt dat naar bytecode die de Zend Engine kan uitvoeren.

Bij een doorsnee WordPress-pagina laad je al snel 100 tot 300 PHP-bestanden. Zonder cache betekent dat: 300 keer disk I/O, 300 keer parsen, 300 keer compileren. Per request.

Voor een achtergrond over wat er allemaal gebeurt tijdens zo'n request raden we onze diepgaande uitleg over wat er tijdens een WordPress request gebeurt aan. Het maakt pijnlijk duidelijk waarom caching op PHP-niveau zoveel uitmaakt.

Wat OPcache precies doet

OPcache is sinds PHP 5.5 een ingebouwde extensie. Hij doet één ding heel goed: hij bewaart de gecompileerde bytecode van PHP-scripts in shared memory.

De eerste keer dat een bestand wordt aangeroepen, doorloopt PHP het hele compileerproces. Daarna onthoudt OPcache het resultaat. Bij elk volgend request slaat PHP de parse- en compileerstappen over en voert direct de bytecode uit.

Het effect is enorm. Je elimineert disk I/O, je elimineert het zwaarste CPU-werk, en je houdt RAM productief in plaats van dezelfde berekeningen telkens opnieuw te draaien.

Wanneer OPcache niet helpt

OPcache cachet alleen PHP-code. Database-queries, externe API-calls of langzame plugins versnelt het niet. Voor de aanpak van die problemen verwijzen we je naar onze artikelen over debugging van trage plugins en database optimalisatie voor WordPress.

OPcache configureren voor WordPress

OPcache zit ingebouwd, maar de standaardinstellingen zijn vaak te conservatief voor een serieuze WordPress-installatie. Je vindt de configuratie in php.ini of in een apart bestand zoals /etc/php/8.3/fpm/conf.d/10-opcache.ini.

Een productie-vriendelijke baseline ziet er zo uit:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.save_comments=1
opcache.fast_shutdown=1

Per setting kort wat hij doet en waarom je hem zo zet:

• memory_consumption=256: 256 MB shared memory voor bytecode. Voldoende voor WordPress core, een dik thema en 30+ plugins. Te krap zorgt voor cache-evictions die je site juist trager maken.
• interned_strings_buffer=16: PHP dedupliceert strings tussen scripts. Hoe groter de buffer, hoe meer strings je hergebruikt. WordPress profiteert hier extra van vanwege het grote aantal hook-namen en optie-keys.
• max_accelerated_files=20000: het maximum aantal bestanden dat OPcache mag cachen. WordPress met populaire plugins zoals WooCommerce of ACF zit al snel boven 10.000 bestanden.
• validate_timestamps=0: in productie hoeft PHP niet te checken of bestanden zijn gewijzigd. Dit scheelt bij elk request een stat-call per bestand. Belangrijk: na een deploy moet je OPcache wel handmatig flushen.
• save_comments=1: WordPress en veel frameworks gebruiken docblock-annotaties. Uitschakelen breekt onder andere de WP REST API.

OPcache flushen na een deploy

Met validate_timestamps=0 weet PHP niets van nieuwe code totdat je de cache leegt. Doe dit met een PHP-FPM reload:

sudo systemctl reload php8.3-fpm

Of via een PHP-script dat opcache_reset() aanroept, bijvoorbeeld als laatste stap in je deploy-pijplijn.

Preloading: het volgende niveau

Sinds PHP 7.4 bestaat preloading: een mechanisme waarbij je PHP een script laat uitvoeren op het moment dat PHP-FPM start. Alle bestanden die dat script require-t, worden permanent in het geheugen geladen, ze hoeven niet meer te worden gelinkt of geladen bij requests.

Het verschil met gewone OPcache is subtiel maar belangrijk:

• OPcache: cachet bytecode pas na het eerste request voor elk bestand.
• Preloading: laadt bytecode vooraf, plus link- en class-resolutie, vóór het eerste request.

Het resultaat is een nog kleinere request-overhead, vooral voor de eerste requests na een herstart en voor bestanden die nog niet "warm" zitten.

Preloading configureren

In je php.ini voeg je toe:

opcache.preload=/var/www/wordpress/preload.php
opcache.preload_user=www-data

preload_user is verplicht als PHP als root start (typisch bij PHP-FPM op Linux).

Een preload-script voor WordPress

Voor WordPress zit hier de uitdaging: het CMS verwacht een volledige request-context (database, hooks, opties). Tijdens preloading is die er niet. Probeer je wp-load.php te preloaden, dan krijg je gegarandeerd fouten.

De pragmatische aanpak: preload alleen statische helper-bestanden uit de WordPress core en je theme die geen runtime-context vereisen.

<?php
// /var/www/wordpress/preload.php

$files = [
    '/var/www/wordpress/wp-includes/functions.php',
    '/var/www/wordpress/wp-includes/class-wp-error.php',
    '/var/www/wordpress/wp-includes/class-wp-hook.php',
    '/var/www/wordpress/wp-includes/plugin.php',
    '/var/www/wordpress/wp-includes/formatting.php',
    '/var/www/wordpress/wp-includes/kses.php',
];

foreach ($files as $file) {
    if (is_readable($file)) {
        opcache_compile_file($file);
    }
}

Door opcache_compile_file() in plaats van require te gebruiken, voer je geen code uit. Je laadt alleen de bytecode in het geheugen. Veiliger en zonder side-effects.

Verwachtingen managen

Wees realistisch over preloading. De winst voor WordPress is vaak 5 tot 15% extra ten opzichte van een goed afgestelde OPcache. Geen factor 2. De grootste kapitaalwinst zit nog altijd in OPcache zelf.

OPcache monitoren

Een cache zonder inzicht is een blinde gok. Installeer een lichte tool zoals opcache-gui op een afgeschermde URL, of bekijk via WP-CLI:

wp eval 'print_r(opcache_get_status(false));'

Let op deze metrics:

• Hit rate: zou boven de 99% moeten liggen op een stabiele site.
• Used memory vs free memory: zit je tegen het maximum aan, dan blijft OPcache evicten en daalt je hit rate.
• Cached scripts vs max_accelerated_files: zit je dichtbij het maximum, verhoog dan max_accelerated_files (gebruik een priemgetal).
• Restarts (oom/manual/hash): vaak voorkomende restarts duiden op een te kleine buffer.

Voor breder inzicht in performance zie ook ons artikel over WordPress performance bottlenecks herkennen.

Combineren met andere optimalisaties

OPcache en preloading staan niet op zichzelf. Ze werken het beste samen met:

• Een goed afgestelde PHP-FPM pool, zie onze PHP-FPM tuning gids voor WordPress.
• Object caching met Redis, verlaagt het aantal database-queries dat PHP überhaupt moet uitvoeren. Lees onze diepgang over Redis object caching.
• Full page caching, vangt de meeste requests af voordat PHP überhaupt start. Zie full page caching: NGINX vs plugins.

De truc is: hoe verder een request afblijft van PHP, hoe sneller je site is. OPcache zorgt ervoor dat áls PHP wel moet draaien, dat zo snel mogelijk gaat.

Veelgemaakte fouten

In de praktijk zien we dezelfde fouten bij klanten:

1. OPcache uit laten staan in productie. Klinkt onmogelijk, gebeurt vaker dan je denkt. Vooral op shared hosting of na een PHP-upgrade.
2. memory_consumption te laag. De default van 128 MB is voor moderne WordPress-sites te krap. Reken op minimaal 192 tot 256 MB.
3. validate_timestamps=1 vergeten te wijzigen. Standaard checkt PHP elk bestand bij elk request. Met veel plugins kost dat tientallen extra stat-calls per request.
4. Geen flush na deploy. Met validate_timestamps=0 blijft je oude code draaien. Dit voelt aan als spookbugs als je het de eerste keer meemaakt.
5. Preloading zonder begrip. WordPress preloaden zonder selectiviteit leidt tot harde fouten of vreemde gedragingen op productie.

Voor uitgebreide foutopsporing helpt onze gids WordPress logs analyseren als een pro. De meeste OPcache-issues lekken namelijk via PHP-FPM of error logs.

Conclusie

OPcache is geen leuke optie maar een vereiste voor elke serieuze WordPress-installatie. Het verschil tussen een site met en zonder OPcache is meestal de factor tussen "wow snel" en "waarom is dit zo traag". Preloading geeft een extra zetje, maar vraagt een doordachte aanpak om binnen de WordPress-context goed te werken.

Begin met OPcache goed afstellen, monitor je hit rate, en overweeg preloading pas als je de basis op orde hebt. De officiële PHP-documentatie over OPcache is daarbij je beste vriend.

Veelgestelde vragen

Wat is OPcache precies?

OPcache is een ingebouwde PHP-extensie die gecompileerde bytecode in het geheugen bewaart. Daardoor hoeft PHP scripts niet bij elk request opnieuw te parsen en te compileren, wat resulteert in een aanzienlijk snellere uitvoering.

Wat is het verschil tussen OPcache en preloading?

OPcache cachet bytecode pas nadat een script voor het eerst is uitgevoerd. Preloading laadt vooraf geselecteerde bestanden direct bij het opstarten van PHP-FPM, zodat ze meteen beschikbaar zijn zonder dat een eerste request nodig is.

Werkt preloading goed met WordPress?

Preloading werkt, maar vraagt extra zorg. WordPress laadt bestanden dynamisch, en plugins kunnen tijdens preload botsen met hooks of database-calls. Een goed afgestelde preload-script richt zich op de WordPress core en stabiele helpers.

Hoeveel sneller wordt mijn site door OPcache?

De winst varieert, maar in de praktijk zie je 2 tot 4 keer snellere PHP-uitvoering bij een goed geconfigureerde OPcache. Bij grote WordPress-sites met veel plugins is het verschil zonder OPcache vrijwel altijd dramatisch.

Moet ik OPcache cachen in development?

In development zet je OPcache het liefst uit of op revalidate-modus, zodat codewijzigingen direct zichtbaar zijn. In productie schakel je revalidatie uit voor maximale performance en deploy je via een cache-reset.