WordPress käyttää useita eri välimuistikerroksia samanaikaisesti, mutta moni kehittäjä tuntee niistä vain page cachen tai Redisin. Todellisuudessa WordPressissä on sisäinen cache-järjestelmä, joka vaikuttaa lähes kaikkeen: queryihin, metadataan, optioneihin ja objecteihin.
WordPressin cache-järjestelmä voidaan jakaa useaan tasoon:...
WordPressissä lähes kaikki kulkee object cachen kautta....
Ilman Redisia tai Memcachedia WordPress käyttää:...
Kun Redis tai Memcached lisätään:...
WordPress jakaa cachen ryhmiin:...
Joitain grouppeja ei koskaan tallenneta pysyvästi:...
Kun WP_Query suoritetaan:...
Kun post haetaan:...
wp_options on erittäin cache-riippuvainen....
Ongelma syntyy kun:...
Transients on WordPressin “kevyt cache API”....
Vaikein osa cache-järjestelmiä....
Vaikein osa cache-järjestelmiä....
Kun post päivitetään:...
WP_Query hyödyntää object cachea epäsuorasti....
WordPress ei oletuksena cacheta REST-vastauksia kunnolla....
Voit cachettaa osia HTML:stä:...
Kun cache vanhenee:...
Redis nopeuttaa erityisesti:...
Moderni WordPress käyttää yleensä:...
Hyvä object cache:...
Hyvä object cache:...
Moderni WordPress stack:...
Moderni WordPress stack:...
WordPressin sisäinen cache-järjestelmä on paljon enemmän kuin pelkkä page cache. Object cache, metadata cache, options cache ja transientit muodostavat kerroksellisen järjestelmän, joka vaikuttaa lähes kaikkiin...
Kun tämän rakenteen ymmärtää, suorituskyvyn optimointi muuttuu huomattavasti tehokkaammaksi.
Mitä WordPress cache tarkoittaa
WordPressin cache-järjestelmä voidaan jakaa useaan tasoon:
Browser Cache
↓
CDN / Edge Cache
↓
Page Cache
↓
Object Cache
↓
DatabaseWordPressin “sisäinen cache” viittaa yleensä:
- Object Cache APIin
- transientteihin
- runtime cacheen
Object Cache API
WordPressissä lähes kaikki kulkee object cachen kautta.
Keskeiset funktiot:
wp_cache_get()
wp_cache_set()
wp_cache_delete()Esimerkki:
wp_cache_set('user_1', $data, 'users', 3600);
$data = wp_cache_get('user_1', 'users');Runtime cache (oletus)
Ilman Redisia tai Memcachedia WordPress käyttää:
non-persistent in-memory cacheTämä tarkoittaa:
- cache toimii vain yhden requestin ajan
- seuraava request aloittaa tyhjästä
Silti tämä vähentää duplicate queryjä requestin sisällä.
Persistent object cache
Kun Redis tai Memcached lisätään:
WordPress → Redis → DatabaseCache säilyy requestien välillä.
Hyödyt:
- vähemmän DB-queryjä
- nopeampi admin
- nopeampi frontend
- parempi skaalautuvuus
Cache groups
WordPress jakaa cachen ryhmiin:
wp_cache_set($key, $data, 'posts');Tyypillisiä grouppeja:
- posts
- users
- terms
- options
Non-persistent groups
Joitain grouppeja ei koskaan tallenneta pysyvästi:
wp_cache_add_non_persistent_groups();Näitä käytetään request-kohtaiseen dataan.
WP_Query ja object cache
Kun WP_Query suoritetaan:
$query = new WP_Query([...]);WordPress cachettaa:
- post objectit
- metadata
- taxonomyt
Tämä vähentää duplicate SELECTejä.
Metadata cache
Kun post haetaan:
get_post_meta($id);Meta cache ladataan usein automaattisesti.
Tämä estää:
N+1 query problemOptions cache
wp_options on erittäin cache-riippuvainen.
get_option('siteurl');Options cache on yksi tärkeimmistä WordPressin optimoinneista.
Autoloaded options
Ongelma syntyy kun:
autoload = yesliikaa dataa.
Kaikki autoloaded optionit ladataan jokaisella requestilla.
Huono tilanne:
10MB autoload dataTransients API
Transients on WordPressin “kevyt cache API”.
set_transient('key', $data, 3600);Luku:
$data = get_transient('key');Ilman Redisia:
- tallentuu DB:hen
Redisin kanssa:
- tallentuu memoryyn
Transient vs object cache
Object cache
- request-level API
- low-level cache
Transient
- expiration built-in
- helpompi käyttää
Cache invalidation
Vaikein osa cache-järjestelmiä.
WordPress invalidioi automaattisesti paljon:
save_post()
clean_post_cache()Mutta custom cache pitää invalidioida itse.
Post cache invalidation
Kun post päivitetään:
clean_post_cache($post_id);Tämä poistaa:
- post objectit
- metadata
- taxonomy cachet
Query cache
WP_Query hyödyntää object cachea epäsuorasti.
Mutta monimutkaiset meta_queryt:
- eivät aina hyödy hyvin cachetuksesta
REST API cache
WordPress ei oletuksena cacheta REST-vastauksia kunnolla.
Usein tarvitaan:
- transient cache
- Redis layer
- edge cache
Fragment cache
Voit cachettaa osia HTML:stä:
$cached = wp_cache_get('hero_section');
if (!$cached) {
$cached = render_hero();
wp_cache_set('hero_section', $cached);
}
echo $cached;Cache stampede ongelma
Kun cache vanhenee:
100 requestia regeneroi saman datanRatkaisut:
- locking
- stale cache
- background regeneration
Redis object cache WordPressissä
Redis nopeuttaa erityisesti:
- WooCommerce
- isot sivustot
- membership-sivut
- multisite-ympäristöt
Cache layers käytännössä
Moderni WordPress käyttää yleensä:
Browser cache
↓
CDN cache
↓
Page cache
↓
Redis object cache
↓
MySQLMitä EI pidä cachettaa
- nonce data
- user-specific HTML
- checkout state
- session data ilman variaatiota
Cache hit ratio
Hyvä object cache:
90–99% hit ratioHuono:
paljon miss-tapauksiaYleisimmät cache-ongelmat
- liikaa autoloaded options
- invalidointi puuttuu
- transient-spämmi
- object cache ilman strategiaa
- cachettamaton REST API
- user-specific cache leak
Paras cache-arkkitehtuuri
Moderni WordPress stack:
- Edge cache/CDN
- NGINX FastCGI cache
- Redis object cache
- OPcache
- transient strategy
- targeted invalidation
Yhteenveto
WordPressin sisäinen cache-järjestelmä on paljon enemmän kuin pelkkä page cache. Object cache, metadata cache, options cache ja transientit muodostavat kerroksellisen järjestelmän, joka vaikuttaa lähes kaikkiin WordPress-requesteihin.
Kun nämä kerrokset ymmärretään ja niitä käytetään oikein yhdessä Redisin ja edge-cachen kanssa, WordPress pystyy käsittelemään erittäin suuria liikennemääriä tehokkaasti.
Monilla sivustoilla lisäosia asennetaan tarpeen mukaan vuosien ajan ilman selkeää hallintamallia. Lopputuloksena voi olla ympäristö... Mielenkiintoista on, että epäonnistumisen syyt liittyvät harvoin itse WordPressiin. Useimmiten ongelmat syntyvät suunnittelussa, viestinn... Verkkosivuston nopeus vaikuttaa lähes kaikkeen. Se vaikuttaa käyttäjäkokemukseen, hakukonenäkyvyyteen, konversioihin ja jopa palvelink... Kaikki trendit eivät muutu pysyviksi käytännöiksi, mutta osa niistä vaikuttaa merkittävästi siihen, miltä WordPress näyttää seuraav... Tietosuoja on noussut yhdeksi tärkeimmistä verkkosivustoihin liittyvistä aiheista. Samalla monet sivuston omistajat ja käyttäjät po... Moni ajattelee, että WordPress on turvaton juuri siksi, että se on niin suosittu. Todellisuudessa suosion vaikutukset ovat paljon moni... WordPressiin liittyy sitkeä mielikuva, jonka mukaan se olisi lähtökohtaisesti vähemmän turvallinen kuin täysin räätälöity verkkosivusto... Jokaisella WordPress-sivustolla on elinkaari. Se alkaa ideasta, kasvaa suunnittelun ja kehityksen kautta toimivaksi verkkopalveluksi...📚 Aiheeseen liittyvät artikkelit
8 artikkelia
WordPress-lisäosien hallinta ammattimaisesti
WordPress-projektien yleisimmät epäonnistumisen syyt
Nopean WordPress-sivuston anatomia
WordPress-kehityksen trendit, joita kannattaa seurata
Kuinka paljon tietoa WordPress kerää käyttäjistään?
Miten WordPressin suosio vaikuttaa sen tietoturvaan?
Voiko WordPress olla turvallisempi kuin räätälöity verkkosivusto?
WordPress-sivuston elinkaari ideasta poistamiseen
