Browser Cache

Overview

  • We can make good use http response header (Cache-control & Etag) to control the caching behaviors

  • If not http header is not be specified, the default behavior can depend on the specific browser or client making the request. In general, if there's no Cache-Control field in the response header, the client might use heuristic freshness to determine whether to serve the response from cache or make a new request to the server. Heuristic freshness typically uses factors like the Last-Modified date to estimate how fresh or stale the cached response might be.

Cache - Control

  • no-cache. This instructs the browser that it must revalidate with the server every time before using a cached version of the URL.

  • no-store. This instructs the browser and other intermediate caches (like CDNs) to never store any version of the file.

  • private. Browsers can cache the file but intermediate caches cannot.

  • public. The response can be stored by any cache.

Etag

  • Setting ETag or Last-Modified, you'll end up making the revalidation request much more efficient. They end up triggering the If-Modified-Sincearrow-up-right or If-None-Matcharrow-up-right request headers that were mentioned in Request headersarrow-up-right.

  • When a properly configured web server sees those incoming request headers, it can confirm whether the version of the resource that the browser already has in its HTTP Cache matches the latest version on the web server. If there's a match, then the server can respond with a 304 Not Modifiedarrow-up-right HTTP response, which is the equivalent of "Hey, keep using what you've already got!" There's very little data to transfer when sending this type of response, so it's usually much faster than having to actually send back a copy of the actual resource being requested.

References

Last updated

Was this helpful?