ETag: Identifikátor verze souboru pro cache

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 pošle zpět v hlavičce If-None-Match. Server porovnává, zda se reprezentace nezměnila; pokud ne, vrátí 304 Not Modified bez těla, čímž š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 efektivitu sítě.

Silný vs. slabý ETag

Silný ETag: označuje bitově identickou reprezentaci. Pokud se liší alespoň jeden 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é při generovaném HTML, kde se mění například 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 poš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: u dynamického obsahu je jednodušší generovat stabilní ETag než udržovat korektní čas poslední modifikace.
Síťové náklady: oba umožňují 304; ETag se lépe hodí, pokud se mění drobnosti, které nemají ovlivnit čerstvost (slabý ETag).
Odolnost vůči hodinám: ETag není závislý na synchronizaci systémového času.

Jaké hodnoty vkládat do ETag

Hash obsahu: například SHA-256/SHA-1 bajtů těla; silný a jednoznačný, ale je třeba dávat pozor na výkon při velkých objektech.
Verze buildu: například "app-css-3f4b1a" nebo "article-12345-v7"; vhodné u SSG/SSR, kde verzi znáte předem.
ETag vázaný na metadata: kombinace velikosti + času změny u statických souborů; rychlé, ale méně robustní.
Slabý ETag pro HTML: například W/"post-42-v15" – stabilní i při nezávadný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 vázaný na originální tělo už 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 pro obrázky).
Slabé ETagy pro HTML a transformovatelný obsah, kde je důležitá sémantická shoda, nikoli bitová identita.
Verzionování URL pro statické zdroje (hash v názvu souboru), čímž snížíte závislost na ETag při CSS/JS/obrázcích.

Interakce s CDN a edge cachingem

Revalidace na edge: CDN porovná ETag s originem pomocí If-None-Match, čímž snižuje traffic na origin (vrací pouze 304 místo plného těla).
Surrogate-Control: můžete mít delší TTL na edge než v prohlížečích; 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ý). Krátký 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 neuškodí.

Výkonnostní a provozní aspekty

Výpočet ETag: u velkých souborů hashování 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).
Částečný obsah: 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íletelný.
Prevence „ETag tracking“: nevažte ETag na identitu uživatele a neuchovávejte per-user ETagy pro cacheovatelný obsah.
Normalizace hlaviček: zabraňte cache poisoning – ETag generujte na normalizovanou reprezentaci, nikoli na „raw“ variantu ovlivněnou 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 a zhoršení hit-rate.
ETag vá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 brotlovaný variant 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 asistivní systémy 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 (verzionování URL) – dvojitá 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čí sémantická rovnost (HTML), a silný pro bitově stabilní objekty (API, assety)?
Máte nastavené 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 per PoP?

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

Správně navržený ETag je levný, přesný a robustní validátor čerstvosti. V kombinaci s disciplinovaným Cache-Control, rozumným použití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žívání napříč celým stackem.