Cache Control Headers Explained

CSD.

Welcome to Syntax.

On this Monday, hasty treat, the 4 164th it. Episode of Syntax. We're gonna be talking about cache control headers. Now this is something that we're gonna have to be spending more time on as web developers as tools start to utilize browser fundamentals, and things like that just a little bit more. Right? I I think we're seeing this with tools like Remix. See it. I know SvelteKit makes us nice and easy. I'm sure, other other tools do as well. So this all started off with a Question from Chris m. But before we get into that, let's take a minute to talk about our sponsors and introduce, Wes Boss, As always, who is the cohost of this show, Wes,

coming live from Canada. How's it going? It's going good. Let's talk about our sponsor, which is Century Century does error exception and performance tracking.

It's just an awesome company for I specifically use it to track all the bugs that I have on all my own websites. So I we just recently launched a whole big update, Both to the back end as well as to the big, the front end viewing experience.

And with that, as soon as we'd launch that sucker, we had the century issue page open, and we were just sort of eyes peeled watching exactly what was happening, and and you start to see these issues pop up. You fix them. You, say they are fixed, and you hope they do not come back.

You can you could tie it to a specific version of your code, which is good because, like, one thing is if you have an error that keeps popping up and you fix But somebody hasn't refreshed the page yet, the error still comes. So you could say, alright. Well, this this is fixed in version 4.2 of our software, so ignore it. Right? They They just do so much. They hold performance, user feedback. You name it, they got it. Check it out. Century.i0.

Make sure you use a coupon code tasty treat. Gets you 2 months for free. Thank you, Century, for sponsoring.

This episode is also sponsored by LogRocket at loggrocket.comforward/syntax.

The perfect place to see all of your errors and exceptions happen in a visual scrubbable replay, but not not just that. It allows you to really understand user behavior on your site. Now these are some things that I think have been somewhat recently added to LogRocket as these tools to really gain more insight into conversion rates, it. Surface UX issues. So not only UI and code bugs, but also UX issues. Easily build custom funnels it. Based on events for clay clicks, views, checkouts, and custom events, and see how your your users journey through your site, it. Engage, retain your customers with LogRocket in addition to seeing all of your bugs. So check it out at logrocket it.comforward/syntax.

Sign up, and you'll get 14 days for free. Thank you so much for LogRocket for sponsoring.

Okay. So let's get into it. It. This actually came to us from a really good potluck question. Sometimes that happens where we're we'll get a potluck question that's so good. We're like, Man, we could we could spend the whole show talking about this. So this question comes from Chris m, and it says, hey, Scott and Wes. Love listening to the show overnight while I'm working in retail.

And one of the things I've been working on lately with my website has been performance and utilizing things like CloudFlare Workers to make the experience as fast as it over my end users as it's very image heavy. Think photo galleries.

My question and struggle has been with caching, cache control headers and would love a better explanation on some of the fields that I just blindly copy and paste from Internet resources.

And I just truly, And just don't truly understand some of the things I put down mean or do. Help exclamation point. So let's talk a little bit of the cache control headers caching in general and how these things can help us build up more performant applications as really, sometimes, you know, I think people they spend so much time working on, really custom solutions or working really hard it. On performance, reducing kilobytes here and there, and then they skip things like caching that could really even make a much bigger difference in much it. Less effort. So, Wes, do you want to, explain a little bit about what a header is, and then we can get into cache control headers? So when you have either a request or a response,

a request, it comes from you and the browser Are sending a request to the server for an image, a HTML file, a list of dogs, you name it. It. And then what comes back from the server is a response.

And both the request as well as the response can have Additional pieces of metadata set along with the request or response, and that could be as simple as sending over an API key Or, sending over what type of, response you're sending. Is it JSON or is it text? You know, there's lots of metadata that goes along with the with the with the request or response.

And one of those headers that comes along with a request or a response is, the cache control headers, which tells either the browser or the server how or specifically, And let's get into the cache control header. So there's kinda a couple different versions of caching, and maybe we should What caching is just in a second. So caching means that you are saving the result That of something that has been generated, whether it is an image, whether it's some HTML, Whether it is a list of dogs, all of those things take work.

Whether that work is that the server needs to go to the database and get it, whether that work is your phone needed to download a huge image of a dog.

All that work doesn't necessarily have to be replicated Should you want that resource a second time.

And that's what caching is, is that we will put it in a bag somewhere so that we can retrieve it from that bag in the future, if it is still fresh.

And there's a couple different, like, areas of cache control. There is a browser level cache, so, you have an image of a dog, and then you go back to that page. A minute later, you have an image of a dog again. Hokey. Do you have to download that twice? No. Your browser will cache that for you.

There's also a CDN level. So you go to your, Let's say you want a list of dogs. You hit you hit your server for endpoint forward slash dogs dot JSON.

Your the 1st time your server is gonna generate that, and and go ahead and maybe make a a list of dogs or maybe an HTML file. But the a second time. Maybe it doesn't make sense to regenerate all that. That can be stored at a CDN level.

That's generally referred to as a public cache because that's, like, that's stuff everybody can have, whereas, there's other there's a a private cache, which is generally your browser level.

And then finally, there's, like, a reverse proxy that can sort of sit in front of your,

it. Server as well. I mean, we cache a lot of our server stuff automatically in Redis, which is like an in memory cache. It. So, you know, even in that that that degree, like, caching, like you mentioned, is really just saving things for

Later, if they're not changed, to make that operation faster in the future. And do you use the cache control to specify whether they should be cached in Redis, or is that a different it. Approach.

So we we do well, we use a plug in for it. So I honestly don't know how it works under the hood. In fact, we just give it a time to live. So that's actually, like, a big thing in caching as you'll often see. TTL, which means time to live. How long should this thing live before we regenerate it and grab a new version of it and spend the resources to get that new version of it? So TTL, Time to live. And, and and time to live is in seconds, which can feel kind of obnoxious sometimes. Right? We we have a a lot of seconds you're having to calculate. So it. Actually, I'll I'll link this in the in the show notes. I made a a quick little little time to live calculator in Svelte in the Svelte REPL that you can just, like, type in, Oh, I wanna cache this for 5 days or 2 months or whatever, and it just gives you the amount of seconds in that. So I'll make sure that's linked up. So benefits of a cache,

a, it reduces the load on your server, b, it reduces bandwidth used, like we talked about, and then, c, probably the biggest one is the client speed, Meaning that if you visited a website before, there are resources on that website That don't necessarily have to be redownloaded and reparsed and all that kind of stuff. So making everything as fast as possible Is sort of the benefit of the cash as well as,

like, at the end of the day, it can save you money, and it can save your your users money who are paying for the bandwidth and and all that kind of stuff. It can also increase those user misery scores on on Sentry. Right? Can that Oh, yeah. There you go. Make your site feel way faster for your users. So which is honestly the the biggest plus in my mind is that perceived time and actual real time of loading your site will be better for those users. Exactly.

So the the question we have now is how do you, specify how long things are cached? And luckily, there are standards for that.

These are through things called directives, and directives are essentially So the header is called cache control, and a directive is essentially how you want to describe how long the cache should be or when it should When it is stale or if it is immutable, we'll talk about that. So there are cache control response directives.

That means they are set on your server and sent To the client sent to the browser, and then there are cache control request directives. I'm going to say that most of your cache control Stuff will happen from the server to the client. However, you can override those or or do it the other way from the client to the server. So Let's, let's go through

each of those now. You wanna grab the first one? Yeah. The well, I you know, to be honest, I I don't know that much about these. So Okay. I mean, I I know a little bit, but the first one is max age with which max age is basically a time to live. You like, how long is this thing going to live? Right? So the max age is the one that I use, primarily because, it's easy to use In in SvelteKit, you just say cache max age.

So max age is basically how long should this thing live before we we grab a new one. And so what do I have here? I have one that has a max age of 8, 86,400.

However long that 86,000.

Hold on. Let's do the math. So divided by 60, that is 1400 minutes, divided by 60 is 24 hours. There you go. So that is a one day Exactly. I came up with that for my Svelte calculator, so if you want.

It's nice that it's done in seconds and not milliseconds because then you don't have to do that extra 1,000 millisecond division.

Yeah, Essentially, how that works is that your browser will save all of your assets. Again, pictures of dogs, HTML images, you name it.

And before it tries to request it first, it will look at the header on that item and say, alright, well, I I The max age of this thing is one day, and I only got it 3 hours ago. So therefore, I'm not going to go back to the server and ask for another copy Of that, there also is no cache that will obviously not cache the thing at all or ever. That's very handy for things that are constantly changing.

There's this is a big the big one that everybody's all excited about, and it's stale while revalidate.

So what this will do?

Yeah. So what's this is the SWR. This is what, the whole idea behind the Next. Js Data fetching library, and this is a browser standard.

Actually, sorry. I have right underneath it nonstandard.

Apparently apparently, Really, it's not a standard, but everybody, every browser has implemented except you know who. Wow. Wow. Safari.

The zoo themed library.

So Stale while we're validate will, essentially what that means is serve the stale version from the cache, But in the background, go and fetch the new version. So you have a website, you visited it, and you have a list of dogs.

Serve up the old list of the dogs even if it is considered stale. So again, that whole Max age thing, It is considered fresh before it, stale after.

So do that. But in the background, go ahead and Fetch the new version. What I don't know, and maybe somebody on Twitter can answer this, tweet us has to text f m, is will the browser automatically swap out it. The asset for you on the page, or does it wait until the next refresh? Refresh.

By the I think it I think it's the latter. It's funny Because this is something that we all all kind of have to do by hand right now, which, I didn't know that this was a nonstandard standard here. So that's interesting. Yeah.

I just saw a tweet from Kent C. Dodds. They have remix Remix Conf going on right now, and he's blown his horn about how amazing the Remix website, Remix Conf website is, and he says it's just using browser standards.

And he there's a screenshot of the headers and what what is What is powering that? Stale while revalidate, meaning that, you can visit the website. You immediately get the stale version, And then you get the new version of the background, and that's actually how the syntax website works as well.

The syntax website will when you visit it, You will get the stale version, meaning that it has been generated when somebody else visited it. We put that in the cache, and then we will serve you that up. But what happens is in the background, we are generating a the next version of the syntax website. And the reason that we do that is because when there is a new a episode of Syntax. It would just automatically show up the next time somebody visits the website because it was regenerated.

So you're not you're not Visiting syntax. F m and waiting for the website to generate, you get the version from the last guy, and then the next guy gets your version. Right? It's kind of off by 1, But that is allows it to be both fresh as well

as pre generated if that makes sense. Yeah. It seems like the ideal way to do things and that's how we're doing a lot of caching these days of it, you know, whether that is like like we've cached images on, you know, Cloudinary or whatever where it's giving you the, you know, the the first person is doing all the work and then the next people are getting the cached version. So but this way, it does all the work in the background. So the even the 1st person is getting a previously cached version, And the next people are getting the the next cache version. So you're always getting what could be considered, like, a performant version of the load.

Go through them all because you can obviously read through the list. We're just going through the ones that are probably the most common, stale if error. So serve up the this one is not very well supported, but it's sort of the whole idea. This is why libraries like remix are becoming popular is that these headers Are going to take a lot of the load off and make it very easy to build performant websites without building something custom that's built into the browser. Use the platform. Right? So stale if error will just serve the stale version if, the asset cannot be downloaded or there's an error that is Downloading.

The must revalidate response directive indicates that the response can be stored in the caches and can be used while fresh.

If the response becomes stale, it must be validated with the origin before it, meaning that, you use that in conjunction with max age, There's other ones here private that will, say that this asset can only be cached on a private Cash, and that that to you is the browser. Your browser is a private cache, whereas, Cloudflare or cachefly or any of these CDNs that sit in between your server and the client, Those things will try to cache as much as they possibly can. And if you wanna explicitly say, no. No. No. No. This is private data or I never want this to be cached, in the CDN, you can pop a private directive on there, and it will make sure that it is not thrown in there. It's beautiful. You don't have to, like, figure out some custom API.

It's just standard immutable. This is kind of interesting. This one specifically for, assets. And I like to think of it as like CSS and JavaScript where if you have like style that CSS, You pop in a mutable tag on there, and what that will tell the browser is cache this thing essentially forever because if you want To load a new version of style dot CSS, you must change the name of the resource instead of changing the style dot CSS file.

And that's kind of cool because, like, that makes people use, like, style dot 1.1.2.

CSS or scripts dot 1.2.3 dot,

Jess, another way no. I think it's important to call out that, like, you typically, when you're working with many frameworks, if you low if you look at it. The source of your framework.

We we take a look at the source of our framework, and we see that any of the bundled JavaScript or CSS that's loaded into that that file can often have those those hashed files where the file has all that. It's not just index dot CSS. It's index, you know, 800 characters and then dot CSS. That is why. Right? Because it. If it is, you you want it to be just straight up cached by the browser and you want it to always have that 1. And if the file changes, then that hash that That unique identifier for that will change, and therefore, I will know to grab the next version of it. One kind of other one I saw here that was interesting is the no

form, cache control header. And what that does is it tells an intermediary CDN not to mess with the original files. So there are some CDNs, like, I think Cloudflare is a big one. I don't know if they Yeah, I just looked it up on their docs. They do have support for this. So Cloudflare will try to compress your images without actually changing them. And if you want them to not mess with that at all, Then you can put the no transform on there. I'm assuming this works for other things like Cloudinary or Opera Mobile, maybe. Opera Opera Mobile is a, like, a so that it can send it to you as fast as possible. It's a it's a proxy in the middle. And if you specifically need to tell the CDN in the middle To not to bypass that, you can pop a no transform header on that. And if they respect those headers, then they will not. They'll just pass the raw image or the raw asset through to you. Interesting.

Yeah. So those are all Response directives, they're coming from the server to the client.

And then there's the other way around. If you are on the client and you need to specifically ask The server for a version of something, you can pop a no cache header on there, headers as well. So, I could see that being handy if you had, like, a button that says, like, I don't know, Fetch dogs, but, like, fetch it from source. And you wanted to have a special button that goes past the cache.

That would be really handy. You'd pop that header on there, and that would be enough to tell your CDN or your server, pass any caches you possibly have, regardless of headers, and give me the raw stuff. Give me the good stuff.

That that's what I got there. So, thank you, Chris m, for writing in this part of question. I thought it was good enough to dedicate entire hasty towards. I think we'll see a lot more of this.

It's not really all that complicated once you realize that there's just maybe 3 or 4 a handfuls. Probably the stale while we're validate and the max age

are probably the 2 biggest ones that you'll you'll wanna start using. Yeah. And it. Like like we mentioned, I mean, caching can just be a a huge performance boost, and you might be spending a lot of time Elsewhere trying to get your your code to be faster to run more performantly for your users and at the end of the day if you're not implementing some of these basic caching mechanisms that are built into to the web platform overall, then, you might be missing out on a a huge opportunity to see some major Perf gains. You know what I always say?

Cash rules everything around me. Yes. I yeah.

Cash.

Yeah. We we used to joke about making T shirts that said that in, like, 2011 less. Yeah. Yeah. Because we're all Wu Tang Wu Tang heads. I I I'm actually I wonder what your your familiarity with Wu Tang even is. With mine? Yes. What's your what's your Wu Tang familiarity? I'm a I'm a little bit of a woo head.

Yeah. I wouldn't I wouldn't say a big fan, but I'll throw it on every time.

Yeah. Yeah.

Sometimes I, I like to throw it on. I'm not the type that would wear a Wu Tang shirt, but I definitely will laugh at a cream a t shirt or sticker that somebody has on their laptop. Although I just Googled it, and it seems like the geocaching community has sort of co opted that joke. Those geocachers, what do they think they're doing?

Hiding things in the forest and trying to find them? Come on. What a what a crazy hobby. Yep. I actually saw Wu Tang once in a concert, and it was awesome. I saw them in New York, and it was fantastic. And then we got to, Yeah. Be, at a b boy battle that was at the Wu Tang concert. So we we actually went for the b boy battle, and we got to, battle some guys from Poland, and they destroyed us. It was, it was, very unfortunate because they're, like, internationally, competitive. Like, these it. Dudes who are you know, they compete on on major major stages, and we we had to go against them in the 1st round, and we're just like, oh, man. We're gonna get worked, And we got we got we got destroyed. So, shot. And and also, like, I wanted to go up to them and be like, hey, I I'm of Polish heritage, but, they only Speak Polish, and I, I speak no Polish. So I couldn't even be like, listen, I'm I'm kind of Polish.

Let's be friends. And I couldn't even do that. It was embarrassing.

So here's a question. As a Michigander at heart, would you rather go see Wu Tang or ICP. Oh my god. Wu Tang. What

yeah. Yeah.

I have no no love a clown buzz. Once over. I'm not down with the clown, so to say. I, it's funny. I worked at an agency that got requested, a request for What do they call that? Like a request for the price? Whatever. Request for proposal. Request for proposal from ICP, and they, they actually wanted us to do their site.

I kid you not. They said, yes. We want this we want this agency to do their site. And you know what? We sat down as an agency, and, the the owner of the agency was basically like, at the end of the day, I don't really wanna do this work, and we just decline them as a client.

Oh, there's a really good documentary Online, if you just search, like, ICP documentary,

pretty pretty crazy. I was like the Workaholics episode where they go to the The clown festival or whatever it's called. Oh, good.

Oh, man. Alright. That's it for today. Thanks, everybody, for tuning in, and we will catch you on Wednesday.

Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.