Alles lijkt in orde: je hosting is goed, caching staat aan, je afbeeldingen zijn geoptimaliseerd. Toch voelt je WordPress-site trager dan verwacht. De boosdoener zit vaak op een plek waar je niet snel kijkt - de autoloaded options in je wp_options-tabel. Deze stille performance killer laadt bij elk pageview data in het geheugen, ook als die data nergens op de pagina wordt gebruikt.
In ons artikel over database optimalisatie voor WordPress noemden we de wp_options-tabel al als veelvoorkomende bottleneck. In dit artikel zoomen we volledig in op autoloaded options: wat ze zijn, waarom ze problematisch worden en hoe je ze opspoort en oplost.
Wat zijn autoloaded options precies?
De wp_options-tabel is het centrale opslagpunt voor WordPress-instellingen. Elke rij bevat een option_name, een option_value en een autoload-veld. Dat laatste veld bepaalt of WordPress de optie automatisch in het geheugen laadt bij het opstarten van elk request.
Wanneer een bezoeker je site opvraagt, voert WordPress vroeg in het request-proces één query uit die alle rijen met autoload = 'yes' ophaalt. Het resultaat wordt in het geheugen geladen zodat functies als get_option() direct toegang hebben zonder extra database-queries.
Dit mechanisme is slim bedacht. Opties als siteurl, blogname en active_plugins zijn bij elk request nodig - die wil je in één keer ophalen. Het probleem ontstaat wanneer plugins en thema's hun eigen data als autoloaded markeren, terwijl die data lang niet altijd nodig is.
Waarom autoloaded options een probleem worden
Een verse WordPress-installatie heeft slechts enkele honderden kilobytes aan autoloaded data. Maar na maanden van plugins installeren, configureren en weer verwijderen, kan die hoeveelheid flink oplopen.
Het sneeuwbaleffect
Elke plugin die je installeert, voegt opties toe aan wp_options. Veel plugins markeren hun instellingen als autoloaded, ook als die instellingen alleen op specifieke admin-pagina's of in bepaalde frontend-scenario's nodig zijn. En hier wordt het problematisch:
- Plugins die grote geserialiseerde arrays opslaan - denk aan page builders die hele layoutconfiguraties in één optie proppen
- Verwijderde plugins die hun opties niet opruimen - de plugin is weg, maar de data blijft autoloaded
- Verlopen transients zonder Redis - als je geen object cache met Redis gebruikt, slaat WordPress transients op in
wp_options, vaak metautoload = 'yes' - Caching-plugins die resultaten in opties opslaan - sommige plugins gebruiken
wp_optionsals cache-backend
De impact op elk request
Stel dat je 3 MB aan autoloaded data hebt. Bij elk request - elke pageview, elke AJAX-call, elke REST API-aanroep - moet WordPress:
- Een query uitvoeren die 3 MB aan data uit MySQL ophaalt
- Die data door PHP laten deserialiseren
- Alles in het werkgeheugen laden
Dat zijn drie stappen die tijd en geheugen kosten, bij elke request. Zelfs als full page caching het merendeel van je frontend-requests afvangt, raken admin-pagina's, AJAX-calls en WooCommerce-accountpagina's alsnog de database.
Je autoloaded options analyseren
Voordat je iets wijzigt, breng je de huidige situatie in kaart. Je hebt hiervoor toegang tot de database nodig via phpMyAdmin, Adminer, of een directe MySQL-verbinding.
Totale autoload-grootte meten
De eerste stap is bepalen hoeveel autoloaded data je hebt:
SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';
Vuistregels:
- Onder 800 KB - gezond, geen actie nodig
- 800 KB - 1 MB - aan de hoge kant, onderzoek de grootste opties
- Boven 1 MB - te veel, dit beïnvloedt je laadtijd merkbaar
- Boven 3 MB - kritiek, elke request wordt hierdoor vertraagd
De grootste boosdoeners vinden
Zoek welke opties de meeste ruimte innemen:
SELECT option_name, LENGTH(option_value) AS size,
ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 30;
Noteer de option_name-waarden bovenaan de lijst. Vaak herken je de pluginnaam in de optienaam. Als je daar namen van plugins ziet die je al lang geleden hebt verwijderd, heb je je probleem gevonden.
Aantal autoloaded rijen tellen
Het gaat niet alleen om grootte, maar ook om het aantal rijen:
SELECT COUNT(*) AS autoloaded_rows
FROM wp_options
WHERE autoload = 'yes';
Een standaard WordPress-installatie heeft zo'n 100-200 autoloaded rijen. Als je er meer dan 500 hebt, is er waarschijnlijk achtergebleven data van plugins die je niet meer gebruikt.
WP-CLI als analysetool
Heb je SSH-toegang tot je server, dan is WP-CLI een snellere manier om autoloaded options te analyseren. De totale grootte check je met:
wp db query "SELECT SUM(LENGTH(option_value)) AS autoload_bytes FROM wp_options WHERE autoload = 'yes';"
De top 20 grootste opties:
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload = 'yes' ORDER BY size DESC LIMIT 20;"
Je kunt ook zoeken naar opties van een specifieke plugin. Stel dat je Yoast SEO hebt verwijderd maar vermoedt dat de opties er nog staan:
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE option_name LIKE '%wpseo%' AND autoload = 'yes';"
Autoloaded options opschonen
Nu je weet welke opties de meeste impact hebben, is het tijd om op te ruimen. Werk altijd op een staging-omgeving of maak eerst een database-backup.
Stap 1: Opties van verwijderde plugins verwijderen
Als je een plugin hebt verwijderd maar de opties zijn achtergebleven, kun je ze veilig verwijderen. Zoek eerst welke opties erbij horen:
SELECT option_name FROM wp_options
WHERE option_name LIKE '%plugin_prefix%';
Vervang plugin_prefix door het prefix van de plugin. Verwijder ze daarna:
DELETE FROM wp_options
WHERE option_name LIKE '%plugin_prefix%';
Veelvoorkomende prefixes van populaire plugins die rommel achterlaten: _elementor_, _yoast_, woocommerce_, jetpack_, revslider_, _oembed_.
Stap 2: Autoload uitschakelen voor grote opties
Sommige opties wil je niet verwijderen, maar ze hoeven niet bij elk request geladen te worden. Zet autoload uit:
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'optie_naam_hier';
WordPress haalt deze opties dan alleen op wanneer een plugin expliciet get_option('optie_naam_hier') aanroept. Dat betekent een extra query op dat specifieke moment, maar je bespaart het laden bij alle andere requests.
Veilig om autoload uit te zetten:
- Opties van plugins die alleen op admin-pagina's draaien
- Grote geserialiseerde datasets (analytics-data, log-entries)
- Cache-gerelateerde opties die beter in Redis thuishoren
Niet uitschakelen:
siteurl,home,blogname,blogdescriptionactive_plugins,current_theme,template,stylesheetrewrite_rules- Core WordPress opties die bij elk request nodig zijn
Stap 3: Verlopen transients opruimen
Transients die in wp_options zijn opgeslagen, nemen onnodig ruimte in als ze verlopen zijn:
wp transient delete --expired
Wil je voorkomen dat transients überhaupt in de database terechtkomen? Configureer dan Redis als object cache. Redis slaat transients in het geheugen op, waardoor ze nooit in wp_options belanden.
WordPress 6.6+ en de autoload-kolom
Sinds WordPress 6.6 is het autoload-systeem gemoderniseerd. De kolom autoload accepteert nu meer waarden dan alleen 'yes' en 'no'. De nieuwe mogelijke waarden zijn:
on- expliciet autoloaded (vervangt'yes'voor nieuwe opties)off- expliciet niet autoloaded (vervangt'no')auto- WordPress beslist op basis van intern gebruikauto-onenauto-off- automatisch bepaald met hint
In de praktijk betekent dit dat WordPress slimmer omgaat met welke opties bij elk request worden geladen. De oude waarden 'yes' en 'no' blijven werken voor backwards-compatibiliteit, maar nieuwe opties gebruiken het verbeterde systeem.
Controleer of je WordPress-versie deze feature ondersteunt. Als je op 6.6 of hoger zit, profiteer je automatisch van deze verbetering voor nieuw aangemaakte opties. Bestaande opties met autoload = 'yes' worden niet automatisch gemigreerd.
Query Monitor als visueel hulpmiddel
Wil je niet met SQL-queries werken, dan is de plugin Query Monitor een uitstekend alternatief. Na installatie kun je op elke pagina zien welke opties worden geladen en hoeveel tijd de option-query kost.
Kijk specifiek naar:
- De totale tijd van de
alloptions-query (de query die alle autoloaded options ophaalt) - De hoeveelheid data die deze query retourneert
- Of er duplicate option-calls zijn
Als de alloptions-query meer dan 10 ms kost, is dat een teken dat je te veel autoloaded data hebt. Op een goed geoptimaliseerde site duurt deze query minder dan 5 ms.
Preventie: voorkom dat het opnieuw gebeurt
Opschonen is nuttig, maar voorkomen is beter. Neem deze gewoontes aan om je autoloaded options beheersbaar te houden.
Bij het installeren van plugins
Let bij het testen van nieuwe plugins op de impact die ze hebben op wp_options. Installeer Query Monitor en vergelijk de alloptions-query voor en na het activeren van een nieuwe plugin. Als een plugin honderden kilobytes aan autoloaded data toevoegt, overweeg dan een alternatief.
Bij het verwijderen van plugins
Deactiveer en verwijder een plugin via het WordPress-dashboard, niet door de map handmatig te verwijderen. Veel plugins hebben een uninstall.php of register_uninstall_hook die de opties opruimt. Controleer na verwijdering of de opties daadwerkelijk weg zijn:
wp db query "SELECT option_name FROM wp_options WHERE option_name LIKE '%plugin_prefix%';"
Periodieke controle
Plan een maandelijkse controle van je autoload-grootte in. Combineer dit met je reguliere database-onderhoud. Eén simpele query vertelt je of er actie nodig is:
wp db query "SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS autoload_kb FROM wp_options WHERE autoload = 'yes';"
Autoloaded options en caching
Het effect van te veel autoloaded options is het sterkst op pagina's die niet uit cache worden geserveerd. Zoals we beschreven in ons artikel over WordPress performance bottlenecks, is de TTFB (Time to First Byte) de metriek die je hier het duidelijkst ziet stijgen.
Met full page caching vang je het gros van de frontend-requests af. Maar admin-pagina's, ingelogde gebruikers, WooCommerce-winkelpagina's en AJAX-requests passeren de cache niet. Voor die requests maakt een verschil van 1 MB aan autoloaded data het verschil tussen 200 ms en 500 ms TTFB.
Redis als object cache helpt ook: de alloptions-query wordt gecacht in Redis, waardoor niet elke request de database hoeft te raken. Maar Redis cached wat er ís - als je 3 MB aan autoloaded data hebt, moet die 3 MB alsnog worden gedeserialiseerd door PHP. Opschonen bij de bron blijft de beste oplossing.
Veelgestelde vragen
Wat zijn autoloaded options in WordPress?
Autoloaded options zijn rijen in de wp_options-tabel met autoload ingesteld op 'yes'. WordPress laadt ze automatisch bij elk request in het geheugen, ongeacht of ze op die pagina nodig zijn. Dit is handig voor essentiële instellingen, maar wordt problematisch als plugins er te veel data in opslaan.
Hoeveel autoloaded data is normaal in WordPress?
Een gezonde WordPress-installatie heeft minder dan 800 KB aan autoloaded data. Tussen 800 KB en 1 MB is een waarschuwing, en boven de 1 MB heb je vrijwel zeker een probleem dat je laadtijden negatief beïnvloedt.
Kan ik autoloaded options veilig uitschakelen?
Ja, maar niet zomaar alles. Core WordPress opties zoals siteurl en blogname moeten autoloaded blijven. Opties van verwijderde plugins en grote geserialiseerde datasets kun je veilig op autoload 'no' zetten. Test altijd op een staging-omgeving eerst.
Wat is het verschil tussen autoloaded options en transients?
Autoloaded options zijn permanente instellingen die bij elk request worden geladen. Transients zijn tijdelijke data met een vervaldatum. Verlopen transients in wp_options nemen onnodig ruimte in. Met Redis als object cache worden transients buiten de database opgeslagen.
Hoe voorkom ik dat autoloaded options opnieuw vollopen?
Controleer bij het installeren van plugins of ze excessief autoloaded data aanmaken. Monitor je autoload-grootte periodiek met een SQL-query of WP-CLI. Gebruik Redis als object cache zodat transients niet in wp_options terechtkomen, en ruim achtergebleven data van verwijderde plugins direct op.