Check out a free preview of the full Web Performance Fundamentals, v2 course
The "Caching" Lesson is part of the full, Web Performance Fundamentals, v2 course featured in this preview video. Here's what you'd learn in this lesson:
Todd discusses the concept of caching and its importance in improving the return user experience. He explains server caching and browser response caching, and how caching headers and cache control and expires headers can be used to optimize the caching process.
Transcript from the "Caching" Lesson
[00:00:00]
>> Todd Gardner: All right, we're gonna talk about improving the return user experience. Now, this is important because it wouldn't be a web-performance talk unless we talk about caching. All right, let's talk about caching. So we already talked a little bit about server caching, because that's largely what we implemented with our CDN.
[00:00:14]
Is we told the server is rather than having our original host produce the content every time, we cached it inside of our CDN, which is a host closer to our end users. That's one kind of caching. The next kind of caching is we could do a browser response caching.
[00:00:32]
So the next time our users make a request to our CDN, let's say it's asking for hero-desktop.png. What would normally happen is the CDN would say, great, here's the bytes and start spewing out all those bytes back to the user about it. Now, what we could do, and through all those bytes, there's all the overhead that goes with making that request.
[00:00:56]
So if it was the first request, it has to do a DNS lookup and a TCP and all those sort of things, the initial request overhead, the response, the processing. There's a bunch of work that goes behind the scenes in the browser to do that. And so if we wanted to get around some of that, the CDN could return caching headers.
[00:01:15]
It could say, hey user, here's some information about this file I just returned. Here's an Etag, which is like a hash. It's like, here's an ID that represents the contents of this file that I gave you. And the last time this file was modified was September 23rd. Well, that's the user's browser, the browser will remember that information.
[00:01:39]
And the next time the user comes back, they come back to buy some more stickers from me, they're going to include that data on the next request. They'll be in the form of an If-None-Match, the contents of the Etag, and If-Modified-Since, the contents of the last modified date.
[00:01:57]
It's essentially saying, hey, here's the thing I already have, you gave me last time, do you have something newer than this? And the CDN or your host will look at it and if it matches, if it's the same ID and the same date. Instead of returning all of those bites and streaming that image back out, it returns an empty response that says 304 Not Modified.
[00:02:19]
You got the thing, man, go ahead and keep using it, and the request is a lot smaller. Now, that's one way we can do it, but there's a second way we could do it, because what we just did still involved a request. A request still had to be sent and returned.
[00:02:37]
And if we didn't have a CDN, we'd still have to pay the Amsterdam to Minneapolis tax of that round trip, even though it's an empty response. So another way we can do this is with Cache-Control and Expires headers. It's rather than saying, hey, let me describe this file so we can make sure you always have the latest version.
[00:02:58]
We can say, this file that I gave you, you can keep it for this many seconds, and it doesn't expire until this date. You can explicitly set that. And then what will happen is it says to the user or to the user's browser, when the next time they ask for it, if that date hasn't passed yet, the request is free, it doesn't happen.
[00:03:25]
The request is never even made. It will say from disk cache, because the browser will just never make that overhead request to the host, it will use that value until December 31, 2025. Now, this is great, but it's also how you get in trouble. Because if you tell the browsers to cache a JavaScript file, it's just called scripts.js, all those browsers will cache that JavaScript file, that version of that file, until 2025, December 31.
[00:04:01]
So if you want to change that JavaScript file, you've gotta change the name of it, or the user will continue operating on the old one forever. This is one of the reasons why just about every JavaScript bundler will stick some unique string into the file name. It's to break caching problems, like this, so that you can cache or tell the end user's browser to cache files for long periods of time.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops