Browser caching article

main
Kaan Barmore-Genç 2 weeks ago
parent 985777a1e9
commit 9cf4164f88
Signed by: kaan
GPG Key ID: B2E280771CD62FCF

@ -62,7 +62,7 @@ images = [""]
# Home subtitle of the index page.
#
homeSubtitle = [
"Hi! I'm a Software Engineer at <a href='https://dendron.so'>Dendron</a>, and a recent Master's graduate from <a href='https://osu.edu'>the Ohio State University</a>. I'm an avid Linux user, an enthusiast of many programming languages, a <a href='/recipes'>home cook</a>, and an amateur gardener.",
"Hi! I'm a Software Engineer, an avid Linux user, an enthusiast of many programming languages, a <a href='/recipes'>home cook</a>, and an amateur gardener.",
"My interests include building web and mobile applications, both front and back end. Over the years I learned and used many programming languages and technologies, including JavaScript, TypeScript, React, React Native, Python, Java, C, C++, Clojure, Rust, and Haskell. Pretty much everthing I've worked on is open source and available on <a href='https://github.com/SeriousBug/'>my Github page</a>.",
]
@ -171,7 +171,7 @@ url = "https://github.com/SeriousBug/"
[[params.social]]
name = "mastodon"
url = "https://mastodon.technology/@kaan"
url = "https://fosstodon.org/@kaan"
me = true
[[params.social]]

BIN
content/img/browser-caching-after.png (Stored with Git LFS)

Binary file not shown.

BIN
content/img/browser-caching-before.png (Stored with Git LFS)

Binary file not shown.

@ -0,0 +1,47 @@
---
title: "Browser Caching: Assets not revalidated when server sends a 304 'Not Modified' for html page"
date: 2022-10-15T20:56:36-04:00
toc: false
images:
tags:
- dev
- web
---
I've been working on some web server middleware, and hit a weird issue that I
couldn't find documented anywhere. First, let's look at an overview of how
browser caching works:
If your web server sends an
[ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) header in
a HTTP response, the web browser may choose to cache the response. Next time the
same object is requested, the browser may add an
[If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match)
header to let the server know that the browser might have the object cached. At this point, the server should respond with the
[304 Not Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304)
code and skip sending the response. This can also happen with the
[Last Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified)
and
[If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since)
headers if `ETag` is not supported as well.
After implementing this in my middleware, I made a quick test website to try it
out. That's when I ran into a weird behavior: the browser would revalidate the
HTML page itself with the `If-None-Match` header, but when the server responded
with `304` it would not attempt to revalidate the linked stylesheets, scripts,
and images. The browser would not request them at all and immediately use the
cached version. It looks like if the server responds with `304` on the HTML
page, the browser assumes that all the linked assets are not modified as well.
That means that if the asset does change (you weren't using something like
fingerprinting or versioning on your assets), then the browser will use outdated
assets. Oops!
Luckily it looks like there's an easy solution: add `Cache-Control: no-cache`
header to your responses. `no-cache` doesn't actually mean "don't cache at all",
but rather means that the browser needs to revalidate objects before using
the cached version.
Without the `Cache-Control` header:
![Browser developer tools window, there is only 1 request for /](/img/browser-caching-before.png)
With the `Cache-Control` header:
![Browser developer tools window, there are 5 requests in total, including /, style.css, and 3 images.](/img/browser-caching-after.png)
Loading…
Cancel
Save