WordPressin autoloaded datan optimointi käytännössä

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.

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:

1. listaa kaikki autoloaded options
2. järjestä koon mukaan
3. tunnista harvoin käytetyt
4. siirrä ne autoload = no
5. 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

Elementor / WPBakery:

• 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.