Cache-Control fejléc

A Cache-Control válaszfejléc mondja meg a böngészőnek és a közbeeső gyorsítótáraknak (például a CDN-nek), hogy eltárolhatják-e a választ, és meddig használhatják fel újra. Ha a fejléc hiányzik, a gyorsítótárak saját szabályaik szerint döntenek, és az eredmény kiszámíthatatlan: egyszer túl sokat töltenek újra, máskor elavult tartalmat adnak.

Hogyan mérjük

A riport a nyitóoldal válaszában keresi a Cache-Control fejlécet.

• Megfelelő: van Cache-Control fejléc, bármilyen értékkel.
• Hiba: nincs ilyen fejléc.

A teszt csak a fejléc meglétét nézi, az érték helyességét nem. Csak a nyitóoldal HTML-jére vonatkozik, a CSS-, JavaScript- és képfájlok fejlécét nem méri.

Hogyan javítsd

Az MDN és a web.dev szerint a leggyakoribb értékek:

• no-cache: a válasz eltárolható, de a felhasználás előtt minden alkalommal egyeztetni kell a szerverrel. Nevével ellentétben nem tiltja a tárolást. Változó HTML-hez ez a biztonságos kezdőérték.
• no-store: a válaszból semmit nem szabad eltárolni (például bejelentkezett, személyes oldalaknál).
• max-age=<másodperc>: ennyi ideig friss a válasz, egyeztetés nélkül felhasználható. Verziózott, soha nem módosuló fájlokhoz (CSS, JS, képek) hosszú érték való, például max-age=31536000 (egy év).
• immutable: jelzi, hogy a válasz a frissességi ideje alatt nem változik.

A kártya a HTML-re a no-cache értéket adja: a böngésző és a CDN tárolhatja, de minden használat előtt megkérdezi a szervert, változott-e. A statikus fájlokra (CSS, JS, képek, betűtípusok) érdemes külön, hosszú max-age-et adni, ha a fájlnevük tartalmazza a verziót vagy a lenyomatot.

nginx

Két rész kell, egy http szintű map és egy server szintű add_header. A map csak a HTML-válaszokra ad no-cache értéket, és csak akkor, ha a háttéralkalmazás (például a WordPress) nem küldött saját Cache-Control fejlécet:

nginx (http blokk)

map "$upstream_http_cache_control:$sent_http_content_type" $hwp_cc {
    "~^:text/html" "no-cache";
    default "";
}

nginx (server blokk)

add_header Cache-Control $hwp_cc always;

Az add_header-t a server szintre tedd, ne location-be: az nginx dokumentációja szerint a direktívák csak akkor öröklődnek az előző szintről, ha az adott szinten nincs add_header. Egy location-be írt add_header így kikapcsolná a server szinten beállított többi fejlécet (például a biztonsági fejléceket).

Apache (.htaccess)

.htaccess

<IfModule mod_headers.c>
    Header setifempty Cache-Control "no-cache" "expr=%{CONTENT_TYPE} =~ m#^text/html#"
</IfModule>

A setifempty csak akkor állítja be a fejlécet, ha még nincs: a WordPress által bejelentkezett felhasználónak vagy kosárnál küldött no-store / private értéket így nem írja felül.

WordPress

Ha nem érsz el szerverkonfigot, egy saját mu-plugin (kötelezően használt bővítmény) fájlba tehetsz kódot, amely a send_headers hookra kapcsolódik. A kód csak a kijelentkezett látogatók oldalára állít no-cache fejlécet:

mu-plugin

<?php
add_action( 'send_headers', function () {
    if ( ! is_user_logged_in() ) {
        header( 'Cache-Control: no-cache' );
    }
} );

Gyorsítótár-bővítmények és tárhelyek gyakran maguk is állítanak Cache-Control fejlécet; ha a riport szerint van fejléc, de te nem állítottál be semmit, valószínűleg ők teszik.

Cloudflare

Cloudflare mögött a böngészőben tárolás idejét (Browser Cache TTL) és a CDN-ben tárolás idejét (Edge Cache TTL) a Cache Rules szabályokkal állíthatod. Ezek a beállítások szabályozzák, mit küld a Cloudflare a látogatónak; a részleteket a Cloudflare dokumentációja tartalmazza.

Hogyan ellenőrizd

Futtasd újra a riportot, vagy parancssorból:

Terminál

curl -sI https://pelda.hu/ | grep -i cache-control

Ha a kimenet üres, a fejléc még hiányzik. Cache-kerülő kéréssel (például ?v=123 a cím végén) is próbáld meg, ha a szerver előtt oldal-gyorsítótár van.