WordPress traag na een update – oorzaken en context

Waarom wordt je site trager na een update?

Updates zijn essentieel voor veiligheid en nieuwe functies, maar ze brengen ook technische wijzigingen met zich mee. Die wijzigingen kunnen onbedoeld invloed hebben op de prestaties van je site. Hier zijn de meest voorkomende redenen waarom WordPress trager kan worden na een update:

• Nieuwe of zwaardere code: Een update (van WordPress core of een plugin) kan nieuwe functionaliteit toevoegen. Dat betekent vaak meer code die moet worden uitgevoerd. Nieuwe features gaan soms gepaard met extra scripts en stylesheets die geladen worden op je pagina’s. Meer JavaScript of CSS betekent dat een pagina net wat langer nodig heeft om te laden. Bijvoorbeeld, er kan een extra script bijgekomen zijn dat elke paginaopvraag iets doet. Al die extra taken stapelen op en kunnen de site iets verzwaren.
• Extra database-queries: Database-queries (opvragen van data uit de database) zijn nodig om je pagina’s te tonen, maar na een update kunnen er meer of complexere queries bij komen. Stel dat een plugin na een update op elke pageload een extra query draait om iets te controleren – dat kost tijd. Zo zag ik eens een webshop die na een update plots traag laadde; de oorzaak bleek één specifieke database-query die een bottleneck vormde. Met andere woorden, één zo’n zwaardere query kan alles ophouden. Soms is de oplossing dan om een index toe te voegen of caching in te zetten, maar het illustreert hoe een enkele codewijziging in een update de hele site kan vertragen.
• Invalideren van caches: WordPress-sites maken vaak gebruik van caching (tijdelijke opslag van gegenereerde pagina’s of data om sneller te kunnen bedienen). Bij een update worden caches vaak geleegd of ongeldig. Een plugin-update kan bijvoorbeeld de pagina-cache wissen om te voorkomen dat bezoekers verouderde content zien. Ook object caching (het tijdelijk in geheugen opslaan van database-resultaten voor snelle toegang) kan na een update worden gereset. Het gevolg: de eerste keer dat pagina’s weer geladen worden, moeten ze volledig opnieuw opgebouwd worden. Totdat de cache zich weer “warm loopt”, ervaar je tragere laadtijden. Het is alsof de site even alles van nul af aan moet berekenen. Hostingfeatures als Auto Purge Cache on Update wissen bijvoorbeeld bewust alle cache na een plugin- of thema-update. Dit is goed om up-to-date content te tonen, maar het zorgt er wel voor dat pagina’s vlak na de update wat langzamer zijn omdat de cache zich opnieuw moet vullen.
• Achtergrondprocessen na updates: Sommige updates voeren eenmalig zware taken uit op de achtergrond. Denk aan het bijwerken van de databankstructuur of het opnieuw genereren van bepaalde bestanden. WordPress zelf doet dit soms na een grote core-update (je ziet dan meldingen als “Database update vereist”, waarna WordPress op de achtergrond tabellen bijwerkt). Plugins kunnen iets soortgelijks doen: een bekende page-builder plugin of een e-commerce plugin als WooCommerce start na een update vaak een database-upgrade proces. Tijdens zo’n proces worden bijvoorbeeld nieuwe velden berekend of data omgezet naar een nieuw formaat. Zo’n achtergrondtaak slurpt tijdelijk serverresources en kan je site in die periode traag maken. Hetzelfde geldt voor het hergenereren van CSS/JS-bestanden of beeldbestanden door sommige thema’s en plugins na een update.
• Veranderde hooks en routines: Onder de motorkap werkt WordPress met hooks (momenten waarop extra code “inhaakt”). Een core-update kan nieuwe hooks introduceren of het gedrag van bestaande hooks wijzigen. Geüpdatete plugins en thema’s haken mogelijk op nieuwe punten in. Dit betekent dat er onverwacht extra code draait. Bijvoorbeeld: een plugin die na de update ineens op elke admin-pagina een controle uitvoert via een nieuwe hook, kan het beheeromgeving trager laten aanvoelen. Dergelijke veranderingen zijn technisch van aard en voor de gebruiker niet zichtbaar, behalve dan dat dingen ineens langzamer gaan.
• Plugins of thema’s die zwaarder geworden zijn: Het kan voorkomen dat een plugin-update je site traag maakt. Soms voegen ontwikkelaars nieuwe functies toe die net wat minder geoptimaliseerd zijn, of er sluipen inefficiënties in. Een voorbeeld: een veiligheidsplugin kan na een update extra scans gaan doen, of een analyse-plugin gaat meer data loggen. Eén “zware” plugin is genoeg om de laadtijd flink omhoog te trekken. Ook kan de combinatie van plugins ongunstiger worden (zie volgende punten).
• Compatibiliteitsproblemen: Niet alle plugins en thema’s zijn meteen optimaal afgestemd op elkaar na updates. Een update kan ervoor zorgen dat twee onderdelen van je site niet meer lekker samenwerken. Het gevolg is niet per se dat er iets “kapot” gaat; vaak merk je het alleen aan vertraging. Bijvoorbeeld, een plugin die niet volledig compatibel is met de nieuwste WordPress-versie kan langere database calls nodig hebben of foutjes veroorzaken die herhaaldelijke pogingen triggeren. Conflicten tussen plugins onderling kunnen een domino-effect geven van verborgen performance issues. Denk aan dubbele queries of code die in loops blijft draaien. Omdat dit achter de schermen gebeurt, zie je geen foutmelding – alleen een site die hapert.
• Oudere serveromgeving vs nieuwe software: Dit is meer een indirecte factor, maar ik noem hem toch. WordPress-core updates gaan vaak hand in hand met adviezen voor nieuwere PHP-versies of MySQL-versies. Als je na een update nog op een verouderde PHP-versie draait, kan de site trager aanvoelen puur omdat de nieuwe WordPress-code zwaarder is voor die oude PHP. (Nieuwere PHP-versies zijn meestal sneller; bijvoorbeeld, PHP 8 is tot 40% sneller dan PHP 7 in WordPress-context.) Je site kan dus performance inleveren na een update wanneer de server niet up-to-date is met wat de software verwacht. Dit ligt niet direct aan WordPress zelf, maar aan de mismatch tussen nieuwe code en oude omgeving.

Kort samengevat: een update verandert de “achterkant” van je website. Meer features en veiligheid, maar soms ook meer belasting. Extra scripts, zwaardere queries, geleegde caches, achtergrondklusjes en compatibiliteitsissues – al die dingen kunnen ervoor zorgen dat je WordPress site traag aanvoelt na het updaten.

Hoe herken je prestatieproblemen na updates?

Het is belangrijk om de symptomen te herkennen: waaraan merk je dat je site last heeft van updategerelateerde traagheid? En hoe onderscheid je dit van “gewone” langzaamheid? Enkele typische tekenen op een rij:

• Traag WordPress-dashboard (wp-admin): Veel gebruikers merken als eerste dat de beheerkant traag is na een update. Je klikt op “Bewerk bericht” of navigeert tussen menu’s en het duurt ineens lang voordat iets gebeurt. Bijvoorbeeld het opslaan van een pagina duurt nu 5–10 seconden waar dat eerder vrijwel direct was. Dit kan zich uiten in knoppen die grijs blijven (onklikbaar) terwijl je wacht tot WordPress klaar is met laden. In het voorbeeld van eerder zag ik dat bij een product bewerken de Update-knop tijdelijk niet klikbaar was en pas na een minuut verscheen – duidelijk een symptoom van een vertragend proces op de achtergrond. Trage adminpagina’s duiden erop dat de server het zwaar heeft met een taak (mogelijk een plugin-conflict of een background update routine).
• Langzame frontend voor bezoekers: Ook de voorkant van de site – datgene wat je klanten of bezoekers zien – kan traag laden na een update. Pagina’s doen er merkbaar langer over om te verschijnen. Waar je homepage eerst in ~2 seconden in beeld was, duurt het nu misschien 5–6 seconden of langer. Beelden kunnen traag laden, of onderdelen van de pagina komen pas met vertraging tevoorschijn. Soms zien gebruikers tijdelijk een blanco pagina of laden onderdelen stukje-bij-beetje. In ernstige gevallen krijg je zelfs time-outs (bijvoorbeeld een 504 Gateway Timeout error) als pagina’s het tijdsbudget overschrijden. Dat zijn duidelijke rode vlaggen dat er iets performance-gerelateerd mis is gegaan na de update.
• Haperingen bij specifieke acties: Naast algemene traagheid kun je het merken bij bepaalde handelingen. Voorbeelden: een WooCommerce-webshop die na een update heel langzaam producten filtert of toevoegt aan de winkelmand. Of een zoekfunctie op de site die vrijwel onbruikbaar traag is geworden. Als één specifiek onderdeel van de site stroperig reageert na een update (terwijl de rest oké lijkt), wijst dat vaak op een bepaalde plugin of query die daarachter zit. Bijvoorbeeld, alleen de zoekpagina is traag omdat een vernieuwde zoekplugin nu een minder efficiënte query gebruikt.
• Verhoogde serverbelasting: Dit is wat minder zichtbaar voor een leek, maar noemenswaardig: als je toegang hebt tot je hostingpanel of een monitoring-tool, zie je na een update wellicht pieken in CPU- of geheugengebruik. De site voelt dan traag omdat de server tegen zijn limieten aan zit. Sommige gebruikers krijgen van hun host een bericht dat hun account veel resources verbruikt. Dit kan komen door een plugin die na update meer CPU vraagt, of een cronjob die blijft draaien. Je hoeft dit niet actief te monitoren, maar het is een signaal: hoge serverload na een update = iets aan de code vraagt meer dan voorheen.
• Tijdelijk vs. langdurig traag: Let er ten slotte op wanneer de traagheid optreedt. Direct na de update en zakt het later af, of blijft het continu langzaam? Dit verschil is een belangrijk symptoom op zich, waar ik in de volgende sectie dieper op inga.

In het kort merk je prestatieproblemen na updates vooral aan “alles voelt zwaarder”: het beheren van je site kost meer tijd, pagina’s laden trager, en in ergere gevallen krijg je foutmeldingen door tijdsoverschrijding. Het gevoel dat “WordPress is langzaam na de update” is dus niet inbeelding – er is echt iets veranderd dat deze symptomen veroorzaakt.

Is de vertraging tijdelijk of structureel?

Niet elke vertraging na een update is blijvend. Soms is het een tijdelijke dip en herstelt de snelheid zichzelf, soms blijft het probleem onverminderd. Hoe kun je dat onderscheid maken?

Tijdelijke vertraging

In veel gevallen is de site vooral vlak na de update traag. Dit kan minuten tot enkele uren duren. Oorzaken van tijdelijke traagheid zijn bijvoorbeeld het opnieuw opbouwen van caches of het draaien van een eenmalige database-upgrade. Je merkt dan dat na verloop van tijd de boel weer opknapt. Voorbeeld: je update ’s ochtends een plugin en ziet dat de site daarna langzaam is; later die dag gaat het alweer beter. Dat duidt erop dat het vooral de cache-warming of achtergrondtaken waren. Een praktisch kenmerk: de eerste paar paginalaadjes na de update zijn het traagst (cold cache), maar elke volgende bezoeker merkt verbetering omdat de cache zich opwarmt. Ook zie je vaak dat na afronding van een upgrade-proces (soms toont een plugin of WordPress een melding als “update voltooid”) de serverbelasting daalt en de snelheid terugkomt. Tijdelijke vertraging is dus een soort “na-ijleffect” van de update die vanzelf wegtrekt zodra alles weer op orde is.

Structurele (blijvende) vertraging

Helaas zijn er situaties waar de site blijft slepen na een update. Ook dagen later is WordPress langzaam. Dit wijst op een structureel performanceprobleem door de update. Bijvoorbeeld een codeverandering die constant invloed heeft: een plugin die voortaan elke pagina-opvraag een zware berekening doet, of een incompatibiliteit die voor elke bezoeker extra overhead geeft. Als je merkt dat zelfs na het weer opbouwen van caches en een herstart van de server de site traag blijft, dan is er een blijvende bottleneck geïntroduceerd. Dat kan betekenen dat je een bepaalde plugin moet verdachten of dat de nieuwe WordPress-versie iets doet wat je hostingomgeving niet lekker trekt. Structurele problemen herken je aan consistent slechte performance: ieder bezoek, elk klikje in wp-admin, op elk moment van de dag blijft stroperig. In zo’n geval is nader onderzoek nodig (of hulp inschakelen) om de oorzaak te pinpointen. Hoe test je dit zelf? Een handige manier is om, na een update, je site even de tijd te geven en vervolgens te kijken: is het morgen nog steeds traag? Je kunt ook een cache-plugin installeren (als je die nog niet had), zodat je na de eerste trage lading ziet of het met cache sneller wordt. Als zelfs met caching aan de site traag blijft, zit er waarschijnlijk iets structureel fout. Merk je daarentegen dat de snelheid per pagina weer normaal wordt na één keer laden (d.w.z. de tweede keer dat je dezelfde pagina opent gaat het vlotter), dan was het mogelijk een tijdelijk cache-opbouw dingetje.

Onzichtbare oorzaken en wat kun je daaraan doen

Een van de frustrerende dingen is dat je niet altijd meteen ziet waardoor de site traag is na een update. Er knippert geen waarschuwingslampje dat zegt “plugin X is de schuldige” of “query Y duurt te lang”. De oorzaken zijn vaak verborgen in de achterkant en vragen speurwerk. Door mijn werk heb ik geleerd om “onder de motorkap” te kijken. Bijvoorbeeld via logbestanden of performance-profiler tools (zoals Query Monitor). Daarmee kun je ontdekken of er ineens honderden database-query’s extra draaien, of dat een bepaald script heel veel tijd kost. Zo’n analyse is voor een doorsnee gebruiker best technisch, maar het komt er vaak op neer dat één of twee elementen de boosdoener zijn. Eerder noemde ik al plugin-conflicten: twee plugins die elkaar in de weg zitten na een update. Dat resulteert bijvoorbeeld in redundante database calls en clashing queries – dus dubbele opvragingen of tegenstrijdige verzoeken die de database ophouden. Jij ziet alleen de vertraging, maar niet het gevecht achter de schermen.

Het kan ook zijn dat een update een sluimerend probleem aan het licht brengt. Stel, je had altijd al een plugin die niet zo efficiënt was, maar door een core-update wordt die inefficiëntie ineens kritischer (bijv. WordPress voert nu vaker een bepaalde functie uit waar die plugin iets mee doet). Zonder diep in de code te duiken, is dat voor jou onzichtbaar. Je merkt alleen “mijn WordPress is traag na deze update, maar ik zie geen fouten”. Wat kun je als gebruiker hiermee? Allereerst begrijpen dat de oorzaak niet altijd voor de hand ligt. Het ligt niet altijd aan “de server” of aan één duidelijk iets. Soms is het echt een samenspel van factoren. Ik adviseer om systematisch te kijken: trad de traagheid echt op direct na het updaten van een specifieke plugin of thema? Zo ja, dan heb je een sterke aanwijzing dat díe de boosdoener is. Je zou tijdelijk die plugin kunnen deactiveren om te zien of dat scheelt (maar doe dit alleen als test, en niet op een live site zonder backup!). In compatibiliteitsproblemen is vaak één component de katalysator voor problemen met een ander – lastig zelf te vinden, maar een ervaren WordPress-specialist kan dit uitpluizen door tests op een staging-omgeving (een kopie van je site) te draaien en plugins om de beurt te activeren, of door profileringstools te gebruiken.

Belangrijk om te benadrukken: je bent niet gek als je vertraging voelt maar niks geks ziet. Het gebeurt regelmatig dat na een update performance-issues spelen die je niet direct kunt aanwijzen. Op het officiële WordPress-forum wordt compatibiliteit met plugins genoemd als een veelvoorkomende oorzaak van plotselinge traagheid. Met andere woorden: de nieuwste update + jouw bestaande plugins = een niet ideale mix, en dat resulteert in een tragere site. Als je dit begrijpt, ben je al halverwege naar een oplossing. Je weet dan dat je moet zoeken in de richting van plugin-versies, database-activiteiten of cachinginstellingen, in plaats van te denken dat je gewoon “meer hosting” nodig hebt (wat hostingproviders soms als eerste roepen als je site traag is). Vaak is de hardware niet het probleem, maar de software-interactie wel.