Browser Cache
Last updated
Was this helpful?
Last updated
Was this helpful?
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.
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.
Setting ETag or Last-Modified, you'll end up making the revalidation request much more efficient. They end up triggering the or request headers that were mentioned in .
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 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.
