cache rules everything

Caching is something most developers take for granted, but experience tells me time and time again that most developers also don’t understand how to configure their caching rules safely, correctly, or effectively. Do you know what no-cache means? Do you know what the Pragma header does? Do you know the difference between Last-Modified or ETag? Expires or Cache-Control? You will soon.

In this talk, we’ll remove the noise, get rid of everything we don’t need, and then step through a series of real-life scenarios to work out how to solve almost any caching situation with a series of questions.

Transcript

1. cache rules everything
2. hi, i’m harry
4. the best request is 
 the one that’s never made
5. key concepts
6. caching and revalidation
7. caching: how long can i reuse this file without checking for updates?
8. caching: how long can i reuse this file without checking for updates?
9. revalidation: how do i check that a file has changed after my cache time limit is up?
10. revalidation: how do i check that a file has changed after my cache time limit is up?
11. caching is a way of stopping the client speaking to the server…
12. …so revalidation shouldn’t 
 happen while a file is cached
13. fresh and stale
14. fresh: file is in cache and 
 within its expiry date
15. stale: file is in cache but has 
 passed its expiry date
16. fresh != most up-to-date
17. request and response
18. </> request response 1 2
19. 200 and 304 responses
20. 200: yep, i fetched a full response
21. </> request 200 response 1 2
22. </> request 200 response 1 2
23. 304: i checked, and you can 
 reuse the old response
24. </> conditional request 304 response 1 2 3
25. headers we don’t need
26. pragma
27. pragma: no-cache
28. pragma a caching header… sort of never meant to be used as a response header at all! should not be used
29. “pragma is not specified for http responses and is therefore not a reliable replacement for the general http/1.1 cache-control header.” — csswz.it/45ZBCV7
30. expires
31. expires: mon, 1 jan 2024 00:00:00 gmt
32. expires a caching header not really harmful, just cache-control is better cache-control has been preferred since january 1997 expire at an absolute time fails if a user has changed their system time can quickly turns fi les completely uncacheable
33. “if there is a cache-control header with the max-age or s-maxage directive in the response, the expires header is ignored.” — csswz.it/3EMHipn
34. expires cache-control
35. last-modified
36. last-modified: mon, 1 jan 2024 00:00:00 gmt
37. last-modified a revalidation header not really harmful, just etag is better date-of-creation is a proxy for change-of-content
38. headers we do need
39. cache-control
40. cache-control: private, max-age=300, must-revalidate
41. cache-control a caching header the rules and conditions for caching a response superseded expires in 1997 extensible
42. etag
43. etag: W/"680c753b-b8b"
44. etag: "8ca7aa679f9065d2017a57244e5068408"
45. etag a revalidation header weak or strong etags a hash of the cached response to compare to the remote version slightly more reliable than last-modified
46. caching
47. yes no cache-control: max-age=3600 cache-control: no-store can this response be cached at all?
48. max-age
49. max-age how long for, in seconds? relative, whereas expires is absolute relative to the moment it entered cache give very careful consideration to these values everything in this slide-deck is an example—do not just copy/paste
50. no-store
51. no-store no cache at all may store this response
52. cache-control: no-cache, no-store, must-revalidate
53. cache-control: no-cache, no-store, must-revalidate
54. yes no cache-control: no-cache cache-control: max-age=3600 does this response always have to be perfectly up-to-date?
55. no-cache
56. </> request 200 response 2 1 FORBIDDEN
57. no-cache forbids the browser from going straight to the cache always makes a trip to the server always incurs a round-trip of latency negligible performance bene fi t unless the fi le was quite large
58. yes no cache-control: public, max-age=3600 cache-control: private, max-age=3600 can this response be shared?
59. yes no cache-control: public, max-age=3600 cache-control: private, max-age=3600 can this response be shared?
60. public do you want many people to have access to the same fi le? e.g. all users need the same style.css exposes cacheability to cdns implied by the presence of max-age, so actually redundant comes with side-e ff ects, so usually best avoided
61. </> public </> </> </> </>
62. </> public </> </> </> </>
63. </> public </> </> </> </>
64. </> public </> </> </> </>
65. </> public </> </> </> </>
66. private only the requesting client may store the response prevents personalised responses being sent to other visitors not a replacement for or alternative to no-store
67. private </> </> </> </>
68. private </> </> </> </>
69. </> private </> </> </>
70. </> private </> </> </>
71. </> private </> </> </>
72. </> private </> </> </>
73. </> private </> </> </>
74. yes no cache-control: max-age=3600 cache-control: max-age=3600, 
 must-revalidate can we reuse this response for of fl ine users even if it’s stale?
75. must-revalidate
76. must-revalidate caches are permitted to serve stale content unless explicitly told otherwise e.g. when a browser is o ff l ine must-revalidate prohibits this behaviour leave it o ff of anything that might be useful o ffl ine, even if stale e.g. non-live train timetable, blog-post add to things that might lie to people if out of date e.g. live train timetable
77. “http allows caches to reuse stale responses when they are disconnected from the origin server. must-revalidate is a way to prevent this from happening…” — csswz.it/48pKjtf
78. yes no cache-control: max-age=3600, 
 stale-while-revalidate=600 cache-control: max-age=3600 can we tolerate a slightly out- of-date response while we perform revalidation?
79. stale-while-revalidate
80. stale-while-revalidate revalidation is synchronous; users see nothing until revalidation is complete can we get away with showing the old response to fi ll that gap? e.g. decorative image in a blog post
81. </> conditional request in the background 200 or 304 response in the background 200 response 2 3 1
82. yes no cache-control: max-age=3600, 
 s-maxage=86400 cache-control: max-age=3600 do we need to con fi gure cdns and browsers differently?
83. s-maxage
84. s-maxage why would you con fi gure shared and private caches di ff erently?
85. cache-busting is a myth
86. s-maxage why would you con fi gure shared and private caches di ff erently? you can’t empty your user’s cache, but you can empty your cdn’s set private cache to one hour and cdn cache to one day can clear cdn cache when you deploy users have maximum one-hour-old responses without having to come all the way back to origin
87. s-maxage daily (or on demand) hourly
88. yes no cache-control: max-age=2147483648, immutable cache-control: max-age=604800 is the fi le hashed, e.g. app.1ef702.js?
89. immutable
90. immutable make a ‘contract’ with the browser fi ngerprinted fi les cease to exist when they’re ‘changed’ we get a whole new fi le therefore, we can cache this fi le forever, and never need to revalidate it how long is forever?
91. 2,147,483,648 01111111111111111111111111111111
92. revalidation
93. interestingly, technically, we don’t actually need revalidation
94. we could just always fetch the whole response without checking if we actually needed to…
95. …but let’s not risk being wasteful
96. last- modified vs etag
97. both cause the browser to 
 emit conditional requests 
 once max-age has been met
98. </> conditional request if (200 response) if (304 response) </> 1 2 2
99. conditional requests
100. if-none-match: "8ca7aa679f9065d2017a57244e5068408"
101. if-modified-since: mon, 1 jan 2024 00:00:00 gmt
102. true: 200—here's your new response
103. false: 304—please keep using the cached response
104. prefer etag
105. prefer etag last-modified changes whenever a fi le is written, even if its contents don’t etag only changes if the fi le actually changes avoids false-positives and wasteful 200 responses
106. harryroberts in ~/cache-rules-everything on (main) » echo 'hello world' > revalidation » stat revalidation 
 ... sep 20 18:37:50 2023 » md5 revalidation 
 6f5902ac237024bdd0c176cb93063dc4 » echo 'hello world' > revalidation » stat revalidation 
 ... sep 20 18:39:23 2023 » md5 revalidation 
 6f5902ac237024bdd0c176cb93063dc4 same di ff erent
107. don’t revalidate hashed responses
108. because hashed files never change, there’s no need to revalidate them
109. what have we learned?
110. we shouldn’t expect to be able to fetch new content while a response is cached
111. we only have two jobs; 
 we only need two headers
112. cache-control: max-age=3600, must-revalidate etag: "edb18ab13566626184c376bc5ee2ea27"
113. expires (caching) and last-modified (revalidation) aren’t bad…
114. …but cache-control (caching) and etag (revalidation) are better
115. files that never change never 
 need to be revalidated
116. handy cheatsheets
117. weeks days hours minutes short medium long forever never
118. weeks days hours minutes short medium long forever never /my-account /news /store-locator /assets/product.jpg /assets/app.2efc38.ccs
119. cache-control versioned 
 assets non-versioned 
 assets immutable maximum expiry 
 (68 years) more granular 
 cache-control 
 directives etag
120. thank you for your time
121. further reading cache-control for civilians (harry roberts): csswz.it/3rvpFYb caching header best practices (simon hearne): csswz.it/45anbMy the headers we don’t want (andrew betts): csswz.it/46sqWOH
122. harry.is/for-hire