Ga naar de inhoud 
Ik analyseer WordPress Autoload-data, identificeert te grote vermeldingen in de wp_options tabel en verwijdert kritieke kandidaten. Dit vermindert de totale grootte van de automatisch geladen opties, vermindert TTFB, ontlast het RAM en versnelt betrouwbaar de backend en frontend.
Centrale punten
De volgende punten geven je een compact overzicht voordat ik meer in detail ga.
- Autoload grootte Houd klein (ideaal: minder dan 1-2 MB)
- Topvervuilers vinden (transiënten, grote arrays, plug-in restanten)
- SQL-controles voor grootte, aantal en topvermeldingen
- Gericht Stel in op autoload=’no‘ of verwijder
- Controle en stel maandelijks onderhoud in
Ik heb de lijst bewust slank en doelgericht gehouden, zodat je meteen de grootste hefbomen kunt herkennen. Elke maatregel heeft een directe impact op merkbare laadtijden. De stappen kunnen veilig worden getest en teruggedraaid als dat nodig is. Ik combineer analyse, opschoning en controle in een duidelijk proces. Zo bereik je duurzaam snel Bekeken pagina's.
Waarom gegevens automatisch laden de prestaties vertraagt
Bij elke aanvraag laadt WordPress alle opties met autoload=’yes’ in het geheugen - ongeacht of je thema of een plugin ze momenteel nodig heeft. Als de som van deze waarden groeit tot meerdere megabytes, nemen de latentie, TTFB en RAM-vereisten aanzienlijk toe. Vooral grote geserialiseerde arrays, verouderde transients en overblijfselen van niet-geïnstalleerde plugins blazen het autoload-volume op. Dit leidt tot onnodig werk voor PHP en MySQL en maakt vooral de backend merkbaar trager. Ik geef daarom prioriteit aan alles wat bij elke pagina-aanvraag het geheugen in gaat en verwijder systematisch de Ballast.
Meet de werkelijke status: Controleer snel grootte en aantal
Voordat ik iets verander, bepaal ik de huidige gegevenssituatie van de automatisch geladen opties in de wp_opties-tabel. Om dit te doen, gebruik ik een eenvoudige SQL-query voor de totale grootte en voeg daar het aantal items aan toe. Ik vertaal het resultaat naar MB, stel mezelf doelen en plan de volgende stappen. Als het totaal meer dan 1-2 MB is of het aantal beduidend meer dan 500, begin ik met een gerichte analyse. Deze eerste blik schept al duidelijkheid en zet de Prioriteiten vast.
-- Totale grootte (bytes) van de autoload gegevens
SELECT SUM(LENGTE(optie_waarde)) ALS autoload_grootte
VAN wp_opties
WHERE autoload = 'yes';
-- Aantal autoload gegevens
SELECT COUNT(*) ALS autoload_count
FROM wp_options
WHERE autoload = 'yes';
Kritieke items identificeren en prioriteren
Ik identificeer eerst de grootste brokken, omdat een paar opties vaak het grootste deel van de Belasting. Ik vind vaak transients (_transient_*, _site_transient_*), roldefinities (_user_roles_) of logs en statistieken van plugins die niet altijd worden gebruikt. WooCommerce of SEO plugins slaan ook graag uitdijende matrices op. Ik kijk goed naar alles wat meer dan 100-200 KB per optie bevat en verwijder consequent tijdelijke bestanden van meer dan 50 KB. Als je dieper wilt gaan, kun je mijn meer gedetailleerde Database tuning boost als een extra gids om je te helpen op een verstandige manier door de opeenvolging van maatregelen te werken.
-- Maak top-originators zichtbaar in MB
SELECT optie_naam, autoload,
ROUND(LENGTE(optie_waarde) / 1024 / 1024, 2) AS size_mb
VAN wp_opties
WAAR autoload = 'ja
ORDER BY size_mb DESC
LIMIT 20;
Diepgaande analyse: patronen, voorvoegsels en serialisatie
Om gericht op te ruimen, heb ik de autoloadhoeveelheid opgesplitst volgens voorvoegsels en gegevensvormen. Hierdoor kan ik snel zien welke plugins of functionele gebieden bijzonder sterk bijdragen en of grote, geserialiseerde arrays domineren. Ik kan geserialiseerde gegevens herkennen aan een startpatroon zoals a:... (matrix) of O:... (object). Grote, geneste arrays zijn typische kandidaten voor autoload=no of een verdeling in kleinere eenheden.
-- Verdeling volgens (eenvoudige) voorvoegsels
SELECT
SUBSTRING_INDEX(optie_naam, '_', 1) AS voorvoegsel,
COUNT(*) als cnt,
ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) ALS size_mb
FROM wp_opties
WAAR autoload = 'ja
GROEP DOOR prefix
ORDER BY size_mb DESC
LIMIT 20;
-- Identificeer grote geserialiseerde arrays
SELECT optie_naam,
LENGTE(optie_waarde) AS len
FROM wp_options
WHERE autoload = 'ja
EN optie_waarde REGEXP '^a:[0-9]+:'
ORDER BY len DESC
LIMIT 20;
-- Controleer JSON-type inhoud (alleen grof filter)
SELECT optie_naam,
LENGTE(optie_waarde) AS len
FROM wp_options
WHERE autoload = 'ja
AND option_value LIKE '{%
ORDER BY len DESC
LIMIT 20;
Als je meerdere zeer grote opties voor een plugin vindt, dan kan de Opslagstrategie het probleem (bijvoorbeeld caches of logboeken in een enkele optie). Dit kan vaak worden beperkt: Splits gegevens op, verwijder onnodige delen of verminder het loggen via een plugin-instelling.
Gericht opruimen: Transiënten, autoload=nee, verweesde opties
Voor verouderde tijdelijke items verwijder ik verlopen items omdat ze vaak onnodige ruimte innemen Geheugen. Ik stel grote, zelden gebruikte opties in op autoload=’no’ en test de werking van de pagina onmiddellijk daarna. Als ik sporen vind van externe plugins, ruim ik hun voorvoegsels op een gecontroleerde manier op uit de wp_options tabel. Elke stap wordt uitgevoerd met een up-to-date back-up en een duidelijk fallback-niveau, zodat je altijd veilig bent. Op deze manier krimpt het autoload-totaal snel en de TTFB winst.
-- Verwijder verlopen transients (maak eerst een back-up!)
DELETE FROM wp_opties
WHERE option_name LIKE '_transient_%'
OF option_name LIKE '_site_transient_%';
-- Verwijder één grote optie uit de autoload
UPDATE wp_opties
SET autoload = 'no'
WHERE option_name = 'EXAMPLE_OPTION';
-- Verwijder verweesde plugin opties met een herkenbaar voorvoegsel
DELETE FROM wp_options
WHERE option_name LIKE 'altplugin_%';
Veilig verwijderen in plaats van blind verwijderen
Toen ik alleen verlopen transiënten, gebruik ik specifieke queries die rekening houden met de time-outopties. Dit is vriendelijker en vermindert neveneffecten bij het cachen. Als alternatief doet WP-CLI het werk met één commando.
-- Alleen verlopen (site) transients verwijderen (veiliger)
DELETE a, b
VAN wp_opties a
JOIN wp_opties b
ON b.option_name = REPLACE(a.option_name, '_transient_', '_transient_timeout_')
WHERE a.option_name LIKE '_transient_%'
AND a.option_name NOT LIKE '_transient_timeout_%'
AND b.option_value < UNIX_TIMESTAMP();
DELETE a, b
VAN wp_opties a
JOIN wp_opties b
ON b.option_name = REPLACE(a.option_name, '_site_transient_', '_site_transient_timeout_')
WHERE a.option_name LIKE '_site_transient_%'
AND a.option_name NOT LIKE '_site_transient_timeout_%'
AND b.option_value < UNIX_TIMESTAMP();
-- WP-CLI (aanbevolen): verlopen transients verwijderen
# enkele site
wp tijdelijk verwijderen --verlopen
# multisite-breed
wp tijdelijk verwijderen --vervallen --netwerk
Voor een Terugdraaien Ik sla de grootste opties van tevoren apart op: namen verzamelen, inhoud exporteren, wijzigingen loggen. Hierdoor kan ik individuele waarden binnen enkele seconden herstellen in het geval van een probleem.
# Top 50 autoload namen exporteren
wp db query "
SELECT optie_naam
FROM wp_opties
WHERE autoload='ja
ORDER BY LENGTH(option_value) DESC
LIMIET 50
' --skip-kolom-namen > big_options.txt
# Inhoud opslaan (eenvoudig tekstformaat)
while read -r NAME; do
printf "=== %s ===n' '$NAME" >> backup_options.txt
wp option get "$NAME" >> backup_options.txt
klaar < grote_opties.txt
Onderhoud van tabellen en geheugenhygiëne
Na het opschonen optimaliseer ik de tabel zodat verwijderde gegevensblokken vrij komen en de Database weer efficiënt werkt. Deze stap vermindert fragmentatie en helpt MySQL bij toekomstige queries. Daarna controleer ik opnieuw de autoload grootte zodat het succes meetbaar blijft. Optioneel versnelt een objectcache zoals Redis of Memcached het laden van de resterende opties. Zelfs zonder een cache zult u het effect direct merken omdat er minder gegevens per verzoek worden opgeslagen in de RAM wandeling.
-- Geheugen vrijmaken en statistieken bijwerken
OPTIMIZE TABLE wp_options;
Automatiseren met tools en WP-CLI
Ik bespaar tijd op terugkerende installaties met geselecteerde Gereedschap en scripts. Met WP-CLI kan ik massale updates uitvoeren, bijvoorbeeld om verschillende grote opties op autoload=’no’ te zetten en ze direct te controleren. Ik gebruik lean plugins met duidelijke logging om regelmatig transiënten op te ruimen en tabellen te optimaliseren. Voor elke automatisering documenteer ik de beginwaarden, zodat ik de voordelen en risico's kan afwegen. Als je meer snelheid uit wp_options wilt halen, kun je meer informatie vinden op Prestatie tuning van de wp_options aanvullende ideeën voor de zinvolle combinatie van analyse en scripting.
# Voorbeeld: doorloop de lijst met grote optienamen en deactiveer autoload
while read -r NAAM; do
wp option update "$NAME" "$(wp option get "$NAME")" --autoload=no
gedaan < names.txt
Bewaking en preventie: TTFB en RAM in één oogopslag
Na het opschonen heb ik een eenvoudige routine ingesteld zodat het autoloadtotaal niet opnieuw verschijnt. stijgt. Een maandelijkse controle van de totale grootte, aangevuld met de top 10 opties, is vaak voldoende. Als de waarde aanzienlijk toeneemt, controleer ik de laatst geïnstalleerde plugins en hun instellingen. Tegelijkertijd controleer ik TTFB, PHP-geheugengebruik en databasetijd om verbeteringen zichtbaar te maken. Deze maatregelen hebben een sterker effect op goede hosting, omdat I/O-prestaties de Winsten extra versterkt.
Drempels en maatregelen in één oogopslag
Om de volgende stappen te categoriseren, gebruik ik duidelijke Grenzen, die het mogelijk maken om snel beslissingen te nemen. Ik geef prioriteit aan de grootste boosdoeners, zonder tijd te verspillen aan niet-kritieke invoer. De tabel toont typische drempelwaarden en mijn standaardreactie daarop. Het is geen vervanging voor een analyse, maar het geeft je vertrouwen voor de eerste paar rondes. Als je dieper gaat, kun je vervolgens fijnere aanpassingen maken en de Besturingselementen condenseren.
| Type | Drempelwaarde | Actie |
|---|---|---|
| Totale autoload grootte | < 1-2 MB | Onderhouden, maandelijks controleren |
| Totale autoload grootte | 2-5 MB | Grootste 10 opties controleren, transiënten opschonen |
| Totale autoload grootte | > 5 MB | Streef naar onmiddellijke vermindering, autoload=no voor zelden gebruikte opties |
| Enkele optie | > 100-200 KB | Controleer de oorzaak, stel indien nodig in op autoload=no |
| Transiënten | > 50 KB | Verwijderen, later opnieuw maken met schone cache |
Vermijd risico's en test veilig
Ik verander nooit kritieke opties zonder verse Back-up en zonder plan voor de weg terug. Voordat ik iets verwijder, controleer ik of er centrale kernopties zoals siteurl of home bij betrokken zijn, omdat ik deze niet aanraak. Na elke wijziging laad ik de frontend en backend in een nieuwe sessie om de pagina-effecten in een vroeg stadium te herkennen. Bij problemen zet ik de vorige staat terug vanaf de back-up en ga ik in kleine stapjes verder. Op deze manier blijft de optimalisatie controleerbaar en behoud je de Stabiliteit van uw installatie.
Praktijkvoorbeeld: Van traag naar responsief
In een installatie met meer dan 20 MB aan autoloadgegevens heb ik eerst grote transiënten verwijderd en daarna drie omvangrijke opties ingesteld op autoload=no ingesteld. Na een OPTIMIZE TABLE werden TTFB en backend wachttijden zichtbaar zonder dat functies faalden. Vervolgens heb ik verweesde plugin-restanten gereduceerd die overbleven na het verwijderen. De nieuwe meting toonde een autoload-totaal van bijna 2 MB, wat de pagina's merkbaar versnelde. Elke actie was meetbaar, omkeerbaar en bracht onmiddellijk Voordelen.
Kernopties en typische valkuilen
Naast de voor de hand liggende brokken zijn er opties die je met bijzondere zorg moet behandelen. Deze omvatten siteurl, Home, actieve_plugins, stijlblad/sjabloon, permalink_structuur, rewrite_rules, cron en wp_gebruiker_rollen. Sommige zijn groot (bijv. rewrite_rules) en vaak autoload=’yes’. Ik verklein ze, maar ontkoppel ze niet achteloos uit de autoload. Voor ongewoon grote rewrite_rules Ik controleer aangepaste posttypen, taxonomieën en plugins met mijn eigen herschrijvingen en ruim op in plaats van alleen aan het symptoom te werken. Is cron opgeblazen, deactiveer ik dubbele gebeurtenissen en ruim ik haken op; simpelweg overschakelen naar autoload=no activeert de Oorzaak niet.
Beste praktijken voor ontwikkelaars: Opties correct gebruiken
Veel problemen met autoload ontstaan al tijdens de ontwikkeling. Mijn richtlijnen:
- Tijdelijke gegevens (caches, resultaten, tijdelijke lijsten) in Transiënten en, indien mogelijk, niet autoloaden.
- Splits grote structuren op in kleinere, gerichte opties; geen megabyte-grote „verzamelcontainers“.
add_option( $name, $waarde, '', 'nee' )als iets niet voor elk verzoek nodig is.- Geen Logboeken of debug-dumps in opties; gebruik hiervoor aparte tabellen of bestanden/waarneembaarheid.
- In plaats van geserialiseerde gigantische arrays, overschakelen naar meerdere opties of een aparte tabel indien nodig - beter Gedeeltelijk laden.
- Exacte ongeldigmaking: Verwijder caches specifiek in plaats van „alles wissen“. Dit houdt de gegevens klein en stabiel.
// Voorbeeld: optie bewust maken zonder autoload
add_option( 'my_plugin_cache', $data, '', 'no' );
// Ervoor zorgen dat grote arrays niet onnodig groeien
update_option( 'my_plugin_cache', array_slice( $data, 0, 1000 ), false );
Object cache: voordelen en beperkingen
Een persistente objectcache (Redis/Memcached) vermindert databasebelasting, maar elimineert niet Autoload-Bloat. Grote autoload-sommen gaan dan rechtstreeks van de cache naar het PHP-geheugen. Dit bespaart query's, maar verhoogt de RAM-vereisten en het deserialisatiewerk. Daarom geldt het volgende verminderen, dan cache. Leeg de cache na het opschonen één keer zodat er schone, kleinere gegevensrecords worden aangemaakt.
Indices, motor en integriteit van de wp_opties
Standaard bestaan er zinvolle indexen op optie_naam en autoload. In handmatig gemigreerde installaties werden deze soms verwijderd of beschadigd. Ik controleer de indices en reset ze indien nodig. Ik let ook op InnoDB als Opslagmotor en een geschikt rijformaat zodat grote waarden efficiënt kunnen worden verwisseld.
-- Indexen controleren
SHOW INDEX FROM wp_options;
-- (Alleen als deze ontbreekt!) Maak een nieuwe index op autoload
CREËER INDEX autoload OP wp_opties (autoload);
-- (Optioneel) Schakel over naar InnoDB en modern rijformaat
ALTER TABLE wp_options ENGINE=InnoDB, ROW_FORMAT=DYNAMIC;
Belangrijk: Breng alleen structurele wijzigingen aan met een back-up- en onderhoudsvenster. Vaak is de autoloadreductie plus TABEL OPTIMALISEREN, om significante effecten te bereiken.
Problemen oplossen met verhaal: kies een meetbare aanpak
Na wijzigingen monitor ik specifiek de volgende kengetallen per request: TTFB, query count/tijd, piekgeheugen en PHP-uitvoeringstijd. Voor diepgaande analyses is het de moeite waard om voor korte tijd een slow query log op de database te activeren en - op ontwikkelomgevingen - een profiler. Het is belangrijk om elke wijziging te analyseren geïsoleerd eerst transiënten, dan individuele grote opties, dan tabelonderhoud.
-- Voorbeeld: query's voor autoload opties zichtbaar maken in het logboek
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.2; -- 200ms
-- Na testen weer deactiveren
Speciale gevallen: WooCommerce, SEO & statistieken plugins
E-commerce en analyseplugins genereren vaak grote opties (productindexen, rapporten, geschiedenis). Ik controleer of caches opnieuw kunnen worden opgebouwd, of er instellingen zijn voor de cachegrootte en of bepaalde rapportfuncties echt altijd nodig zijn. Bij WooCommerce is het de moeite waard om te kijken naar sessie- en inventarisovergangen; bij SEO-plugins let ik op index- en metadata-caches. Principe: Functie behouden, geheugen beperken - Het is beter om vaker te regenereren dan om reusachtige waarden permanent automatisch te laden.
Staging, uitrol en herhaalbare controles
Ik voer alle riskantere stappen eerst uit op een Staging-omgeving en sla daar de specifieke volgorde van commando's op. Vervolgens implementeer ik dit playbook in productie. Ik maak twee mini-rapporten voor terugkerende controles: totale grootte/aantal en top 10 grootte. Dit houdt de monitoring licht en zorgt voor snelle reacties wanneer een plugin-update de autoload-hoeveelheid weer verhoogt.
# Quick-Report 1: Grootte & aantal
wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';".
wp db query "SELECT COUNT(*) FROM wp_options WHERE autoload='yes';"
# Quick-Report 2: Top-10
wp db query "
SELECT optie_naam, ROUND(LENGTE(optie_waarde)/1024/1024,2) AS mb
FROM wp_options WHERE autoload='yes'
ORDER BY mb DESC LIMIT 10;
"
Fijnafstemming: multisite- en netwerkgegevens
In multisite-setups controleer ik ook de wp_sitemetatabel omdat netwerkwijde instellingen zich daar bevinden. Grote vermeldingen gedragen zich daar net zo en kunnen meerdere sites vertragen. Ik meet de totalen en topvermeldingen en beslis dan over het aandeel opruimen en autoloaden per netwerk. De controle wordt voor elke site apart uitgevoerd, zodat lokale eigenschappen niet over het hoofd worden gezien. Op deze manier houd ik ook grotere netwerken responsief en bescherm ik gedeelde sites. Bronnen.
-- Controleer netwerkgegevens (multisite)
SELECT SUM(LENGTH(meta_value)) AS network_meta_size FROM wp_sitemeta;
SELECT meta_key, LENGTE(meta_waarde) AS len
FROM wp_sitemeta
ORDER BY len DESC
LIMIT 10;
Verdere hulp voor gestructureerde implementatie
Als je de procedure stap voor stap wilt uitvoeren, gebruik dan een compacte Gids als aanvulling op je eigen aantekeningen. Begin met meten, sla een back-up op, ruim transiënten op en controleer dan geleidelijk de belangrijkste opties. Op deze manier kun je het risico beheersbaar houden en na elke ronde duidelijke verbeteringen zien. Dit overzicht biedt extra structuur: wp_opties optimalisatie. Met dit raster blijf je consistent en verlies je niets. Stappen uit het zicht.
Korte samenvatting: De belangrijkste hefbomen voor snelle pagina's
Ik houd de automatisch geladen opties consequent klein, ruim transiënten op, stel zelden gebruikte chunks in op autoload=no en de tafel optimaliseren. Meten voor en na elke ronde maakt het effect zichtbaar en creëert zekerheid. Met duidelijke drempelwaarden vind ik binnen enkele minuten de grootste oorzaken en begin daar als eerste. Eenvoudige monitoring voorkomt dat het autoload-totaal later weer oploopt. Zo krijg ik je WordPress installatie permanent op snelheid en versterk ik de Prestaties merkbaar.
