Een klant belde me deze week. Zijn site was “gewoon trager geworden.” Geen nieuwe plugins, geen redesign, niets veranderd. Alleen maar trager. Ik keek in de database en telde 47.000 post-revisies, 12.000 transients die allang verlopen waren en een options-tabel van acht megabyte. De site draaide al vier jaar zonder één keer databaseonderhoud. Dat zie je vaker dan je denkt.
WordPress slaat alles op. Elke keer dat je een pagina opslaat, maakt het een revisie aan. Elke plugin die data tijdelijk wil bewaren, schrijft een transient. Sommige plugins slaan instellingen op in de options-tabel op een manier die na verloop van tijd uit de hand loopt. Dat is geen bug, dat is gewoon hoe het systeem werkt. Maar het betekent wel dat je er actief iets aan moet doen.
Wat er precies in je database terechtkomt
WordPress gebruikt een relationele database met een handvol kernstabellen. De meeste rotzooi verzamelt zich in drie ervan: wp_posts, wp_postmeta en wp_options.
In wp_posts staan je berichten en pagina’s, maar ook elke revisie van elk bericht. Als je een pagina twintig keer hebt bijgewerkt, staan er twintig revisies in. Standaard is er geen limiet. Bij een site die al vijf jaar actief is, kunnen dat duizenden rijen zijn die je nooit meer nodig hebt.
In wp_options slaan plugins hun instellingen op. Sommige doen dat netjes, met één rij per plugin. Andere schrijven bij elke actie een nieuwe rij, of laten verlopen transients staan. Transients zijn tijdelijke waarden met een vervaldatum, maar WordPress ruimt ze niet automatisch op tenzij er iemand om vraagt. Ze blijven gewoon staan.
Wat revisies met je laadtijd doen
Meer rijen in een tabel betekent langere query’s. Dat klinkt logisch, maar in de praktijk merk je het pas als het al een tijdje mis is. WordPress haalt bij elke paginaweergave data op uit de database. Hoe groter de tabellen, hoe langer dat duurt.
Bij een kleine site met weinig bezoekers valt het nauwelijks op. Maar zodra je caching uitzet, of een pagina opvraagt die niet gecached is, zie je de vertraging direct. Zeker op goedkope shared hosting, waar de databaseserver ook nog eens gedeeld wordt met honderden andere sites.
Revisies zijn het laaghangende fruit. Ze kosten ruimte, vertragen query’s en je gebruikt ze nooit. De meeste klanten weten niet eens dat revisies bestaan.
Revisies beperken via wp-config.php
Je kunt het aantal revisies dat WordPress bewaart instellen in wp-config.php. Voeg deze regel toe:
define('WP_POST_REVISIONS', 5);
Dit zorgt ervoor dat WordPress maximaal vijf revisies per bericht bewaart. Oudere revisies worden automatisch verwijderd als je opslaat. Je kunt ook false instellen om revisies volledig uit te zetten, maar dat is zelden nodig. Vijf is voor de meeste mkb-sites meer dan genoeg.
Dit voorkomt nieuwe ophoping. De bestaande revisies ruim je apart op, via een plugin of een directe SQL-query als je weet wat je doet.
Transients opruimen
Verlopen transients ruimt WordPress op als ze worden opgevraagd. Als ze nooit worden opgevraagd, blijven ze staan. Bij een drukke site met veel plugins kan dat snel oplopen tot duizenden rijen in de options-tabel.
Je kunt transients handmatig verwijderen met een SQL-query:
DELETE FROM wp_options WHERE option_name LIKE '%_transient_%' AND option_name NOT LIKE '%_site_transient_%';
Let op: voer dit alleen uit als je een recente back-up hebt. En controleer daarna of alles nog werkt, want sommige plugins verwachten dat hun transients er nog zijn. In de praktijk gaat het zelden mis, maar controleren kost je dertig seconden.
Als je liever niet direct in de database werkt, zijn er plugins die dit veilig voor je doen. Kies er een die alleen verwijdert wat verlopen is, niet alles in één keer.
De options-tabel als probleemgeval
De options-tabel is de meest onderschatte bron van databaseproblemen. Plugins die slecht zijn geschreven, schrijven bij elke actie een nieuwe rij in plaats van een bestaande rij bij te werken. Na een jaar heb je honderden rijen van dezelfde plugin, allemaal met licht afwijkende namen.
Een ander probleem is autoload. Elke rij in de options-tabel heeft een autoload-veld. Als dat op yes staat, laadt WordPress die waarde bij elke paginaweergave in het geheugen, ook als je hem niet nodig hebt. Sommige plugins zetten alles op autoload. Dat betekent dat WordPress bij elke request megabytes aan data inlaadt die niemand gebruikt.
Je kunt zien hoeveel autoload-data je hebt met deze query:
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';
Als dat getal boven de megabyte uitkomt, heb je een probleem. Bij de klant van deze week was het ruim acht megabyte. Elke paginaweergave laadde acht megabyte aan opties in het geheugen. Dat vreet aan de responstijd.
Hoe je databaseonderhoud inplant
Eenmalig opruimen helpt, maar het probleem komt terug. Je hebt een routine nodig. Dat hoeft niet ingewikkeld te zijn.
Een paar dingen die ik bij elke klant instel:
- Revisielimiet in wp-config.php: één keer instellen, werkt daarna automatisch
- Maandelijkse optimalisatie: de meeste hostingpanelen hebben een knop om tabellen te optimaliseren; dat comprimeert de lege ruimte die achterblijft na het verwijderen van rijen
- Kwartaallijkse controle van de options-tabel: even kijken of er nieuwe autoload-rotzooi is bijgekomen
- Back-up voor je iets aanraakt: altijd, zonder uitzondering
Als je een onderhoudsplugin gebruikt die ook databasetaken kan uitvoeren, schakel dan in elk geval de automatische revisie-opruiming in. Laat de rest handmatig, zodat je weet wat er gebeurt.
Automatisch alles laten opruimen klinkt handig, maar ik heb genoeg klanten gehad waarbij een te agressieve plugin data heeft weggegooid die ze toch nodig hadden. Liever één keer per kwartaal zelf kijken dan achteraf puzzelen wat er is verdwenen.
Wat je na het opruimen merkt
Bij de klant van deze week was het resultaat direct meetbaar. De time-to-first-byte ging van 1,4 seconde naar 0,6 seconde op een niet-gecachede pagina. Dat is zonder enige wijziging aan de server, de code of de hosting. Alleen een schonere database.
Dat is niet altijd zo dramatisch. Bij een site die al redelijk bijgehouden is, merk je minder verschil. Maar bij sites die jaren zonder onderhoud hebben gedraaid, is dit vaak de snelste winst die je kunt boeken zonder geld uit te geven.
Het tweede wat je merkt is dat het WordPress-dashboard sneller reageert. De admin-omgeving maakt ook databasequery’s. Als die queries sneller zijn, reageert de editor sneller, laden de pluginpagina’s sneller en duurt het opslaan van een pagina minder lang. Dat is iets wat klanten direct voelen, ook als ze de technische achtergrond niet begrijpen.
Databaseonderhoud is geen sexy onderwerp. Er is geen plugin die je 40% snelheidswinst belooft en er is geen instelling die je één keer aanzet en daarna nooit meer aan hoeft te denken. Het is gewoon een taak die je periodiek uitvoert, zoals je dat doet met back-ups en updates. Wie dat bijhoudt, heeft minder storingen en minder klanten die bellen met de mededeling dat hun site “gewoon trager is geworden.”