Autoloaded data on yksi WordPressin “piilokriittisistä” suorituskykytekijöistä. Se ei näy suoraan sivulla, mutta vaikuttaa jokaiseen requestiin, koska WordPress lataa automaattisesti kaiken wp_options-taulusta, jossa autoload = yes.
WordPress lataa bootissa:...
Monet pluginit tallentavat:...
Hyvin optimoitu sivusto:...
SQL:...
Jos dataa ei tarvita joka requestilla:...
Jos dataa ei tarvita joka requestilla:...
update_option('analytics_data', $big_array); Parempi: erillinen taulu tai transient/cache 3. Transientit oikein käytettynä set_transient('analytics_summary', $data, HOUR_IN_SECONDS); Transientit eivät kuulu autoloadiin....
set_transient('analytics_summary', $data, HOUR_IN_SECONDS); Transientit eivät kuulu autoloadiin....
Huono:...
WordPress serialisoi automaattisesti arrayt:...
Redis auttaa, mutta ei poista ongelmaa:...
Etsi:...
Prosessi:...
Kun data kasvaa:...
Elementor / WPBakery:...
Väärä ajattelu:...
Skaalautuva WordPress:...
Skaalautuva WordPress:...
Autoloaded data on yksi WordPressin aliarvioiduimmista suorituskykyongelmista. Se vaikuttaa jokaiseen requestiin riippumatta siitä käytetäänkö dataa vai ei. Kun autoload-rakenne pidetään kevyenä ja isot datasetit siirretään...
Kun autoloaded data kasvaa liikaa, seurauksena on:
- hidas TTFB
- kasvanut muistinkulutus
- turhat DB-queryt jokaisella sivulatauksella
- adminin hidastuminen
- Redis/object cache -hyödyn heikkeneminen
Mitä autoloaded data oikeastaan on
WordPress lataa bootissa:
SELECT option_name, option_value
FROM wp_options
WHERE autoload = 'yes'
Tämä tarkoittaa:
- kaikki autoload = yes → ladataan joka requestilla
- ei väliä käytetäänkö arvoa vai ei
Tyypillinen ongelma
Monet pluginit tallentavat:
- isot JSON-rakenteet
- analytics-dataa
- transient-tyyppistä dataa väärään paikkaan
- WooCommerce konfiguraatiota ilman rajoja
Tulos:
autoloaded options = 1–10 MB+ (liikaa)
Tavoitetaso
Hyvin optimoitu sivusto:
- alle 300 KB autoloaded dataa
- mieluiten 100–200 KB
- ei isoja serialisoituja objekteja
Autoloaded datan tarkistus
SQL:
SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload = 'yes';
Yksittäiset raskaat optionit:
SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;
Tyypilliset syylliset
site_transient_*(väärin käytettynä)- page builder -asetukset
- WooCommerce options
- SEO plugin config
- analytics plugin data
- custom theme options (isot JSONit)
1. Korjaa autoload-arvo
Jos dataa ei tarvita joka requestilla:
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'heavy_option';
Tämä on yksinkertaisin optimointi.
2. Käytä oikeaa tallennusstrategiaa
Huono:
update_option('analytics_data', $big_array);
Parempi:
- erillinen taulu
- tai transient/cache
3. Transientit oikein käytettynä
set_transient('analytics_summary', $data, HOUR_IN_SECONDS);
Transientit eivät kuulu autoloadiin.
4. Fragmentoi isot optionit
Huono:
theme_options = 500KB JSON
Parempi:
theme_colors
theme_typography
theme_layout
Useita pieniä optioneita → vähemmän kuormaa.
5. Vältä serialisoituja monster-objekteja
WordPress serialisoi automaattisesti arrayt:
update_option('settings', $huge_array);
Ongelma:
- ei indeksoitavissa
- aina koko blob ladattava
Parempi:
- normalisoitu data
- tai custom table
6. Object cache + autoload
Redis auttaa, mutta ei poista ongelmaa:
- ensimmäinen request lataa silti kaiken
- cache warmup ei ratkaise huonoa rakennetta
7. Pluginien auditointi
Etsi:
- isot option_name:t
- JSON stringit
- “all settings in one option” -mallit
Työkalut:
- Query Monitor
- WP-CLI option list
- custom SQL audit
8. WP-CLI analyysi
wp option list --autoload=on --format=table
9. Autoload cleanup -strategia
Prosessi:
- listaa kaikki autoloaded options
- järjestä koon mukaan
- tunnista harvoin käytetyt
- siirrä ne autoload = no
- siirrä raskaat data custom tableen
10. Custom table -ratkaisu
Kun data kasvaa:
wp_app_settings
wp_app_cache
wp_app_metrics
Hyödyt:
- ei autoload-kuormaa
- indeksoitavissa
- query-optimoitavissa
11. WordPress core vs plugin vastuu
Core:
- pienet config-arvot
- site-wide asetukset
Pluginit:
- usein liiallista autoload-käyttöä
12. Autoload + page builder ongelma
- voi kasvattaa autoloadin satoihin KB:ihin
- JSON-rakenteet isoja
Ratkaisu:
- asetusten pilkkominen
- revision cleanup
- export/import optimointi
13. Cache ei korvaa rakennetta
Väärä ajattelu:
“meillä on Redis, ei väliä autoloadista”
Todellisuus:
- autoload query tapahtuu ennen cachea
- DB load kasvaa silti
14. Yleisimmät virheet
- kaikki asetukset yhteen optioniin
- analytics-data optioneissa
- transientit autoloadilla
- pluginit jotka eivät koskaan siivoa dataa
- ei auditointia wp_options-tauluun
15. Paras käytäntö
Skaalautuva WordPress:
- autoload < 300 KB
- vain kriittinen config autoloadissa
- transientit cacheen
- isot datasetit custom tauluihin
- säännöllinen option auditointi
- pluginien kontrollointi
Yhteenveto
Autoloaded data on yksi WordPressin aliarvioiduimmista suorituskykyongelmista. Se vaikuttaa jokaiseen requestiin riippumatta siitä käytetäänkö dataa vai ei. Kun autoload-rakenne pidetään kevyenä ja isot datasetit siirretään pois wp_options-taulusta, sivuston suorituskyky paranee usein merkittävästi ilman mitään muita optimointeja.
Hyvin optimoitu autoload-strategia on yksi helpoimmista tavoista pienentää TTFB:tä ja vakauttaa suuria WordPress-sivustoja.