WordPressin HTTP-välimuisti ja Cache-Control-headerit

WordPressin suorituskykyä optimoitaessa HTTP-välimuisti ja Cache-Control-headerit ovat usein se näkymätön kerros, joka ratkaisee kaiken. Ne eivät näy teemoissa, eivät lisäosien asetuksissa, eivätkä edes WordPressin hallintapaneelissa – mutta ne määrittävät, kuinka usein WordPressiä ylipäätään ajetaan.

Ilman oikein määriteltyjä HTTP-headerita WordPress tekee työtä turhaan. Oikein määriteltynä sama sisältö voidaan palvella tuhansille käyttäjille ilman, että PHP tai tietokanta herää kertaakaan.

Mitä HTTP-välimuisti oikeasti tarkoittaa

HTTP-välimuisti ei ole WordPress-ominaisuus. Se on selainten, reverse proxyjen ja CDN-verkkojen noudattama standardi. WordPressin rooli on vain yksi: lähettää oikeat headerit.

HTTP-välimuisti toimii kolmella tasolla:

• selaimen välimuisti

• välikerrokset (CDN, reverse proxy)

• origin-palvelin

Cache-Control-headerit kertovat näille kaikille, miten sisältöä saa käsitellä.

Cache-Control on sopimus, ei vihje

Cache-Control-header ei ole toive. Se on eksplisiittinen sääntö. Kun WordPress lähettää vastauksen, se samalla sanoo:

• saako tämän cachettaa

• kuinka kauan

• kenelle

• missä

Jos säännöt ovat ristiriitaisia tai puutteellisia, välimuisti ei toimi odotetusti.

Tärkeimmät Cache-Control-direktiivit WordPressissä

public ja private

public tarkoittaa, että vastaus voidaan cachettaa:

• selaimessa

• CDN:ssä

• reverse proxyssa

private tarkoittaa, että vastaus:

• kuuluu vain yhdelle käyttäjälle

• ei saa mennä jaettuun cacheen

WordPressissä:

• anonyymi sisältö → public

• kirjautuneet käyttäjät → private

Jos tätä ei erotella, seuraukset ovat vakavat.

max-age ja s-maxage

max-age määrittää:

• kuinka kauan selain saa cachettaa vastauksen

s-maxage määrittää:

• kuinka kauan jaettu cache (CDN, proxy) saa cachettaa

WordPressissä tämä ero on kriittinen. Hyvä malli on:

• pitkä s-maxage anonyymille sisällölle

• lyhyempi max-age selaimessa

Tämä antaa hallitun päivittyvyyden ilman backend-kuormaa.

no-cache ja no-store

no-cache ei tarkoita “älä cacheta”. Se tarkoittaa:

• cache sallittu

• mutta jokainen pyyntö pitää validoida

no-store tarkoittaa:

• älä tallenna ollenkaan

WordPress käyttää näitä usein varmuuden vuoksi, mikä:

• estää edge cachingin

• tekee CDN:stä hyödytöntä

• kasvattaa backend-kuormaa

Liiallinen no-cache on yksi yleisimmistä virheistä.

WordPressin oletuskäyttäytyminen

WordPress on varovainen oletuksena

WordPress:

• lähettää evästeitä herkästi

• asettaa no-cache-headerit adminissa

• ei cacheta HTML:ää oletuksena

Tämä on turvallista, mutta huonoa suorituskyvyn kannalta. Oletuslogiikka on tehty toiminnallisuus edellä, ei skaala edellä.

Evästeet ja välimuisti

Yksi WordPress-eväste voi:

• estää koko HTML-sivun cachettamisen

• ohittaa CDN:n

• pakottaa backend-käsittelyn

Siksi WordPress-ympäristössä cache-logiikka pyörii usein evästeiden ympärillä, ei URLien.

HTTP-välimuisti ja reverse proxy

Nginx, Varnish ja WordPress

Reverse proxy käyttää HTTP-headereita päätöksenteossa:

• cache hit vai miss

• TTL

• invalidointi

Jos WordPress lähettää ristiriitaisia headerita, reverse proxy ei voi korjata sitä automaattisesti.

Hyvä WordPress-arkkitehtuuri:

• erottaa anonyymin ja kirjautuneen liikenteen

• lähettää selkeät Cache-Control-headerit

• antaa proxyn tehdä työnsä

Edge caching ja CDN

CDN ei ole taikalaatikko. Se noudattaa HTTP-standardeja. Jos WordPress sanoo “älä cacheta”, CDN tottelee.

Suurin virhe Cloudflaren ja WordPressin yhdistelmissä on:

• yrittää pakottaa cachea ilman ymmärrystä headereista

Kun headerit ovat kunnossa, CDN toimii ilman hackeja.

Cache-Control ja dynaaminen sisältö

Kaikkea ei tarvitse cachettaa

Hyvä HTTP-välimuisti ei tarkoita:

• että kaikki on cachettavaa

• että TTL on aina pitkä

Se tarkoittaa:

• että cachettava ja ei-cachettava sisältö on eroteltu

WordPressissä tämä tarkoittaa:

• julkinen sisältö → aggressiivinen cache

• käyttäjäkohtainen sisältö → private tai no-store

Vary-header ja WordPress

Miksi Vary on vaarallinen

Vary-header kertoo, että cache riippuu jostain muuttujasta, esimerkiksi:

• Cookie

• Accept-Encoding

Vary: Cookie on erityisen ongelmallinen WordPressissä, koska:

• se moninkertaistaa cache-avaimet

• pienikin eväste muuttaa vastauksen “uudeksi”

Liiallinen Vary tekee cache-hiteistä harvinaisia.

Cache-invalidaatio HTTP-tasolla

TTL vs purge

WordPressin HTTP-välimuisti perustuu yleensä:

• TTL-arvoihin

• tai erillisiin purge-pyyntöihin

Lyhyt TTL:

• yksinkertainen

• turvallinen

• vähemmän tehokas

Purge:

• tehokas

• vaatii integraation

• voi mennä helposti överiksi

Useimmat WordPress-sivustot toimivat parhaiten hybridimallilla.

Yleisimmät virheet HTTP-cacheissa

Yleisimpiä virheitä ovat:

• no-cache kaikkialla

• evästeiden huolimaton käyttö

• Vary: Cookie ilman tarvetta

• sama cache-strategia kaikelle sisällölle

• WordPress-lisäosan ja proxyn ristiriitainen logiikka

Nämä eivät näy heti, mutta näkyvät laskussa ja kuormassa.

Milloin HTTP-välimuisti on oikein tehty

HTTP-välimuisti on onnistunut, kun:

• backend-kuorma laskee merkittävästi

• TTFB paranee globaalisti

• liikennepiikit eivät näy palvelimessa

• cache toimii ilman jatkuvaa purkua

Usein paras merkki onnistumisesta on se, että siitä ei tarvitse keskustella enää.

Lopuksi: Cache-Control on WordPressin todellinen suorituskykyrajapinta

WordPressin suorituskyky ei ala PHP:stä eikä pääty JavaScriptiin. Se alkaa siitä, kuinka usein WordPressiä ylipäätään tarvitsee ajaa.

Cache-Control-headerit ovat se rajapinta, jolla WordPress keskustelee selainten, CDN:ien ja proxyjen kanssa. Kun tämä keskustelu on selkeää, järjestelmä toimii rauhallisesti ja ennustettavasti.

Kun se on sekavaa, mikään määrä palvelintehoa ei pelasta tilannetta.