WordPress autoload options -taulukon siivous ja suorituskykyvaikutus

WordPressin wp_options-taulu on yksi yleisimmistä piilevistä suorituskykyongelmien lähteistä, erityisesti autoload = yes -merkinnän takia. Kun sivu latautuu, WordPress hakee automaattisesti kaikki autoloadatut optionit jokaisella requestilla – myös ne, joita ei tarvita kyseisellä sivulla.

Suurissa tai pitkään ylläpidetyissä sivustoissa tämä voi kasvaa ongelmaksi, joka hidastaa koko sivustoa ilman että sitä heti huomaa.

Mikä autoload oikeasti tekee

Autoload = yes käytännössä

• kaikki kyseiset rivit ladataan jokaisella sivulatauksella
• data menee PHP:n muistiin ennen kuin WordPress edes renderöi sivua
• koskee sekä frontendiä että adminia

Autoload = no

• optio haetaan vain kun sitä erikseen pyydetään
• ei kuormita jokaista requestia

Miksi autoload kasvaa ongelmaksi

1. Pluginien “jäljet” jäävät tietokantaan

Monet lisäosat:

• eivät poista asetuksia poiston yhteydessä
• jättävät transientteja ja konfiguraatiota
• tallentavat isoja JSON-rakenteita autoload = yes

Tuloksena:

• wp_options kasvaa huomaamatta
• autoload-data paisuu vuosien aikana

2. Isoja dataobjekteja autoloadissa

Tyypillisiä ongelmia:

• page builder -asetukset (Elementor, WPBakery)
• WooCommerce transients
• SEO-pluginien metadata
• cache-pluginien konfiguraatiot

Yksi rivi voi olla satoja kilotavuja.

3. Kaikki ladataan, vaikka ei tarvita

Esimerkki:

• yhteystietosivu lataa WooCommerce-asetuksia
• blogipostaus lataa page builderin globaalit asetukset

Suorituskykyvaikutus

Muisti

• jokainen request voi ladata useita megatavuja turhaa dataa
• PHP memory usage kasvaa nopeasti

Aika

• suuret autoload-taulut lisäävät query timea
• serialize/unserialize kuormittaa CPU:ta

Käytännön vaikutus

• TTFB kasvaa
• admin tuntuu hitaalta
• erityisesti shared hosting kärsii

Miten tarkistaa autoload-koko

SQL-kysely:

SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload = 'yes';

Yksittäiset suurimmat rivit:

SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Hyvä ja huono tilanne

Hyvä taso

• alle ~1–2 MB autoload-dataa
• kevyt ja nopea sivusto

Varoitusalue

• 5–10 MB
• alkaa näkyä hitaudessa

Ongelma

• 20 MB+
• selkeä suorituskykyhaitta

Autoload siivous käytännössä

1. Analysoi ensin

Älä poista mitään sokkona:

• selvitä mitä pluginia option kuuluu
• tarkista käytetäänkö sitä oikeasti

2. Vaihda autoload = no

SQL:

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

Tämä on usein turvallisin ensimmäinen askel.

3. Poista orpoja optioneita

Tyypillisiä poistettavia:

• poistettujen pluginien asetukset
• vanhat transientit
• cache-jäämät

4. Käytä WP-CLI:tä (suositeltu)

wp option list --autoload=on --format=table

Yleisimmät “syylliset” pluginityypit

Page builderit

• Elementor
• WPBakery
• Divi

WooCommerce

• session data
• transients
• raportointi

SEO-pluginit

• Yoast
• RankMath

Cache-pluginit

• WP Rocket
• LiteSpeed Cache

Miten estää ongelma jatkossa

1. Plugin-hygienia

• poista käyttämättömät pluginit kunnolla
• varmista että ne siivoavat datansa

2. Autoload-käytön tarkistus

• älä tallenna suuria JSON-objekteja autoloadiin
• käytä transientteja oikein

3. Arkkitehtuurivalinnat

• siirrä raskas data custom-tauluihin
• vältä wp_options “datavarastona”

4. Cache-ratkaisut

• Redis object cache vähentää DB-kuormaa
• mutta ei korjaa paisunutta autoloadia

Yhteenveto

Autoload options -taulu on yksi WordPressin aliarvostetuimmista suorituskykyongelmista. Se ei yleensä näy heti, mutta ajan kanssa se voi hidastaa koko sivustoa merkittävästi.

Ongelman ydin on yksinkertainen:

• kaikki ladotaan jokaisella sivulla
• myös turha ja vanha data

Korjaus ei ole monimutkainen, mutta vaatii systemaattista siivousta ja ymmärrystä siitä, mitä oikeasti tarvitaan ja mitä ei.

Kun autoload pidetään kevyenä, WordPressin vasteajat paranevat usein yllättävän paljon ilman mitään muuta optimointia.