Je winkelwagen is leeg
Producten die je toevoegt, verschijnen hier.
Database vol of traag? Optimaliseer je WordPress-database in 6 stappen en verminder je TTFB met 40–83%. Inclusief tips voor autoload, revisies en transients.
Wordt je site met de dag trager, of loopt phpMyAdmin vast op een enorme tabel? Dan is WordPress
KeurigOnline zegtWordPress
KeurigOnline zegtDatabase
Samenvatting: WordPress-database optimaliseren
Een verwaarloosde WordPress-database vuurt bij elke paginaweergave 20 tot meer dan 200 queries af[1] en kan de onbewaarde laadtijd (TTFB) tot 83% vertragen[1]. Volg de 6 stappen in dit artikel (backup, meten, revisies, transients, autoload, tabellen) om je database 50 tot 80% kleiner te maken[4] en je hosting weer ademruimte te geven.
Steeds meer WordPress-sites lopen tegen de database-limiet van hun shared hosting
KeurigOnline zegtShared hosting
KeurigOnline zegtMySQLUPDATE command denied-foutmelding, een site die geen berichten meer opslaat en een beheerder die er niet meer in kan bewerken[7].
Ook zonder dat drama kost een vervuilde database je gewoon snelheid. Een niet-geoptimaliseerde database vuurt 20 tot 200 queries per pagina af[1], en database-opschoning verbetert laadtijden met 40 tot 83%[1], meer dan caching alleen oplevert (ongeveer 30% winst tegenover 70% voor database-opschoning)[3]. Caching verbergt het probleem, opschoning verhelpt de oorzaak.
In dit artikel doorloop je 6 concrete stappen: van een verplichte backup
KeurigOnline zegtBackup

Elke keer dat een bezoeker een pagina op je WordPress-site opent, doet de server tientallen tot honderden MySQL-queries: berichten ophalen, menu's opbouwen, plugin-instellingen uitlezen. Bij een gemiddelde pagina zijn dat er 20 tot 100, en een WooCommerce
KeurigOnline zegtWooCommerce
Drie tabellen zijn op shared hosting meestal de grootste boosdoeners: wp_options (vervuild met verlopen tijdelijke data), wp_postmeta (metadata van elke plugin die je ooit installeerde) en wp_actionscheduler_actions (achtergrondtaken van WooCommerce)[6]. Een verwaarloosde wp_options-tabel van 50 MB of meer is geen uitzondering, terwijl een schoongehouden tabel ruim onder de 1 MB blijft.
Belangrijk om te begrijpen: caching verbetert vooral de gecachede laadtijd, terwijl zoekmachines en eerste bezoekers de onbewaarde laadtijd ervaren. Uit een audit van 31 WordPress-sites bleef de gecachede TTFB
KeurigOnline zegtTTFB
KeurigOnline zegtCore Web Vitals
Wil je dus echt sneller hosten, dan pak je de database
KeurigOnline zegtDatabase
Let op: sla deze stap nooit over.
Voordat je revisies verwijdert, transients opruimt of tabellen optimaliseert, maak je een volledige backup. Dat kan op twee snelle manieren. Via het hostingpaneel (bij DirectAdmin
KeurigOnline zegtDirectAdmin
Zodra de backup staat, weet je zeker dat elke volgende stap veilig terug te draaien is. Voor een bredere beveiligingscheck van je site, inclusief backup-strategie, lees je hoe je je WordPress-site beveiligt.
Je kunt pas winst boeken als je weet waar je staat. Er zijn twee snelle meetmethoden.
Open phpMyAdmin, selecteer je database en bekijk het tabeloverzicht. In de kolom "Grootte" zie je direct per tabel hoeveel ruimte die inneemt, en onderaan de totale databasegrootte.
Bij KeurigOnline-pakketten zie je de databasegrootte direct in het control panel, zonder dat je phpMyAdmin hoeft te openen.
Als richtlijn: een schoongehouden site blijft doorgaans onder de 100 MB. Een verwaarloosde site met rond de 100.000 berichten kan uitgroeien tot 500 MB à 2,4 GB[1].
Doe ook meteen een nulmeting van je autoload-data via Gereedschappen > Site Health > Geavanceerd in je WordPress-dashboard. Sinds WordPress 6.6 toont deze tool zelf een alarm zodra de autoload-data boven de 800 KB uitkomt[5], wat je in stap 4 gaat oplossen.
Tip: zit je database al boven de helft van je hostinglimiet? Dan is opschoning urgent, niet optioneel.
WordPress slaat bij elke keer dat je een concept opslaat automatisch een kopie op als revisie, zonder standaardlimiet. Bij een actief bewerkte site loopt dat snel op: revisies alleen al kunnen wp_posts met 30 tot 60% laten groeien[4], puur aan overtollige data.
Drie manieren om dit aan te pakken, van makkelijk naar technisch:
Deze gratis plugin verwijdert bestaande revisies met één klik, via een overzichtelijk dashboard.
define('WP_POST_REVISIONS', 5);Deze regel zorgt dat WordPress
KeurigOnline zegtWordPress
wp post delete $(wp post list --post_type='revision' --format=ids)Verwijdert in één commando alle bestaande revisies.
Revisies verwijderen is onomkeerbaar: je bewerkingsgeschiedenis is daarna weg. Dankzij de backup uit stap 0 is dat geen probleem.
Transients zijn tijdelijke cache
KeurigOnline zegtCachewp_options opslaan, met een vervaldatum. Het probleem: WordPress verwijdert verlopen transients niet proactief. Ze blijven gewoon staan, request na request, totdat iemand ze expliciet opruimt. Op sites met weinig verkeer draait WordPress' pseudo-cron (wp-cron), dat normaal opruimtaken triggert, bovendien zelden genoeg om dit bij te houden.
Het resultaat: een wp_options-tabel die kan uitgroeien tot 50 MB of meer[4].
DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_%'
OR option_name LIKE '\_transient\_timeout\_%';WP-Optimize of Advanced Database Cleaner ruimen verlopen transients op met een enkele klik, zonder dat je zelf SQL hoeft te schrijven.
Na opschoning kan wp_options terugvallen van 50 MB naar minder dan 1 MB, wat op shared hosting 100 tot 300 ms TTFB-winst oplevert[4].

Definitie: autoload-data zijn opties in wp_options met autoload='yes'. WordPress laadt die bij elke paginaweergave automatisch in het geheugen, ongeacht of die specifieke pagina ze nodig heeft.
Dit is de meest onderschatte snelheidsrem in WordPress. Een contactformulier-plugin, een pagebuilder als Divi of een WooCommerce-instelling kan moeiteloos honderden kilobytes aan autoload-data achterlaten, en dat gewicht sleep je bij elk enkel verzoek mee, nog vóór caching, thema of andere plugins in beeld komen.
Meet je huidige autoload-belasting met deze query in phpMyAdmin:
SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload = 'yes';Toets de uitkomst aan deze normen:
Autoload-normen
Spoor de grootste boosdoeners op met een query die per optie de grootte toont, gesorteerd van groot naar klein:
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 20;Pagebuilders zoals Divi en uitgebreide WooCommerce-configuraties staan hier vaak bovenaan. Voor opties die je niet bij elk request nodig hebt, zet je autoload uit (via SQL of via een plugin als WP-Optimize, die dit veilig per optie beheert) in plaats van de optie te verwijderen. Zit je al op WordPress 6.6 of nieuwer, gebruik dan het ingebouwde Site Health-alarm als vast controlepunt bij elke sweep.
Na talloze inserts en deletes ontstaan er kleine "gaten" in de opslagstructuur van een tabel: tabel-fragmentatie. OPTIMIZE TABLE defragmenteert de tabel en herberekent de statistieken
KeurigOnline zegtStatistieken
Vink alle tabellen aan onderaan het tabeloverzicht en kies "Optimaliseer tabel" in het dropdown-menu.
Ga naar het tabblad "Database" en klik op "Optimaliseer databasetabellen". Eén klik, geen SQL nodig.
wp db optimizeTip: gebruik je InnoDB (de standaard in moderne MySQL en MariaDB)? Dan voert OPTIMIZE TABLE feitelijk een ALTER TABLE … ENGINE=InnoDB uit. Bij grote tabellen kost dat even tijd, dat is normaal en veilig. MyISAM-tabellen krimpen direct zichtbaar in bestandsgrootte; bij InnoDB zit de winst vooral in bijgewerkte statistieken, minder in ruimte.
Database-optimalisatie is geen eenmalige klus, want revisies, transients en autoload-bloat bouwen zich vanzelf weer op. Zet daarom een vast schema:
Stel in de plugin-instellingen een dagelijks, wekelijks of maandelijks schema in, desgewenst per tabel-type.
wp cron event schedule wp_optimize_scheduled_optimize now weeklyMinimaal 1 keer per maand voor een gemiddelde site. Draai je WooCommerce of een druk nieuwsblog, schakel dan over op een wekelijks schema.
Monitor na het instellen van automatisering de databasegrootte in je hostingpaneel, zo zie je bij de volgende sweep precies hoeveel ruimte er is teruggewonnen.
Zie je de foutmelding UPDATE command denied of kun je ineens geen berichten meer opslaan of bewerken? Dan heeft MySQL
KeurigOnline zegtMySQL
Vraag je hostingpaneel of support om de databaselimiet tijdelijk te verhogen. Zo kan je site weer schrijven en heb je ruimte om op te schonen.
Doorloop direct stap 1 tot en met 6 hierboven. Na een volledige opschoning is een reductie van 50 tot 80% normaal voor een database die nooit eerder is onderhouden[4].
Zit je database na volledige opschoning nog steeds boven de limiet, dan is de site simpelweg te groot voor het huidige pakket. Een upgrade naar een hoger hostingpakket, of overstappen naar managed WordPress hosting bij KeurigOnline, is dan de duurzame stap: minder handmatig onderhoud en meer ruimte om te groeien.
Resultaat per stap
wp_posts[4].wp_options van 50 MB+ naar minder dan 1 MB[4], 100 tot 300 ms TTFB-winst.Opgeteld is een reductie van 50 tot 80% in databasegrootte normaal voor een verwaarloosde site[4], met een onbewaarde TTFB die tot 83% sneller kan worden[1]. Wil je naast de database ook de rest van je site versnellen, lees dan verder over de 5 redenen waarom je WordPress-site zo langzaam is of vergelijk serveromgevingen in LiteSpeed versus Apache.
Minimaal 1 keer per maand voor een gemiddelde site. Heb je WooCommerce
KeurigOnline zegtWooCommerce
Ja. Verwijder je bestaande revisies, dan raak je de bewerkingsgeschiedenis kwijt, maar de gepubliceerde inhoud blijft intact. Maak wel altijd eerst een backup
KeurigOnline zegtBackup
Transients zijn tijdelijke cache
KeurigOnline zegtCachewp_options, met een vervaldatum. WordPress verwijdert ze niet proactief: ze blijven staan totdat je ze expliciet opschoont, waardoor wp_options kan uitgroeien tot 50 MB of meer.
Opties met autoload=yes worden bij elke paginaweergave in het geheugen geladen, ook als de pagina ze niet nodig heeft. Boven de 800 KB toont WordPress 6.6 een Site Health-alarm; bij 5 MB of meer loopt elk request 100 tot 200 ms extra vertraging op.
WP-Optimize is de meest gebruikte gratis optie: het combineert tabel-optimalisatie, revisies verwijderen, transients opruimen en een automatisch schema in één interface. Alternatieven zijn Advanced Database Cleaner en de ingebouwde databasereiniging van LiteSpeed Cache
KeurigOnline zegtLiteSpeed Cache
Vraag eerst om de limiet tijdelijk te verhogen, zodat je site weer kan schrijven. Doorloop daarna direct stap 1 tot en met 6. Na volledige opschoning is 50 tot 80% groottereductie realistisch; is dat niet genoeg, overweeg dan een hoger hostingpakket.