ETag: Identifikátor verze souboru pro cache

LLM a generativní AI
Dalimil
ETag: Identifikátor verzie súboru pre 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 jej pošle zpět v hlavičce If-None-Match. Server porovná, zda se reprezentace změnila; pokud ne, vrátí 304 Not Modified bez těla, čímž ušetří přenos i výpočetní čas na origin 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ší byť jen jeden bajt (např. jiná komprese), ETag je jiný. Zapisuje se bez prefixu, např. "686897696a7c876b7e".
  • Slabý ETag: označuje sémanticky ekvivalentní reprezentaci (obsah je stejný, ale v serializaci je drobný rozdíl). Zapisuje se s prefixem W/, např. W/"content-v42". Hodí se pro generované HTML, kde se mění např. časové razítko renderování.

Základní revalidační cyklus

  1. První odpověď ze serveru obsahuje ETag a ideálně také Cache-Control (např. public, max-age=300, stale-while-revalidate=30).
  2. Po vypršení max-age klient odešle If-None-Match: "ETAG_HODNOTA".
  3. Server porovná verze:
    • Pokud se nezměnila, vrátí 304 Not Modified s původními cache hlavičkami; klient použije místní 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 s přesností na sekundy a při rychlých aktualizacích může být nepřesný; ETag je přesnější.
  • Generování: u dynamického obsahu je snazší generovat stabilní ETag než udržovat správný čas poslední změny.
  • Náklady na přenos: oba umožňují 304; ETag se hodí více, pokud se mění drobnosti, které nemají ovlivnit čerstvost (slabý ETag).
  • Odolnost vůči systémovému času: ETag není závislý na synchronizaci systémového času.

Jaké hodnoty používat v ETag

  • Hash obsahu: např. SHA-256/SHA-1 bajtů těla; je silný a jednoznačný, pozor však na výkon u velkých objektů.
  • Verze buildu: např. "app-css-3f4b1a" nebo "article-12345-v7"; vhodné pro SSG/SSR, kde verzi znáte předem.
  • ETag navázaný na metadata: kombinace velikosti a času změny u statických souborů; je rychlá, ale méně robustní.
  • Slabý ETag pro HTML: např. W/"post-42-v15" – zůstává 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, změna formátu obrázků), silný ETag navázaný na původní tělo již nemusí odpovídat výsledku. Řešení:

  • ETag pro každou reprezentaci: 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á rovnost, nikoli 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 originem pomocí If-None-Match, čímž snižuje provoz na originu (jen 304 místo celého těla).
  • Surrogate-Control: na edge můžete nastavit delší TTL než v prohlížečích; ETag při revalidaci zajistí konzistenci.
  • Vyprázdnění cache podle tagů: ETag je validátor, nikoli mechanismus invalidace. Pro hromadnou invalidaci používejte vyprázdnění cache 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 těla JSON).
  • Statické prostředky s verzí v URL: public, max-age=31536000, immutable; ETag je volitelný, ale neuškodí.

Výkonnostní a provozní aspekty

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

Bezpečnost a soukromí

  • Neodvozujte ETag ze soukromých údajů (ID uživatele, token). ETag má být deterministický a sdílitelný.
  • Prevence sledování pomocí ETag: nenavazujte ETag na identitu uživatele a neuchovávejte ETagy pro jednotlivé uživatele u cachovatelného obsahu.
  • Normalizace hlaviček: zabraňte otravě cache – ETag generujte pro normalizovanou reprezentaci, nikoli pro „raw“ variantu ovlivněnou neočekávanými hlavičkami.

Nejčastější anti-patterny

  • Nekonzistentní ETag v clusteru: různé uzly generují odlišné ETagy pro stejná data – vede to ke zbytečným odpovědím 200 a zhoršení míry zásahů cache.
  • ETag navázaný na časové razítko renderování (silný) pro HTML – drobné změny zbytečně invalidují cache; použijte slabý ETag.
  • Kombinace s transformacemi bez Vary – klient má ETag pro gzip, ale dostane variantu komprimovanou pomocí Brotli a revalidace selže.
  • Ignorování revalidace: krátké TTL bez ETag/Last-Modified mění CDN v „továrnu na cache miss“.

ETag a SEO/AEO: vliv na procházení a indexaci

  • Efektivní procházení: vyhledávače používají podmíněné požadavky; ETag podporuje rychlé 304, šetří rozpočet na procházení a urychluje reindexaci.
  • Stabilita během špiček: revalidace přes edge snižuje zatížení originu, takže roboti i uživatelé dostávají konzistentní odpovědi.
  • AIO/AEO: multimodální modely a asistenční systémy upřednostňují stabilní HTML/API s rychlou revalidací; ETag snižuje latenci odpovědí.

Stylové vzory implementace

  • ETag při sestavení pro statické prostředky: hodnotou je hash souboru; při změně obsahu se změní i název souboru (verzování URL) – dvojitá jistota.
  • HTML napojené na databázi: slabý ETag odvozený od verze záznamu (např. inkrement content_version); nemění se při nerelevantních změnách rozvržení.
  • 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ř. úložiště objektů) generují ETag jako hash částí; u vícedílných nahrávání se ETag nerovná jednoduchému MD5 obsahu.
  • Reverse proxy: některé mohou při úpravách těla ETag odstraňovat nebo přepisovat; sledujte nastavení komprese a filtrů.
  • Obrazové CDN: pro každou variantu (šíř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říč uzly a releasy?
  • Používáte slabý ETag tam, kde stačí sémantická rovnost (HTML), a silný pro objekty se stabilním obsahem po bajtech (API, prostředky)?
  • Máte nastavené Cache-Control s stale-while-revalidate pro plynulé doručování?
  • Doplňují edge/transformace správný Vary (Accept, Accept-Encoding)?
  • Vrací revalidace 304 s konzistentními cache hlavičkami a novým Age?
  • Sledujete podíl 304 vůči 200, TTFB a poměr zásahů do cache pro jednotlivé 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žitím Vary a strategiemi edge cachování (stale-while-revalidate, revalidace na CDN) přináší nižší latenci, menší objem přenesených dat, vyšší stabilitu během špiček a rychlejší procházení ze strany vyhledávačů. Jeho síla spočívá v konzistenci: deterministickém generování, předvídatelném chování při transformacích a jasných pravidlech používání napříč celým stackem.