Bestellen
Hosting
Domeinnaam
Ondersteuning
Ontdek

Op deze pagina

Blog / Hosting · · ~11 min lezen

WordPress-database optimaliseren: sneller hosten in 6 stappen

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.

Geschreven door: Pablo Cleij Pablo Cleij
Deel dit artikel

Wordt je site met de dag trager, of loopt phpMyAdmin 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.

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

Hand tekent een touw los waardoor een kar vol stenen wegvalt en sneller rijdt

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, plugin-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 Google's belangrijkste metrics voor website-ervaring en snelheid. 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

Let op: sla deze stap nooit over.

  • Een mislukte opschoning zonder backup kan berichten, instellingen of een volledige site kosten.
  • Backup zowel de database als de bestanden, niet alleen de een van de twee.

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.

Tip: zit je database al boven de helft van je hostinglimiet? Dan is opschoning urgent, niet optioneel.

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)

Koerier zeult telkens een enorme kist mee voor het afleveren van één klein briefje

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

  • 200 tot 500 KB: gezond, geen actie nodig.
  • Meer dan 800 KB: WordPress 6.6 toont zelf een Site Health-alarm ("Autoloaded options could affect performance")[5].
  • Meer dan 5 MB: kritiek, met 100 tot 200 ms extra vertraging op elk request[3].

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 laten zien hoe bezoekers je website gebruiken. 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

Tip: 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.

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 plugin-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?

Resultaat per stap

  1. Backup: geen ruimtewinst, wel de garantie dat elke stap terug te draaien is.
  2. Meten: geen winst, wel een nulmeting om tegen af te zetten.
  3. Revisies verwijderen: 30 tot 60% kleiner wp_posts[4].
  4. Transients opruimen: wp_options van 50 MB+ naar minder dan 1 MB[4], 100 tot 300 ms TTFB-winst.
  5. Autoload fixen: tot 100 tot 200 ms minder vertraging per request[3].
  6. Tabellen optimaliseren: minder fragmentatie, snellere queries.
  7. Automatiseren: resultaat blijft behouden zonder handmatig werk.

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

Hoe vaak moet ik mijn WordPress-database optimaliseren?

Minimaal 1 keer per maand voor een gemiddelde site. Heb je WooCommerceKeurigOnline zegtWooCommerceWooCommerce is de gratis e-commerce plugin voor WordPress. Bouw een professionele webshop met producten, betalingen en verzending — zonder technische kennis. of een druk nieuwsblog, schakel dan een wekelijks schema in via bijvoorbeeld WP-Optimize.

Is het veilig om post-revisies te verwijderen?

Ja. Verwijder je bestaande revisies, dan raak je de bewerkingsgeschiedenis kwijt, maar de gepubliceerde inhoud blijft intact. Maak wel altijd eerst een backupKeurigOnline zegtBackupEen backup is een reservekopie van digitale gegevens die je kunt terugzetten bij dataverlies of storingen., zoals in stap 0.

Wat zijn transients en waarom hopen ze op?

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

Wat is autoload-data en waarom is dat een probleem?

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.

Welke plugin is het beste voor WordPress-database-optimalisatie?

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 CacheKeurigOnline zegtLiteSpeed CacheLiteSpeed Cache is een server-level cachingoplossing die dynamische pagina's opslaat als statische HTML-bestanden..

Wat als mijn database-limiet bij mijn host al bereikt is?

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.

Bronnen