wp_options autoload — de sluipmoordenaar van trage WordPress-sites

Wat is wp_options eigenlijk?

WordPress slaat al zijn site-instellingen op in één enkele database-tabel: wp_options. Niet je posts, niet je users, alleen instellingen. Daar staan dingen in als je site-naam, je permalink-structuur, je actieve theme, je plugin-instellingen, API-keys, cache-data, en nog ongeveer 200 andere kleine waarden.

De tabel heeft vier kolommen:

option_id     INT       (auto-incrementing ID)
option_name   VARCHAR   (de naam, bv. "siteurl")
option_value  LONGTEXT  (de waarde — kan tot 4 GB groot zijn)
autoload      VARCHAR   ("yes" of "no")

Die laatste kolom — autoload — is waar het misgaat.

Wat doet autoload?

Bij elke pageload op je WordPress-site (elke pagina, elke post, elke admin-pagina, elke AJAX-call) doet WordPress één enkele query in wp_options:

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Het resultaat van die query wordt vervolgens vóór alles geladen in PHP-memory, zodat plugins en themes razendsnel hun instellingen kunnen ophalen zonder telkens opnieuw de database te raadplegen. Slim ontwerp — als de autoloaded dataset klein blijft.

Het probleem: veel plugins markeren hun opties als autoload='yes', ook als die opties alleen op één specifieke admin-pagina nodig zijn. Sommige plugins slaan zelfs hun complete log-history, scan-resultaten, of cache-data op in wp_options met autoload aan. En als de plugin verwijderd wordt, blijven die rijen vaak gewoon staan.

Resultaat: een wp_options-tabel die met de tijd opzwelt van een gezonde 200 KB naar 50, 100, of zelfs 500 MB autoloaded data. Elke pageload moet dat eerst inladen voor er ook maar één byte HTML wordt gerenderd.

Wat is een gezonde grootte?

Bij een schone WordPress-installatie met een paar plugins:

• Onder 1 MB autoload — gezond, geen actie nodig
• 1-3 MB autoload — opletten, monitor de groei
• 3-10 MB autoload — site begint merkbaar trager te worden, vooral op shared hosting
• 10-50 MB autoload — kritiek, je site is structureel traag, hosting kan timeouts geven
• 50+ MB autoload — disaster-niveau, vaak zie je 504-errors op piekmomenten en bezoekers die een 30-seconden TTFB ervaren

Eén klant had toen ik begon 247 MB aan autoloaded options. De site duurde 22 seconden om te beginnen renderen. Na opschoning: 380 KB. TTFB ging naar 200ms.

Diagnose in 30 seconden — drie SQL-queries

Open phpMyAdmin (via cPanel/Plesk/DirectAdmin), klik op je WordPress-database, klik op SQL en draai deze drie queries.

Query 1 — totale grootte van autoload

SELECT
    ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb,
    COUNT(*) AS aantal_rijen
FROM wp_options
WHERE autoload = 'yes';

Resultaat: één regel met twee getallen. Als autoload_mb boven de 3 MB is, ga door naar query 2.

Query 2 — top 20 dikste autoload-rijen

SELECT
    option_name,
    ROUND(LENGTH(option_value) / 1024 / 1024, 3) AS size_mb,
    autoload
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

Hier zie je direct wie de hoofdverdachten zijn. Vaak ontdek je dat 1 of 2 rijen 80% van de totale grootte uitmaken. Voorbeelden uit echte sites:

option_name                        size_mb
---------------------------------- -------
wpseo_premium_redirects_export       142.7
wf_summary_items_lastrun              68.4
elementor_log                         45.2
edd_settings                          31.8
woocommerce_attribute_lookup_optimi   28.1
backupbuddy_options                   22.3
mailpoet_logs                         18.9

Query 3 — verlopen transients (gratis ruimtewinst)

SELECT COUNT(*) AS verlopen_transients
FROM wp_options
WHERE option_name LIKE '\_transient\_%'
   OR option_name LIKE '\_site\_transient\_%';

Transients zijn tijdelijke cache-waarden die WordPress zou moeten opruimen — maar in praktijk blijven ze vaak hangen. Sommige sites hebben er duizenden. Die ruimen we straks op.

De usual suspects — bekende boosdoeners

Sommige plugins zijn berucht om wp_options-bloat. Niet omdat ze slecht zijn, maar omdat ze opslag-ontwerp niet goed hebben uitgedacht.

Top categorieën

1. Backup-plugins — UpdraftPlus, BackupBuddy, BlogVault, BackWPup. Slaan log-history en backup-metadata in autoload.
2. Security-plugins — Wordfence, iThemes Security, Sucuri. Slaan scan-resultaten, blocklog, en file-checksums op.
3. Page-builders — Elementor (vooral elementor_log), WPBakery, Divi, Beaver Builder. Slaan revisies, draft-data en widget-cache op.
4. SEO-plugins — Yoast SEO Premium (vooral redirect-export), RankMath, AIOSEO. Bij grote sites kan de redirect-tabel megabytes worden.
5. WooCommerce + extensions — vooral attribute-lookup, variations en oude session-data.
6. E-mailmarketing — MailPoet, Mailchimp, Newsletter. Logs en queue-data.
7. Verwijderde plugins — die hun rijen niet hebben opgeruimd bij verwijdering.

Stap-voor-stap fix — zonder iets te slopen

Vóór alles: maak een database-backup. Niet onderhandelbaar. Via UpdraftPlus, je hosting-paneel, of via SSH:

mysqldump -u jouwuser -p jouw_db > backup-voor-autoload-cleanup.sql

Stap 1 — verwijder verlopen transients

Veiligste eerste actie. Transients horen tijdelijk te zijn:

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

Geen risico — als een transient nog nodig was, regenereert WordPress hem bij de volgende request. Dit alleen kan al 5-10 MB winst opleveren.

Stap 2 — zet grote autoload-rijen op autoload='no'

Voor de boosdoeners uit query 2: zet ze op no. Dan worden ze pas geladen wanneer een specifieke functie ze opvraagt — niet meer bij elke pageload.

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'wpseo_premium_redirects_export';

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'elementor_log';

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'wf_summary_items_lastrun';

Hoe weet je welke je veilig op no kan zetten? Vuistregel: alle opties die alleen op admin-pagina's worden gebruikt (logs, instelling-export, scan-resultaten) hebben autoload niet nodig. Alle opties die WordPress core gebruikt (siteurl, blogname, template, stylesheet, wp_user_roles) moeten wel op yes blijven.

Als je twijfelt: zet hem op no, test je site (frontend + admin), als alles werkt → klaar. Werkt iets niet → zet hem terug op yes:

UPDATE wp_options SET autoload = 'yes' WHERE option_name = 'naam_van_optie';

Stap 3 — verwijder rijen van plugins die je niet meer hebt

Eerst opzoeken welke plugins er nog instellingen achterlieten:

SELECT option_name, autoload, ROUND(LENGTH(option_value)/1024, 1) AS kb
FROM wp_options
WHERE option_name LIKE '%pluginprefix%'
ORDER BY LENGTH(option_value) DESC;

Vervang pluginprefix door bv. backupbuddy, wpsupercache, wfsync, jetpack — afhankelijk van wat je in query 2 zag.

Als je er zeker van bent dat de plugin echt weg is en niet meer terugkomt, verwijder de rijen:

DELETE FROM wp_options WHERE option_name LIKE 'backupbuddy_%';

Pas op: jetpack_, woocommerce_ en wordpress_ blijven sowieso staan zolang die actieve plugins zijn.

Stap 4 — optimize de tabel

MySQL/MariaDB houdt na deletes "lege" plekken vast tot je OPTIMIZE draait. Daarna pas is de schijfruimte écht vrij:

OPTIMIZE TABLE wp_options;

Of via WP-CLI als je SSH-toegang hebt:

wp db optimize

Stap 5 — verifieer winst

Draai query 1 nogmaals. Als je goed werk hebt gedaan, zou autoload_mb minstens gehalveerd moeten zijn. Bij sites met 50+ MB zie je vaak een reductie van 95%+.

Test daarna je site grondig — laad de homepage, een paar posts, de admin, plaatst een test-bericht, doe een check-out (bij WooCommerce). Werkt alles → klaar.

Plugin-recommendations voor het automatisch monitoren

Liever niet handmatig SQL draaien? Drie tools die het werk doen:

• Query Monitor (gratis) — toont per pageload welke options worden geladen en hoe groot ze zijn. Onmisbaar voor diepere diagnose. Zet alleen aan op een staging-site of voor jezelf — niet op productie met live verkeer.
• WP-Optimize (gratis + premium) — heeft een Optimize Database-tab met een sectie voor autoload, plus auto-cleanup van transients en post-revisions.
• Advanced Database Cleaner (gratis + premium) — specialistischer dan WP-Optimize, betere weergave van orphaned options en is beter in detecteren welke plugins zijn verwijderd.

Preventie — voorkomen dat het terugkomt

Autoload-bloat sluipt langzaam terug. Een paar gewoontes om het beheersbaar te houden:

1. Voer maandelijks query 1 uit — stel een herinnering in. Boven 5 MB? Dieper kijken.
2. Verwijder plugins netjes — vóór deactivate-en-delete: kijk of de plugin een "uninstall"-optie heeft die zijn data opruimt. Veel doen dat niet automatisch.
3. Vermijd plugins die wegwerk-data in wp_options stoppen — log-zware plugins horen hun data in eigen tabellen op te slaan, niet in wp_options.
4. Gebruik object-caching (Redis of Memcached) voor sites op VPS — transients worden dan in memory opgeslagen ipv in wp_options. Niet beschikbaar op de meeste shared-hosting plannen.
5. Schakel je SEO-plugin's redirect-export uit als je 'm niet gebruikt — Yoast Premium en RankMath kunnen die in wp_options dumpen.
6. Doe een autoload-audit na elke major plugin-installatie — als een nieuwe plugin direct 10 MB toevoegt, weet je waar je naar moet kijken.

Wat kan je verwachten qua snelheidswinst?

Dit hangt af van je startsituatie. Realistische winst-percentages uit projecten:

• Van 50 MB → 1 MB: TTFB-reductie van 50-80%. Ervaarbaar als "site is direct sneller".
• Van 10 MB → 500 KB: TTFB-reductie van 30-50%. Zichtbaar in Google Search Console Core Web Vitals.
• Van 3 MB → 300 KB: TTFB-reductie van 10-20%. Vooral op shared hosting merkbaar.
• Van 800 KB → 200 KB: nauwelijks merkbaar. Onder 1 MB is autoload niet je bottleneck — kijk dan naar plugins, theme, of caching.

Combineer altijd met andere performance-fixes voor maximaal resultaat. Volledige snelheid-aanpak vind je in trage WordPress versnellen.

Veelgestelde valkuilen

"Ik zet autoload op no, maar het werkt nog steeds traag"

WordPress heeft mogelijk een object-cache die de oude waarden onthoudt. Vlieg-fix: deactiveer en heractiveer je caching-plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache), of run wp cache flush via WP-CLI.

"Ik heb een rij verwijderd en nu werkt iets niet meer"

Geen paniek — je hebt toch een backup gemaakt? Restore alleen die rij:

mysql -u user -p jouw_db < backup-voor-autoload-cleanup.sql

Of restore alleen één rij door de specifieke INSERT uit de backup-SQL te draaien.

"De grootste rij is iets met _site_transient_"

Verwijder altijd zonder zorgen — transients regenereren zich automatisch.

"Ik zie rijen van een plugin die ik nooit heb geïnstalleerd"

Soms een teken van een gehackte site: malware-plugins die geïnstalleerd waren en weer verwijderd. Of een vorige eigenaar/agentschap die plugins heeft gebruikt en weer afgezet. Kijk de site na voor andere hack-indicatoren — meer over hack-detection in Chinese spam in WordPress detecteren en verwijderen.

Wanneer roep je hulp in?

Bij een wp_options van 100+ MB met afhankelijkheden van WooCommerce, multilanguage-plugins (WPML, Polylang) of complexe page-builders kan een verkeerde DELETE vlak voor checkout of een product-update voor uren downtime zorgen. Als je niet zeker weet welke rij van wat afhankelijk is, of als je site al €1000+ omzet per dag draait, is een uur professionele cleanup goed besteed geld vergeleken met het risico van een fout.