ETag

Čo je ETag a prečo existuje

ETag (Entity Tag) je HTTP identifikátor verzie reprezentácie zdroja. Slúži ako validator čerstvosti pri cachovaní a revalidácii: klient alebo edge cache si uloží ETag z odpovede a pri ďalšom požiadavku ho pošle späť v hlavičke If-None-Match. Server porovná, či sa reprezentácia nezmenila; ak nie, vráti 304 Not Modified bez tela, čím ušetrí prenos aj procesorový čas na origin serveri. ETag dopĺňa, prípadne nahrádza časový validator Last-Modified a pri správnom použití výrazne zlepšuje latenciu, stabilitu a efektívnosť siete.

Silný vs. slabý ETag

• Silný ETag: označuje bitovo identickú reprezentáciu. Ak sa líši čo i len jeden bajt (napr. iná kompresia), ETag je iný. Zapisuje sa bez prefixu, napr. "686897696a7c876b7e".
• Slabý ETag: označuje semanticky ekvivalentnú reprezentáciu (obsah rovnaký, no drobný rozdiel v serializácii). Zapisuje sa s prefixom W/, napr. W/"content-v42". Vhodné pri generovanom HTML, kde sa mení napr. timestamp renderu.

Základný revalidačný cyklus

1. Prvá odpoveď zo servera obsahuje ETag a ideálne aj Cache-Control (napr. public, max-age=300, stale-while-revalidate=30).
2. Po vypršaní max-age klient pošle If-None-Match: "ETAG_HODNOTA".
3. Server porovná verziu:
   • Ak sa nezmenila, vráti 304 Not Modified s pôvodnými cache hlavičkami; klient použije lokálnu kópiu.
   • Ak sa zmenila, vráti 200 OK s novým telom a novým ETag.

ETag vs. Last-Modified

• Presnosť: Last-Modified pracuje na úrovni sekúnd a môže byť nepresný pri rýchlych aktualizáciách; ETag je presnejší.
• Generovateľnosť: pri dynamickom obsahu je jednoduchšie generovať stabilný ETag než udržiavať korektný čas poslednej modifikácie.
• Sieťové náklady: oba umožňujú 304; ETag sa lepšie hodí, ak sa menia drobnosti, ktoré nemajú meniť čerstvosť (slabý ETag).
• Odolnosť voči hodinám: ETag nie je závislý na synchronizácii systémového času.

Aké hodnoty dávať do ETag

• Hash obsahu: napr. SHA-256/SHA-1 bajtov tela; silný a jednoznačný, no pozor na výkon pri veľkých objektoch.
• Verzia build-u: napr. "app-css-3f4b1a" alebo "article-12345-v7"; vhodné pri SSG/SSR, kde verziu poznáte vopred.
• ETag viazaný na metadáta: kombinácia veľkosti + času zmeny u statických súborov; rýchle, ale menej robustné.
• Slabý ETag pre HTML: napr. W/"post-42-v15" – stabilný aj pri neškodných zmenách formátovania.

Vplyv transformácií: kompresia, minifikácia, obrazové varianty

Ak CDN/edge vrstva mení reprezentáciu (Gzip/Brotli, minifikácia, preformátovanie obrázkov), silný ETag viazaný na originálne telo už nemusí zodpovedať výsledku. Riešenia:

• ETag per reprezentácia: generovať ETag až po transformácii (na edge), aby platil pre konkrétnu variantu (Vary: Accept-Encoding alebo Vary: Accept pre obrázky).
• Slabé ETagy pre HTML a transformovateľný obsah, kde je dôležitá sémantická rovnosť, nie bitová identita.
• Verziovanie URL pre statické zdroje (hash v názve súboru), čím znížite závislosť na ETag pri CSS/JS/obrázkoch.

Interakcia s CDN a edge cachingom

• Revalidácia na edge: CDN porovná ETag s originom pomocou If-None-Match, čím znižuje traffic na origin (len 304 namiesto plného tela).
• Surrogate-Control: môžete mať dlhší TTL na edge než v prehliadačoch; ETag udrží konzistenciu pri revalidácii.
• Tag-based purge: ETag je validator, nie mechanizmus invalidácie. Pre hromadné zneplatnenie používajte purge podľa tagov/keys.

Cache-Control a ETag: odporúčané kombinácie

• HTML: Cache-Control: public, max-age=60, stale-while-revalidate=30 + ETag (slabý). Krátky TTFB, častá revalidácia.
• API GET: public, max-age=120, stale-while-revalidate=60 + silný ETag (hash JSON tela).
• Statické assety s verziou v URL: public, max-age=31536000, immutable; ETag je voliteľný, no neuškodí.

Výkonnostné a operačné aspekty

• Výpočet ETag: pri veľkých súboroch hashing zaťaží CPU; zvážte predpočítanie počas build/deploy pipeline.
• Škálovanie originu: horizontálne škálované nody musia generovať identické ETagy pre rovnaký obsah (deterministická funkcia).
• Partial content: pri Range požiadavkách sa ETag vzťahuje na celé telo; zmeny musia meniť ETag aj pre range dotazy.

Bezpečnosť a súkromie

• Neodvodzujte ETag zo súkromných údajov (ID používateľa, token). ETag má byť deterministický a zdieľateľný.
• Prevencia „ETag tracking“: neviažte ETag na identitu používateľa a neuchovávajte per-user ETagy pre cacheovateľný obsah.
• Normalizácia hlavičiek: zamedzte cache poisoning – ETag generujte na normalizovanú reprezentáciu, nie na „raw“ variant ovplyvnený nečakanými hlavičkami.

Najčastejšie anti-patterny

• Nekonzistentný ETag v clustri: rôzne nody generujú odlišné ETagy pre rovnaké dáta – vedie k zbytočným 200 a zhoršeniu hit-rate.
• ETag viazaný na timestamp renderu (silný) pre HTML – drobné zmeny zbytočne invalidujú cache; použite slabý ETag.
• Kombinácia s transformáciami bez Vary – klient má ETag pre gzip, no dostane brótlovaný variant a revalidácia zlyhá.
• Ignorovanie revalidácie: krátke TTL bez ETag/Last-Modified mení CDN na „miss factory“.

ETag a SEO/AEO: vplyv na prehliadanie a indexáciu

• Efektívny crawl: vyhľadávače používajú podmienené dopyty; ETag podporuje rýchle 304, šetrí crawl budget a urýchľuje reindexáciu.
• Stabilita počas špičiek: revalidácia cez edge znižuje zaťaženie originu, takže roboty aj používatelia dostávajú konzistentné odpovede.
• AIO/AEO: multimodálne modely a asistenčné systémy preferujú stabilné, rýchlo revalidované HTML/API; ETag znižuje latenciu odpovedí.

Štýlové vzory implementácie

• Build-time ETag pre statické assety: hodnota je hash súboru; pri zmene obsahu sa zmení aj názov súboru (verziovanie URL) – dvojitá istota.
• DB-backed HTML: slabý ETag z verzie záznamu (napr. inkrement content_version); nemení sa pri nerelevantných zmenách layoutu.
• API JSON: silný ETag ako hash normovaných dát (bez whitu a nestabilných polí), aby ostal stabilný pri bezvýznamných zmenách serializácie.

Kompatibilita a zvláštnosti platforiem

• Objektové úložiská: niektoré služby (napr. object storage) generujú ETag ako hash častí; pri multipart uploadoch sa ETag nerovná jednoduchej MD5 obsahu.
• Reverse proxy: niektoré môžu stripovať alebo prepisovať ETag pri úpravách tela; sledujte nastavenia kompresie a filterov.
• Obrazové CDN: pre každý variant (šírka, formát) generujte samostatný ETag a používajte Vary: Accept a/alebo parameter šírky v URL.

Kontrolný zoznam pre nasadenie ETag

• Je ETag deterministický naprieč nódmi a releasmi?
• Používate slabý ETag tam, kde stačí sémantická rovnosť (HTML), a silný pre bajtovo stabilné objekty (API, assety)?
• Máte nastavené Cache-Control s stale-while-revalidate pre plynulé doručovanie?
• Edge/transformácie dopĺňa správny Vary (Accept, Accept-Encoding)?
• Revalidácie vracajú 304 s konzistentnými cache hlavičkami a novým Age?
• Monitorujete podiel 304 vs. 200, TTFB a hit ratio per PoP?

ETag ako základný stavebný kameň efektívnej cache

Správne navrhnutý ETag je lacný, presný a robustný validator čerstvosti. V spojení s disciplinovaným Cache-Control, rozumným použitím Vary a edge stratégiami (stale-while-revalidate, revalidácia na CDN) prináša nižšiu latenciu, menší dátový prenos, vyššiu stabilitu pri špičkách a rýchlejšie prehliadanie vyhľadávačov. Jeho sila spočíva v konzistencii: deterministická generácia, predvídateľné správanie pri transformáciách a jasné pravidlá používania naprieč celým stackom.