HTTP Caching
Webndsday
June 28, 2023
© David Buchmann
But... why?
- Response time
- Scale with load
- Save resources and money
HTTP: Your browser chats with the webserver
Request
GET /path
Accept-Encoding: text/html
Response
HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>
HTTP verbs
- GET
- HEAD
- POST
- PUT
- DELETE
- ...
HTTP response codes
- 1xx hold on
- 2xx here you go
- 3xx go away
- 4xx you fucked up
- 5xx I fucked up
twitter.com/stevelosh/status/372740571749572610
HTTP Cache Control
Cache control headers
- Cache Expiration Model
- Cache Validation Model
HTTP 1.1, RFC 2616, Sections 13.2 and 13.3
Cache Expiration
Cache-Control: s-maxage=3600, max-age=900
Expires: Thu, 15 May 2014 08:00:00 GMT
- s-maxage
- max-age
- Expires (HTTP 1.0 - avoid!)
Cache validation
- Application specific hash value on response
- On request, cheap check if hash changed
ETag: 82901821233
If-None-Match: 82901821233
304 Not Modified
Do not cache
Cache-Control: s-maxage=0, private, no-store
- s-maxage=0: Do not keep in cache
- private: For specific user, do not cache on proxies
- no-cache: Needs to be validated each time
- no-store: May never be placed in cache storage
Keep variants apart
Response content depends on request headers
Requests
GET /resource
Accept: application/json
GET /resource
Accept: text/xml
Response
Vary: Accept
Cache busting
- Very long cache lifetime for assets
- Append ?version to asset links
- Query string to miss the cache
<link rel="stylesheet" href="/css/style.css?v1" type="text/css"/>
...
<script src="/js/scripts.js?v1"></script>
CDN / Reverse Proxy
Control your reverse proxy
Surrogate-Control: max-age=900, no-cache
Surrogate-Control: no-store
Check documentation of your surrogate!
