WordPress-database optimaliseren: tot 80% kleiner in 6 stappen

Wordt je site met de dag trager, of loopt phpMyAdminKeurigOnline zegtphpMyAdminphpMyAdmin is een gratis webapplicatie waarmee je MySQL- en MariaDB-databases in je browser beheert. vast op een enorme tabel? Dan is WordPressKeurigOnline zegtWordPressWordPress is een open-source contentmanagementsysteem (CMS) geschreven in PHP, waarmee je eenvoudig websites en blogs kunt bouwen en beheren.-databaseKeurigOnline zegtDatabaseEen database is een georganiseerde verzameling gegevens die elektronisch wordt opgeslagen en beheerd. optimaliseren de snelste weg naar een merkbaar snellere site: een verwaarloosde database vuurt bij elke paginaweergave tientallen tot honderden onnodige queries af, en dat kost je direct laadtijd en hosting-ademruimte. Dit artikel loopt in 6 concrete stappen door hoe je die database weer terugbrengt tot gezonde proporties, structureel in plaats van met caching gemaskeerd.

Steeds meer WordPress-sites lopen tegen de database-limiet van hun shared hostingKeurigOnline zegtShared hostingShared hosting is een hostingvorm waarbij meerdere websites dezelfde serverresources delen. aan: doorgaans 500 MB tot 1 GB^[6]. Is die limiet bereikt, dan weigert MySQLKeurigOnline zegtMySQLMySQL is een open-source relationeel databasebeheersysteem (RDBMS) dat gegevens opslaat in tabellen. nieuwe schrijfacties. Het gevolg: een fatale UPDATE 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 backupKeurigOnline zegtBackupEen backup is een reservekopie van digitale gegevens die je kunt terugzetten bij dataverlies of storingen. tot het automatiseren van je onderhoud, met een noodplan voor als je limiet nu al bereikt is.

Waarom de database de grootste snelheidsrem van je hosting is

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, pluginKeurigOnline zegtPluginEen plugin is een uitbreiding die je aan software zoals WordPress toevoegt om er een nieuwe functie bij te krijgen.-instellingen uitlezen. Bij een gemiddelde pagina zijn dat er 20 tot 100, en een WooCommerceKeurigOnline zegtWooCommerceWooCommerce is de gratis e-commerce plugin voor WordPress. Bouw een professionele webshop met producten, betalingen en verzending — zonder technische kennis.-productpagina vuurt er zelfs 200 of meer af^[1]. Wordt de database nooit opgeschoond, dan gaat elke query trager: tabellen raken gefragmenteerd, en optiedata die WordPress bij elk verzoek meelaadt (autoload) groeit ongemerkt uit tot enkele megabytes.

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 TTFBKeurigOnline zegtTTFBTTFB (Time to First Byte) meet de tijd tussen een HTTP-verzoek en de eerste byte van het serverantwoord. nauwelijks veranderen na database-opschoning (90 ms naar 85 ms), terwijl de onbewaarde TTFB daalde van gemiddeld 870 ms naar 540 ms^[2]. En dat onbewaarde pad is precies het pad dat meetelt voor je Core Web VitalsKeurigOnline zegtCore Web VitalsCore Web Vitals zijn drie meetwaarden van Google voor de laadsnelheid, reactiesnelheid en stabiliteit van een pagina. en dus je ranking. In benchmarks tussen een geoptimaliseerde en een niet-geoptimaliseerde database liep de TTFB terug van 1,8 seconden naar 0,3 seconden (83% sneller), met 127 versus 34 queries per pagina (73% minder)^[1].

Wil je dus echt sneller hosten, dan pak je de databaseKeurigOnline zegtDatabaseEen database is een georganiseerde verzameling gegevens die elektronisch wordt opgeslagen en beheerd. aan naast de andere maatregelen om je WordPress sneller te maken. De 6 stappen hieronder lopen op van makkelijk naar technisch.

Stap 0: maak eerst een volledige backup

Voordat je revisies verwijdert, transients opruimt of tabellen optimaliseert, maak je een volledige backup. Dat kan op twee snelle manieren. Via het hostingpaneel (bij DirectAdminKeurigOnline zegtDirectAdminDirectAdmin is een webhosting control panel ontwikkeld door JBMC Software als kostenefficiënt en gebruiksvriendelijk alternatief voor cPanel. of cPanel is dit doorgaans één klik; bij KeurigOnline-pakketten staat deze optie standaard klaar in het control panel) of via een plugin zoals UpdraftPlus of All-in-One WP Migration.

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.

Stap 1: meet je huidige database-grootte

Je kunt pas winst boeken als je weet waar je staat. Er zijn twee snelle meetmethoden.

Via phpMyAdmin

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.

Via het hostingpaneel

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.

Stap 2: verwijder onnodige post-revisies

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:

1. WP-Optimize (aanbevolen voor beginners)

Deze gratis plugin verwijdert bestaande revisies met één klik, via een overzichtelijk dashboard.

2. wp-config.php (toekomstige opslag begrenzen)

define('WP_POST_REVISIONS', 5);

Deze regel zorgt dat WordPressKeurigOnline zegtWordPressWordPress is een open-source contentmanagementsysteem (CMS) geschreven in PHP, waarmee je eenvoudig websites en blogs kunt bouwen en beheren. voortaan nooit meer dan 5 revisies per bericht bewaart.

3. WP-CLI (voor gevorderden)

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.

Stap 3: ruim verlopen transients op

Transients zijn tijdelijke cacheKeurigOnline zegtCacheEen cache is een tijdelijke opslaglaag die veelgebruikte gegevens bewaart voor snellere toegang en betere prestaties.-waarden die plugins in wp_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].

Voor gevorderden: handmatig via phpMyAdmin

DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_%'
OR option_name LIKE '\_transient\_timeout\_%';

Voor beginners: via een plugin

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].

Stap 4: fix autoload-bloat (de verborgen snelheidsrem bij elk request)

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 phpMyAdminKeurigOnline zegtphpMyAdminphpMyAdmin is een gratis webapplicatie waarmee je MySQL- en MariaDB-databases in je browser beheert.:

SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload = 'yes';

Toets de uitkomst aan deze 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.

Stap 5: optimaliseer de databasetabellen zelf (OPTIMIZE TABLE)

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 statistiekenKeurigOnline zegtStatistiekenStatistieken (websitestatistieken) zijn cijfers over je websitebezoekers, zoals aantallen, populaire pagina's en herkomst. die MySQL gebruikt om queries efficiënt uit te voeren.

1. Via phpMyAdmin

Vink alle tabellen aan onderaan het tabeloverzicht en kies "Optimaliseer tabel" in het dropdown-menu.

2. Via WP-Optimize

Ga naar het tabblad "Database" en klik op "Optimaliseer databasetabellen". Eén klik, geen SQL nodig.

3. Via WP-CLI

wp db optimize

Stap 6: automatiseer het onderhoud

Database-optimalisatie is geen eenmalige klus, want revisies, transients en autoload-bloat bouwen zich vanzelf weer op. Zet daarom een vast schema:

1. WP-Optimize scheduler (aanbevolen voor de meeste sites)

Stel in de pluginKeurigOnline zegtPluginEen plugin is een uitbreiding die je aan software zoals WordPress toevoegt om er een nieuwe functie bij te krijgen.-instellingen een dagelijks, wekelijks of maandelijks schema in, desgewenst per tabel-type.

2. WP-CLI en cron (voor servers en VPS-beheerders)

wp cron event schedule wp_optimize_scheduled_optimize now weekly

Aanbevolen frequentie

Minimaal 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.

Wat als je hosting-limiet al bereikt is? (noodplan)

Zie je de foutmelding UPDATE command denied of kun je ineens geen berichten meer opslaan of bewerken? Dan heeft MySQLKeurigOnline zegtMySQLMySQL is een open-source relationeel databasebeheersysteem (RDBMS) dat gegevens opslaat in tabellen. je database op slot gezet omdat de limiet bereikt is^[7].

Kortetermijnoplossing

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.

Structurele fix

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.

Samenvatting: wat levert WordPress-database optimaliseren op?

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.

Veelgestelde vragen over WordPress-database optimaliseren