ETag v HTTP: význam, typy a použití při cachování a revalidaci

Co je ETag a proč existuje

ETag (Entity Tag) je HTTP identifikátor verze reprezentace zdroje. Slouží jako validátor čerstvosti při cachování a revalidaci: klient nebo edge cache si uloží ETag z odpovědi a při dalším požadavku ho odešle zpět v záhlaví If-None-Match. Server porovná, zda se reprezentace nezměnila; pokud ne, vrátí 304 Not Modified bez těla, čímž ušetří přenos i procesorový čas na originálním serveru. ETag doplňuje, případně nahrazuje časový validátor Last-Modified a při správném použití výrazně zlepšuje latenci, stabilitu a efektivnost sítě.

Silný vs. slabý ETag

Silný ETag: označuje bitově identickou reprezentaci. Pokud se liší i jediný bajt (např. jiná komprese), ETag je odlišný. Zapisuje se bez prefixu, například "686897696a7c876b7e".
Slabý ETag: označuje semanticky ekvivalentní reprezentaci (obsah stejný, ale drobný rozdíl v serializaci). Zapisuje se s prefixem W/, například W/"content-v42". Vhodné u generovaného HTML, kde se mění např. timestamp renderu.

Základní revalidační cyklus

První odpověď ze serveru obsahuje ETag a ideálně také Cache-Control (např. public, max-age=300, stale-while-revalidate=30).
Po vypršení max-age klient odešle If-None-Match: "ETAG_HODNOTA".
Server porovná verzi:
- Pokud se nezměnila, vrátí 304 Not Modified s původními cache hlavičkami; klient použije lokální kopii.
- Pokud se změnila, vrátí 200 OK s novým tělem a novým ETag.

ETag vs. Last-Modified

Přesnost: Last-Modified pracuje na úrovni sekund a může být nepřesný při rychlých aktualizacích; ETag je přesnější.
Generovatelnost: při dynamickém obsahu je snazší generovat stabilní ETag než udržovat korektní čas poslední modifikace.
Síťové náklady: oba umožňují 304; ETag je vhodnější, pokud se mění drobnosti, které nemají ovlivnit čerstvost (slabý ETag).
Odolnost vůči času: ETag není závislý na synchronizaci systémového času.

Jaké hodnoty dávat do ETag

Hash obsahu: například SHA-256 nebo SHA-1 bajtů těla; silný a jednoznačný, ale třeba dbát na výkon u velkých objektů.
Verze build-u: např. "app-css-3f4b1a" nebo "article-12345-v7"; vhodné u SSG/SSR, kde verzi znáte předem.
ETag navázaný na metadata: kombinace velikosti + času změny u statických souborů; rychlé, ale méně robustní.
Slabý ETag pro HTML: např. W/"post-42-v15" – stabilní i při neškodných změnách formátování.

Vliv transformací: komprese, minifikace, obrazové varianty

Pokud CDN/edge vrstva mění reprezentaci (Gzip/Brotli, minifikace, přeformátování obrázků), silný ETag navázaný na originální tělo již nemusí odpovídat výsledku. Řešení:

ETag per reprezentace: generovat ETag až po transformaci (na edge), aby platil pro konkrétní variantu (Vary: Accept-Encoding nebo Vary: Accept u obrázků).
Slabé ETagy pro HTML a obsah podléhající transformacím, kde je důležitá semantická rovnost, ne bitová identita.
Verzování URL pro statické zdroje (hash v názvu souboru), čímž snížíte závislost na ETag u CSS/JS/obrázků.

Interakce s CDN a edge cachingem

Revalidace na edge: CDN porovná ETag s originálem pomocí If-None-Match, čímž snižuje traffic na origin (jen 304 místo plného těla).
Surrogate-Control: můžete mít delší TTL na edge než v prohlížeči; ETag udrží konzistenci při revalidaci.
Tag-based purge: ETag je validátor, nikoli mechanismus invalidace. Pro hromadné zneplatnění používejte purge podle tagů/klíčů.

Cache-Control a ETag: doporučené kombinace

HTML: Cache-Control: public, max-age=60, stale-while-revalidate=30 + ETag (slabý). Nízké TTFB, častá revalidace.
API GET: public, max-age=120, stale-while-revalidate=60 + silný ETag (hash JSON těla).
Statické assety s verzí v URL: public, max-age=31536000, immutable; ETag je volitelný, ale neškodí.

Výkonnostní a operační aspekty

Výpočet ETag: u velkých souborů hashing zatěžuje CPU; zvažte předpočítání během build/deploy pipeline.
Škálování originu: horizontálně škálované nody musí generovat identické ETagy pro stejný obsah (deterministická funkce).
Partial content: u Range požadavků se ETag vztahuje na celé tělo; změny musí měnit ETag i pro range dotazy.

Bezpečnost a soukromí

Neodvozujte ETag ze soukromých údajů (ID uživatele, token). ETag má být deterministický a sdílený.
Prevence „ETag trackingu“: nevazujte ETag na identitu uživatele a neukládejte per-user ETagy pro cachovatelný obsah.
Normalizace hlaviček: zabraňte cache poisoning – generujte ETag na normalizované reprezentaci, nikoli na „raw“ variantě ovlivněné neočekávanými hlavičkami.

Nejčastější anti-patterny

Nekonzistentní ETag v clusteru: různé nody generují odlišné ETagy pro stejná data – vede k zbytečným 200 response a zhoršení hit-ratio.
ETag navázaný na timestamp renderu (silný) u HTML – drobné změny zbytečně invalidují cache; použijte slabý ETag.
Kombinace s transformacemi bez Vary – klient má ETag pro gzip, ale dostane brotli variantu a revalidace selže.
Ignorování revalidace: krátké TTL bez ETag/Last-Modified mění CDN na „miss factory“.

ETag a SEO/AEO: vliv na prohlížení a indexaci

Efektivní crawl: vyhledávače používají podmíněné dotazy; ETag podporuje rychlé 304, šetří crawl budget a urychluje reindexaci.
Stabilita během špiček: revalidace přes edge snižuje zátěž originu, takže roboti i uživatelé dostávají konzistentní odpovědi.
AIO/AEO: multimodální modely a asistenti preferují stabilní, rychle revalidované HTML/API; ETag snižuje latenci odpovědí.

Stylové vzory implementace

Build-time ETag pro statické assety: hodnota je hash souboru; při změně obsahu se změní i název souboru (verzování URL) – dvojnásobná jistota.
DB-backed HTML: slabý ETag z verze záznamu (např. inkrement content_version); nemění se při nerelevantních změnách layoutu.
API JSON: silný ETag jako hash normalizovaných dat (bez whitespace a nestabilních polí), aby zůstal stabilní při bezvýznamných změnách serializace.

Kompatibilita a zvláštnosti platforem

Objektová úložiště: některé služby (např. object storage) generují ETag jako hash částí; u multipart uploadů se ETag nerovná jednoduchému MD5 obsahu.
Reverse proxy: některé mohou stripovat nebo přepisovat ETag při úpravách těla; sledujte nastavení komprese a filtrů.
Obrazové CDN: pro každý variant (šířka, formát) generujte samostatný ETag a používejte Vary: Accept a/nebo parametr šířky v URL.

Kontrolní seznam pro nasazení ETag

Je ETag deterministický napříč nody a releasy?
Používáte slabý ETag tam, kde stačí semantická rovnost (HTML), a silný pro bajtově stabilní objekty (API, assety)?
Máte nastaveno Cache-Control s stale-while-revalidate pro plynulé doručování?
Edge/transformace doplňuje správný Vary (Accept, Accept-Encoding)?
Revalidace vrací 304 s konzistentními cache hlavičkami a novým Age?
Monitorujete poměr 304 vs. 200, TTFB a hit ratio na jednotlivých PoP?

ETag jako základní stavební kámen efektivní cache

Správně navržený ETag je levný, přesný a robustní validátor čerstvosti. Ve spojení s disciplinovaným Cache-Control, rozumným používáním Vary a edge strategiemi (stale-while-revalidate, revalidace na CDN) přináší nižší latenci, menší datový přenos, vyšší stabilitu při špičkách a rychlejší prohlížení vyhledávačů. Jeho síla spočívá v konzistenci: deterministická generace, předvídatelné chování při transformacích a jasná pravidla použití napříč celým stackem.