WP-Cron optimalisatie: snellere taken

WordPress plant achter de schermen tientallen taken: publicaties inplannen, updates controleren, transients opruimen en e-mails versturen. Het systeem dat dit regelt - WP-Cron - werkt fundamenteel anders dan een echte server cron job. En dat verschil kan je site merkbaar vertragen. In dit artikel leer je hoe WP-Cron werkt, waar het knelpunt zit en hoe je het stap voor stap optimaliseert.

We behandelden eerder al hoe je performance bottlenecks herkent en meet en hoe het volledige WordPress request-proces eruitziet. WP-Cron is een onderdeel dat in dat request-proces meelift - en daar zit precies het probleem.

Hoe WP-Cron werkt (en waarom het geen echte cron is)

Een traditionele cron job op Linux draait op vaste tijdstippen, ongeacht of er iemand op je site zit. De server voert de taak uit, klaar. WP-Cron werkt anders: het is traffic-driven. Pas wanneer een bezoeker een pagina laadt, controleert WordPress of er geplande taken klaarstaan.

Dit betekent twee dingen:

• Zonder verkeer geen uitvoering. Als niemand je site bezoekt, worden geplande publicaties niet gepubliceerd en draaien achtergrondtaken niet.
• Met verkeer wordt de bezoeker belast. De controle en eventuele uitvoering van taken gebeurt als onderdeel van het pageview. Dat verhoogt de TTFB voor die ene bezoeker.

Technisch werkt het zo: vroeg in het WordPress-laadproces - nog voor de template wordt geladen - kijkt wp_cron() of er taken in de wp_options-tabel staan waarvan het tijdstip is verstreken. Als dat zo is, vuurt WordPress een niet-blokkerend HTTP-request af naar wp-cron.php. In theorie blokkeert dit het originele verzoek niet, maar in de praktijk kost die extra HTTP-call wél serverresources. Op drukke sites kan dit tot een cascade van gelijktijdige cron-runs leiden.

De problemen met standaard WP-Cron

Onbetrouwbare timing

Stel je plant een blogpost in om 08:00 te publiceren. Als de eerste bezoeker pas om 08:47 langskomt, verschijnt je artikel 47 minuten te laat. Voor tijdkritische content - denk aan nieuwsberichten, productlanceringen of geplande social media - is dat problematisch.

Dubbele uitvoeringen

Bij hoog verkeer kunnen meerdere bezoekers tegelijkertijd binnenkomen en elk WP-Cron triggeren. WordPress heeft een lockingmechanisme, maar dat is niet waterdicht. Taken kunnen dubbel worden uitgevoerd, wat vooral bij backup-plugins en e-mailverzending tot ongewenste situaties leidt.

Performance-impact bij achterstallige taken

Als je site even offline is geweest of als WP-Cron een tijd niet is getriggerd, bouwt er een achterstand op. De eerste bezoeker daarna krijgt de volle lading: alle achterstallige taken worden in één keer uitgevoerd. Dat kan de laadtijd met seconden verhogen.

Dit effect is vergelijkbaar met wat we beschreven bij autoloaded options - onzichtbare processen die bij elk request meelopen en cumulatief je laadtijd omhoog duwen.

Extra load op de server

Elke WP-Cron trigger start effectief een extra request naar je eigen server. Bij een site met honderd bezoekers per minuut zijn dat honderd extra interne requests die allemaal checken of er werk te doen is. Die PHP-FPM workers kun je beter inzetten voor echte bezoekers.

Stap 1: analyseer je huidige cron-taken

Voordat je iets wijzigt, wil je weten wat er in je cron-wachtrij staat. De plugin WP-Crontrol geeft je een compleet overzicht.

Na installatie vind je onder Extra > Cron Events een lijst van alle geplande taken. Let op:

• Taken die te vaak draaien - sommige plugins plannen taken elke minuut in terwijl eens per uur voldoende is
• Achterstallige taken - taken waarvan het geplande tijdstip al is verstreken
• Onbekende taken - taken van plugins die je al hebt verwijderd maar die hun cron-events niet hebben opgeruimd

Met WP-CLI kun je dit ook zonder plugin bekijken:

wp cron event list

Dit toont alle geplande events met hun hook, volgende uitvoering en interval. Het is dezelfde informatie als WP-Crontrol, maar handig als je liever op de commandline werkt.

Stap 2: schakel WP-Cron uit

De eerste concrete stap is het uitschakelen van de ingebouwde traffic-driven cron. Open je wp-config.php en voeg de volgende regel toe boven de regel /* That's all, stop editing! */:

define('DISABLE_WP_CRON', true);

Dit schakelt alleen het automatische triggeren uit. De cron-taken zelf bestaan nog gewoon - ze worden alleen niet meer bij elk pageview gecontroleerd. Je moet nu zelf zorgen dat ze worden uitgevoerd.

Stap 3: stel een echte server cron job in

De vervanging is een server-level cron job die wp-cron.php op vaste intervallen aanroept. Hiermee haal je de cron-uitvoering volledig los van je bezoekersverkeer.

Via de commandline (Linux/crontab)

Open de crontab van je webserver-gebruiker:

crontab -e

Voeg de volgende regel toe:

*/5 * * * * curl -s https://jouwsite.nl/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Dit roept elke vijf minuten wp-cron.php aan. De ?doing_wp_cron parameter voorkomt dat WordPress een extra lockcheck uitvoert.

Een nog betere aanpak is het direct aanroepen via WP-CLI, omdat je dan geen HTTP-overhead hebt:

*/5 * * * * cd /var/www/jouwsite && wp cron event run --due-now > /dev/null 2>&1

Elke minuut of elke vijf minuten?

WordPress zelf beveelt elke minuut aan als interval. Dit zorgt ervoor dat geplande publicaties en andere tijdkritische taken nooit meer dan een minuut te laat zijn.

Bij lichtere sites is elke vijf minuten een prima compromis. Draai het niet minder dan elke vijftien minuten - anders loop je dezelfde timingproblemen op die je wilde oplossen.

Managed hosting

Bij managed WordPress-hosting (zoals Kinsta, Cloudways of Savvii) is WP-Cron vaak al vervangen door een server-level cron. Check de documentatie van je hostingprovider. Sommige partijen bieden een instelling in hun dashboard, andere regelen het automatisch.

Stap 4: optimaliseer individuele cron-taken

Na het omschakelen naar een server cron is het tijd om de taken zelf te optimaliseren.

Verwijder overbodige taken

Plugins die je hebt gedeactiveerd of verwijderd laten vaak hun cron-events achter. Via WP-Crontrol of WP-CLI kun je deze handmatig opruimen:

wp cron event delete <hook-naam>

Dit is vergelijkbaar met het opruimen van achtergebleven opties in wp_options - rommel van oude plugins die onnodig resources verbruikt.

Pas frequenties aan

Sommige plugins bieden instellingen voor hun cron-frequentie. Een backup-plugin die elk uur draait terwijl je site maar eens per week verandert, is verspilling. Check de instellingen van:

• Backup-plugins - dagelijks is voor de meeste sites voldoende
• SEO-plugins - sitemap-hergeneratie hoeft niet elk uur
• Analytics-plugins - data ophalen kan vaak eens per dag
• WooCommerce - houd e-mailwachtrijen en voorraadsynchronisatie wel frequent

Vermijd custom cron op korte intervallen

Als je zelf cron-taken registreert in een plugin of theme, denk dan goed na over het interval. WordPress biedt standaard hourly, twicedaily en daily. Een custom interval van elke minuut registreren is zelden nodig en belast je server onnodig.

// Doe dit niet tenzij strikt noodzakelijk
wp_schedule_event(time(), 'every_minute', 'mijn_zware_taak');

// Beter: gebruik een passend standaardinterval
wp_schedule_event(time(), 'hourly', 'mijn_taak');

Stap 5: monitor en onderhoud

Controleer of je cron daadwerkelijk draait

Een veelgemaakte fout: WP-Cron uitschakelen maar vergeten de server cron in te stellen. Of de server cron staat wel ingesteld maar faalt stilletjes. Controleer dit regelmatig.

Met WP-CLI:

wp cron event list --fields=hook,next_run_relative

Als je overal "now" of negatieve tijden ziet, worden je taken niet uitgevoerd. Controleer dan je crontab en serverlogbestanden.

Houd je cron-wachtrij schoon

Plan een periodieke controle in - bijvoorbeeld maandelijks - waarin je de cron-events doorloopt. Verwijder taken van plugins die je niet meer gebruikt en controleer of frequenties nog passend zijn.

Log cron-activiteit

Voor debugging kun je cron-uitvoering loggen. Voeg dit toe aan je wp-config.php:

define('WP_CRON_LOCK_TIMEOUT', 120);

Dit vergroot het lockingvenster naar 120 seconden, wat dubbele uitvoeringen verder beperkt. Standaard is dit 60 seconden.

Voor uitgebreidere logging kun je de WP Crontrol plugin gebruiken, die events logt wanneer ze worden uitgevoerd.

WP-Cron en caching: een veelvoorkomende valkuil

Als je full page caching hebt ingesteld - via NGINX of een plugin - is er een extra reden om WP-Cron uit te schakelen. Gecachte pagina's bereiken PHP niet, wat betekent dat WP-Cron niet wordt getriggerd. Een site met een hoge cachehit-ratio heeft dus effectief een kapotte cron.

Dit is een van de meest voorkomende oorzaken van "mijn geplande berichten worden niet gepubliceerd". De oplossing is altijd dezelfde: schakel over naar een server cron job.

WP-Cron in een multi-server setup

Draai je WordPress op meerdere servers? Dan verdient WP-Cron extra aandacht. Je wilt voorkomen dat dezelfde taak op meerdere servers tegelijk wordt uitgevoerd.

De beste aanpak:

• Schakel DISABLE_WP_CRON in op alle servers
• Stel de server cron job in op slechts één server (of een dedicated cron-server)
• Gebruik WP-CLI in plaats van HTTP-calls, zodat je geen load balancer passeert

Dit voorkomt dubbele uitvoeringen en houdt je cron-verwerking voorspelbaar.

Geavanceerd: Action Scheduler als alternatief

Voor complexere scenario's - denk aan WooCommerce, grote import/export-taken of het verwerken van wachtrijen - biedt Action Scheduler een robuuster alternatief voor WP-Cron. WooCommerce gebruikt dit intern al.

Action Scheduler biedt:

• Wachtrijen met prioriteit - taken worden in volgorde verwerkt
• Retry-logica - mislukte taken worden automatisch opnieuw geprobeerd
• Logging - elke taak wordt gelogd met status en doorlooptijd
• Schaalbaarheid - beter geschikt voor grote hoeveelheden taken

Als je WooCommerce draait, profiteer je hier al van. Voor custom ontwikkeling is het een waardevol alternatief wanneer WP-Cron niet toereikend is.

Checklist: WP-Cron optimalisatie

Ter afsluiting een samenvatting die je als checklist kunt gebruiken:

• Analyseer huidige cron-taken met WP-Crontrol of WP-CLI
• Voeg DISABLE_WP_CRON toe aan wp-config.php
• Stel een server cron job in (elke 1-5 minuten)
• Verwijder cron-events van gedeactiveerde plugins
• Pas frequenties aan van zware taken (backups, sitemaps)
• Controleer of geplande publicaties correct werken
• Monitor regelmatig of de server cron actief is
• Bij multi-server: cron op slechts één server draaien

Veelgestelde vragen

Wat is het verschil tussen WP-Cron en een echte cron job?

WP-Cron wordt pas uitgevoerd wanneer een bezoeker je site laadt. Een echte server cron job draait op vaste tijden, onafhankelijk van verkeer. Daardoor zijn echte cron jobs betrouwbaarder en belasten ze je bezoekers niet met extra verwerkingstijd.

Hoe schakel ik WP-Cron uit zonder geplande taken te verliezen?

Voeg define('DISABLE_WP_CRON', true) toe aan je wp-config.php. Stel daarna een server cron job in die elke minuut of elke vijf minuten wp-cron.php aanroept. Zo blijven al je geplande taken gewoon werken, maar worden ze niet meer door bezoekers getriggerd.

Kan WP-Cron mijn site echt langzamer maken?

Ja. Bij elk pageview controleert WordPress of er achterstallige taken zijn. Als er veel taken in de wachtrij staan, worden die tijdens het bezoekersverzoek uitgevoerd. Dit verhoogt de Time to First Byte en kan bij drukke sites tot merkbare vertragingen leiden.

Hoe vaak moet ik een server cron job laten draaien voor WordPress?

Elke minuut is de meest betrouwbare optie en is wat WordPress zelf aanbeveelt. Bij lichte sites is elke vijf minuten vaak voldoende. Draai het niet minder dan elke vijftien minuten, anders kunnen geplande publicaties en andere tijdkritische taken te laat uitvoeren.

Welke plugins gebruiken WP-Cron het zwaarst?

Backup-plugins, SEO-plugins die sitemaps hergenereren, WooCommerce voor e-mailwachtrijen en voorraadsynchronisatie, en caching-plugins voor het voorverwarmen van de cache. Controleer met WP-Crontrol welke taken er draaien en hoe vaak.