Back in 90s, when modems screamed and images loaded byte by byte, HTTP ETag was born.
Fast forward to 2026 and
ETags are still quietly making web faster.
No hype. No fancy frameworks. Just one tiny header doing real work.
In this AI era, where bandwidth feels unlimited and sloppy code ships daily, ETags are a beautiful piece of engineering that somehow still survives.
Fun Fact: I was unaware of it until I read it from one of the Zerodhas's tech blog fro 2020. I tried, I was sold.
What is an HTTP ETag?
ETag = Entity Tag - a fingerprint for a response.
Flow in one sentence:
Server sends data + ETag --> client sends it back later --> server replied "304 Not Modified"
No response body, no bandwidth just pure engineering. Simple.
What I was struggling with?
In one of my apps, the frontend polls the backend every 10 seconds to check device status.
Most of the time? Nothing changes.
Without caching:
- Same JSON sent again and again
- Same CPU Work, Same MySQL Query
- Same bandwidth wasted
Naturally someone asked, "Why not websocket or SSE?"
Because... it overkills.
- Data changes rarely
- 90% of response are identical
- websocket = connection management, reconnection logic, scaling pain
- SSE = long-lived connection, load balancer cries
In other word, I did not needed realtime, I needed Smarter Polling
Now the frontend sends:
If-None-Match: "abc123"
Backend answers:
304 Not Modified OR 200 OK + new JSON + New ETag
- ~90% of requests return 304
- Almost zero bandwidth
- No open sockets
- Works everywhere
Same polling. Now polite.
You can find the implementation here.
Final thought
ETag isn’t legacy tech. Before adding realtime infra, try the header that’s been solving this problem since 1997.
Sometimes the best optimization… is already in HTTP.
NOTE: While inspecting request, please make sure
Disble Cachein network panel is un-checked.
Top comments (0)