Text compression with GZIP

• GZIP performs best on text-based assets: CSS, Javascript, HTML
• All modern browsers support GZIP compresion and will automatically request it
• Your server needs to be configured to enable GZIP compression
• Some CDNs require special care to ensure that GZIP is enabled

There are cases where GZIP can increase the size of the asset. Typically, this happens when the asset is very small and the overhead of the GZIP dictionary is higher than the comression saving.

Validating cached responses with ETags

First, the browser checks the local cache and finds the previous response, unfortunately it cannot use it as the response has now "expired".

At this point it could simply dispatch a new request and fetch the new full response, but that's inefficient because if the resource has not changed then there is no reason to download the exact same bytes that are already in cache.

That's the problem that validation tokens, as specified in the ETag header, are designed to solve: the server generates and returns an arbitrary token which is typically a hash or some other fingerprint of the contents of the file. If the fingerprint is still the same then the resource has not changed and we can skip the download.

The client automatically provides the ETag token within the "If-None-Match" HTTP request header, the server checks the token against the current resource, and if it has not changed returns a "304 Not Modified" response which tells the browser that the response it has in cache has not changed and can be renewed for another 120 seconds.

Cache-Control

The best request is a request that does not need to communication with the server: a local copy of the response allows us to eliminate all network latency and avoid data charges for the data transfer.

"no-cache" and "no-store"

"no-cache": If a proper validation token (ETag) is present, no-cache will incur a roundtrip to validate the cached response, but can eliminate the download if the resource has not changed.

"no-store": It disallows the browser and all intermediate caches to store any version of the returned response. Everytime the user requests this asset, a request is sent to the server and a full response is downloaded each and every time.

"private" vs. "public"

"public": it can be cached, even if it has HTTP authentication associated with it, and even when the response status code isn't normally cacheable.

"private": can be cached by user's browser, but not by a CDN

"max-age"

specifies the maximum time in seconds that the fetched response is allowed to be reused for from the tiem of the request

max-age=60 // response can be cached and reused for the next 60 seconds

Invalidating and updating cached response

All HTTP requests made by the browser are first routed to the browser cache to check if there is a valid cached response that can be used to fulfill the request. If there is a match, the response is read from the cache and we eliminate both the network latency and the data costs incurred by the transfer.

We can change the URL of the resource and force the user to download the new response whenever its content changes.