Increase App performance with HTTP Cache Headers

Before we begin, What is HTTP caching??

HTTP caching occurs when the browser stores local copies of web resources for faster retrieval the next time the resource is required. As your application serves resources it can attach cache headers to the response specifying the desired cache behavior.

Source: https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers#http-cache-headers

When an item is fully cached, the browser may choose to not contact the server at all and simply use its own cached copy i.e. instead of going through make request-> fetch result from server -> and then wrapping the response to a user-readable form, it directly sends the previously stored result (memoization) to the user upon request if it exists. Just like a {key, value} dictionary (hash-map ) structure.

To talk about an example, consider your application’s CSS file. Once downloaded from the server it doesn’t make much sense to fetch it again as it’s not very frequently changed. Other examples might include assets like icons, and images. In a situation like this, it seems intuitively better if we could cache such resources and then serve them to the consumer

Sounds too simple ?Think how do we decide if a resource is frequently mutating ? Where and In what format should we store them as to get better reads and writes? What are the limits of such storage, you don’t want your user’s screen to freeze while they are using your app for no reason ?Doesn’t seem that easy now :`) don’t worry together we will try to come to a trade-off here that will be reasonably good for both of us, although you can always comment below for a more optimised approach :P .

Type of HTTP cache headers

There are two primary cache headers, Cache-Control and Expires.

Cache-Control: Required for other cache headers to yield any results, effectively this is the header that ‘turns on’ caching in the browser. It is a composite value and accepts attributes like public (resources cached can be modified by both end-users browsers as well as any intermediate proxies), and private(resources cached can be modified only by end-client). It also stores a value max-age that provides the maximum amount of time (in seconds) after which the resource is assumed stale.

note : 1 : While the Cache-Control header turns on client-side caching and sets the max-age of a resource the Expires header is used to specify a specific point in time the resource is no longer valid

note : 2 : If both the *max-age and `Expires`* headers are set max-age takes precedence

Example request with cache turned on : http://<app-url>/?cache=true,

So till now, our header looked something like this

Cache-Control:public
Expires: Mon, 25 Jun 2012 21:31:12 GMT

Great! now we know when to fetch a resource again, but still, we haven’t answered how to do so.

1. Conditional requests

Conditional requests are those where the browser can ask the server if it has an updated copy of the resource. The browser will send some information about the cached resource it holds and the server will determine whether updated content should be returned or the browser’s copy is the most recent. In the case of the latter, an HTTP status of 304 (not modified) is returned.

But mind that even a 304 response would mean that you have performed a network call but since it would have an empty response so a lot faster.

2. Time-Based requests

We can also agree that a request to be processed is a re-fetch request from client only when the requested resource (if existing) is modified. We can reduce a lot of time if we knew whether the requested resource has changed since the browser’s copy was cached and the contents be transferred. If the cached copy is the most up-to-date then the server returns the 304 response code.

3. Content-based requests

What if there are multiple nested entries and so it will be difficult to determine the last modified value for the header? For cases like these, we have the ETag. ETag (or Entity Tag) works in a similar way to the Last-Modified header except its value is a digest of the contents of the resources (for instance, an MD5 hash). This allows the server to identify if the cached contents of the resource are different from the most recent version.

On subsequent browser requests the If-None-Match request header is sent with the ETag value of the last requested version of the resource.

As with the If-Modified-Since header, if the current version has the same ETag value, indicating its value is the same as the browser’s cached copy, then an HTTP status of 304 is returned.

Example request with ETag : http://<app-url>/?etag=true,

Cache prevention

Highly secure or variable resources often require no caching. For instance, anything involving a shopping cart checkout process. Unfortunately, merely omitting cache headers will not work as many modern web browsers cache items based on their own internal algorithms. In such cases, it is necessary to tell the browser explicitly to not cache items.

In addition to public and private the Cache-Control header can specify no-cache and no-store which informs the browser to not cache the resources under any circumstances.

Both values are required as IE uses no-cache, and Firefox uses no-store.

Cache-Control:no-cache, no-store

Sources:

[embed]Increasing Application Performance with HTTP Cache Headers The modern day developer has a wide variety of techniques and technologies available to improve application performance…devcenter.heroku.com

[embed]Going to Production | Next.js Before taking your Next.js application to production, here are some recommendations to ensure the best user experience.nextjs.org