Waarom WordPress traag kan aanvoelen na een update

Een update verandert code die WordPress op elke request uitvoert. Nieuwe core-bestanden, nieuwe plugincode, nieuwe thema-templates en soms een nieuw databaseschema. Al die dingen kunnen de kosten om een pagina te bouwen veranderen. Dit artikel gaat over het venster vlak na die verandering, als een site die snel was ineens traag wordt voor minuten, uren of soms permanent.

Wat "traag na een update" eigenlijk is

Traagheid na een update is niet één storingspatroon. Het zijn er twee, en het verschil is belangrijk. Er is een tijdelijke dip die zichzelf oplost zodra caches weer warm zijn en eenmalige migraties klaar zijn, en er is een structurele regressie die de update heeft geïntroduceerd en niet vanzelf verdwijnt. Het tijdelijke type is de verwachte prijs van draaiende code vervangen. Het structurele type is een probleem in de nieuwe code zelf, in de interactie met de rest van de stack, of in een databasemigratie die niet netjes is afgerond. Die twee verwarren is de meest voorkomende manier waarop mensen een middag aan dit probleem verspillen.

Hoe een update een draaiende site eigenlijk verstoort

Een WordPress-update raakt drie lagen waar een request doorheen loopt: PHP, de database en de verschillende caches die daarbovenop zitten. Elke laag reageert anders op bestanden die op schijf veranderen.

PHP en OPcache. WordPress draait als PHP, en op moderne hosts wordt PHP geserveerd vanuit een opcode cache. OPcache zet gecompileerde bytecode in shared memory, zodat PHP bestanden niet op elke request opnieuw hoeft te parsen. Zodra je PHP-bestanden overschrijft, moet OPcache dat doorhebben, de oude bytecode invalideren en opnieuw compileren. Met de standaard opcache.validate_timestamps=1 controleert OPcache elke opcache.revalidate_freq seconden de bestandstimestamps (standaard: 2) en compileert alles wat nieuwer is. Op hosts die vanwege performance met validate_timestamps=0 draaien, merkt OPcache de wijziging niet totdat de pool wordt gereset, en daarom herstarten sommige platforms PHP-FPM na een deploy. Hoe dan ook: de eerste requests na een update komen op een koudere cache terecht, en de request die de hercompilatie triggert betaalt de parse-kosten.

De database. Als de update WordPress core over een major-versie heen tilt, draait WordPress zelf wp_upgrade(), die de cache flusht, het schema bijwerkt via make_db_current_silent(), upgrade_all() draait en de wp_upgrade action hook afvuurt. WooCommerce, ACF, LearnDash, BuddyBoss en andere grote plugins draaien soortgelijke eenmalige upgrade-routines na hun eigen update, waarbij soms tabellen met miljoenen rijen worden gemigreerd. Tijdens die migratie concurreert elke request met een database die zware schrijfacties doet. Dit is het "Database update required"-scherm dat je soms ziet als je vlak na een core-upgrade /wp-admin/ bezoekt, en het is ook waarom de officiële upgrade-instructies van WordPress je adviseren om na een grote update plugins één voor één weer te activeren en te controleren.

Caches. Elke full-page cache, object cache en geminifieerde asset-bundel is gekoppeld aan de code die vóór de update bestond. De meeste caching-lagen invalideren zichzelf bij een core- of plugin-update, zodat bezoekers geen verouderde pagina's zien. Dat is correct gedrag, maar het betekent ook dat de eerste paginaweergave na de update het volledige uncached WordPress-pad aflegt. De autoload-cache met options (alloptions, die WordPress aan het begin van elke request laadt) wordt op dezelfde manier opnieuw opgebouwd: geleegd en bij de volgende request opnieuw gevuld uit wp_options.

Leg die drie mechanismes over elkaar heen en de site draait op koudere PHP, een drukkere database en een lege cache tegelijk. Dat is de normale staat van een WordPress-site in de eerste paar minuten na een update, nog voordat er ook maar iets echt misgegaan is.

Tijdelijke dip of structurele regressie

De diagnostische vraag is of de site uit zichzelf herstelt zodra die tijdelijke omstandigheden verdwijnen. Geef het kwartier op een kleine site, een uur op een drukke site met een koude full-page cache. Is hij tegen het einde van dat venster merkbaar sneller, dan had je een tijdelijke dip te pakken. Is hij de volgende ochtend nog steeds traag en helpt de cache opnieuw opwarmen niks, dan heeft de update een structurele regressie geïntroduceerd.

Tijdelijke oorzaken (lossen zichzelf op):

• OPcache cold start, totdat workers de nieuwe bestanden opnieuw hebben geparsed
• Full-page en object cache die bij de eerste bezoeken na de purge opnieuw worden opgebouwd
• De alloptions autoload-cache die zichzelf opnieuw vult vanuit wp_options
• Eenmalige databasemigraties die na een core- of plugin-upgrade op de achtergrond draaien
• Het opnieuw genereren van CSS, JavaScript of afbeeldingsvarianten (thumbnail-formaten, critical CSS, asset-bundels)

Structurele oorzaken (blijven totdat je ze aanpakt):

• Een plugin of thema die niet compatibel is met de nieuwe WordPress core-versie, met warnings, retries of fatale fouten die als het kritieke foutmelding-scherm naar boven komen tot gevolg
• Een pluginversie die op elke request nieuw werk toevoegt: een remote licentiecheck, een nieuw analytics-event, een nieuwe hook op een core-API
• Een deprecation warning in de nieuwe code die nu op elke request naar debug.log wordt geschreven, meetbaar duur als dat logbestand op trage storage staat
• Een databasemigratie die niet is voltooid, waardoor de site half op het oude en half op het nieuwe schema draait

Een tijdelijke dip wordt beter naarmate je blijft verversen. Een structurele regressie trekt zich niks aan van hoe vaak je herlaadt.

Wat traag-na-update niet is

De meeste verwarring rond dit probleem ontstaat doordat mensen alle traagheid na een update op één hoop gooien, of de update de schuld geven van iets wat er al was.

• Niet hetzelfde als een algemeen trage site. Was de site vóór de update al traag, dan heeft de update dat niet veroorzaakt. De update heeft misschien een cache geleegd die het onderliggende probleem verborg, maar dát is wat je wilt oplossen. Begin bij het algemene artikel over een trage WordPress-site in plaats van de update te achtervolgen.
• Niet hetzelfde als traag na het installeren van een plugin. Een update verandert bestaande code. Een nieuwe plugin installeren voegt nieuwe code toe. Bij een installatie is de verdachte duidelijk, bij een update is het er één uit tientallen bestanden die veranderden.
• Niet hetzelfde als tegen een worker- of CPU-plafond aanlopen. Een update kan de site over een rand duwen waar hij al dicht tegenaan zat, maar de onderliggende oorzaak is nog steeds dat plafond. Als de eerste traffic piek na de update de PHP-FPM workers uitput of de CPU op het quotum vastspijkert, dan is het plafond verhogen de echte fix, niet de update terugdraaien.
• Niet hetzelfde als "WordPress is zwaarder op nieuwere PHP". Het tegenovergestelde klopt juist. [De PHP-benchmarks van Kinsta (zie PHP-versie wijzigen in WordPress voor de upgrade-procedure)](https://kinsta.com/blog/php-benchmarks/) meten WordPress 6.1 op PHP 8.1 op ruwweg drie keer zoveel requests per seconde als op PHP 5.6. Voelt een site zwaarder na een update, dan is het meestal andersom: oude PHP houdt de site tegen en de update duwde hem over de streep. Valt de traagheid samen met een hostmigratie, dan kan de migratie zelf de oorzaak zijn.
• Niet een signaal dat je meer hosting nodig hebt. Hardware is af en toe wel de bottleneck, maar het hostingpakket de schuld geven is de standaardreflex als de echte oorzaak lastiger te vinden is. Meer CPU en meer RAM repareren geen plugin die zijn upgrade-routine in een lus draait.

Waar je vanaf hier verder kunt lezen

Weet je niet welke laag schuldig is, dan werk je met het algemene artikel over een trage WordPress-site de request-lagen af. Loopt de traagheid gelijk op met een plugin die je net hebt geïnstalleerd, dan helpt het artikel over traag na een plugin-installatie je om hem te isoleren. Crasht de site eerder dan dat hij vertraagt, dan behandelt het artikel over de kritieke foutmelding het pad van de fatale fout.