 One of the common issues we see when looking at people's sites is that they don't cache resources as well as they could. For example, they set a resource that are unlikely to change to expire after a few minutes and sometimes regularly changing files are set to cache for several weeks. And then you get into cache busting and fighting with the browser's cache. What you probably want to do instead is to categorize your resources in one of two ways. Things need to be validated with a server and things that don't and can come straight from the HTTP cache. Something that does normally need to be revalidated is HTML, since that's the primary resource and the source of truth for your app. Here, you want a cache like this, private, no cache. That tells the browser that the resource is intended for just that user and that it should check with a server before serving it. Things that don't need to be validated would be things like JavaScript, CSS, or images. Here, you'll want to tell the browser that it should cache the resource for like a year. But what do you do if you need to change that resource? You include a hash or a revision name in the resources path. There are plenty of build tools that can help you achieve just that. Bear in mind that you shouldn't be caching your HTML, which means that when you change the far future cache resource, you can update the reference to it in the HTML and everything should just work out. If you want to see what your caching headers are, head to DevTools, Network Panel, click on a resource, and choose the headers tab. For more on this topic, you can watch the Supercharged livestream I did on server-side rendering over there or read Jake's blog post, which we link to in the description. But more importantly, you actually know.