-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP Caching - Fresh, Stale and Revalidation #2
Comments
HTTP caching is critical to the performance of a website. Resources can be reused for a set period of time, and then revalidated to keep their freshness. It can save the client the time waiting for responses and relieve the server's burden of handling requests. 🍎 Fresh and StaleLet's do this together:
This is where the magic happens! The value of age indicates how long the resource will remain fresh, i.e. reusable. During this period, the client no longer needs to query the server for this resource, but can instead reuse the cached version of it. Prior to HTTP/1.1, The benefit is self-evident: No request issued, no response awaited, and a foreseeable boost in performance. That's awesome, but it also comes at a price, since the server has completely lost control over the client, on that specific URL. This places a high demand on the setting of age. A long age makes it easier for the client to see an outdated version of resource, whereas a short age makes caching nearly useless. When the magic fades, the resource becomes stale. Oops! That's definitely not what we want, as we cannot enjoy the blazing fast local cache any more. One intuitive approach would be to fetch that resource again, right? And the magic can be replayed once again. This is adequate, but not optimal. Revalidation is a better way to replay that magic. 🛏️ RevalidationWe'll still have to try to fetch that resource eventually. But this time, we will include some credentials with the request that will inform the server about the current state of our local resource. After the server validates the credentials, it will inform us whether or not our resource has become obsolete. If not, the stale resource will be refreshed, and the client will be able to reuse it for another period of time. Now the magic is back, but the server no longer needs to send that resource! Next, we'll talk about the credentials. ⏱️ Revalidation Based on TimeOne of the credentials is the last modified time of the resource. The basic idea is straightforward: If a resource has not been touched since it was requested, then it's safe for the cache to be reused.
Isn't it easy? However, it has numerous drawbacks:
And another approach is ready to come out, once those drawbacks are identified. 🏷️ Revalidation Based on ContentThe server generates a unique tag based on the current content of the resource, such as a hash value or version number. After that, we can reuse the resource if the tag remains the same.
🤝 Combination of Last-Modified and ETagWhenever these two credentials appears together, Ideally, 🤔 Related Cache-Control Directives🚫 no-cacheForce the client to revalidate the resource every time. The resource will still get stored, but it turns stale immediately upon arrival. If you are wondering how is it different from
🚫 no-storeNot storing the resource at all. In most cases in practice,
👀 private/public
📚 References |
HTTP caching is critical to the performance of a website. Resources can be reused for a set period of time, and then revalidated to keep their freshness.
The text was updated successfully, but these errors were encountered: