Web app optimization technique — Fingerprint with Cache-control header
In this blog, I’m gonna talk about how to handle the browser cache efficiently to reduce the network to the server to fetch the static resources. This blog contains a high-level description of the Fingerprint method. I’ll write the practical production implementation as a separate blog.
Fingerprint and Cache-Control header
Have you ever think that what’ll happen If you load the same set of static files(js, CSS, and icons) every time when the user loads the web app? Every time, will a network call hit the server to fetch those static files? (or) Does the browser handle it smartly? (or) Can we(developers) do something to help the browser handle this situation? Let’s see more in detail below.
To visualize more, consider you have a web app and you’ve included the button.js file in the head tag, like below.
File name : index.html
<head> <script src=”button.js”></script></head>
Every time when the web app loads, the browser will make a network call to fetch the button.js file from the server. Consider, the button.js file contains event handlers for all the buttons in our web app.
Here, we know that the server will provide the same button.js file every time the browser request until the developer made any changes to the file.
What if there is a mechanism between the browser and the server in such a way that to avoid network calls to fetch button.js file on every page reload. In that mechanism, browser should able to identify whether the button.js file content changed in the server or now. If changed, the browser should request the server to fetch new content. If now, the browser should avoid fetching and use previous button.js file.
The above-mentioned mechanism is Fingerprint.
Fingerprint facilitates a workaround to let the browser know whether the static file(in our example, button.js) content is changed in the server or not. Based on this information, we inform the browser what to do, either fetch the static file from the server or use the existing one.
How do we let the browser know whether the static file content changed in the server or not?
In our example, we have included static file button.js in the script tag. Once the browser loads the index.html, the browser parses the HTML file to know what to load from the server.
In our example, the browser will try to load the button.js file once it parses the index.html file. From this, we know that the index.html file tells the browser what to load.
Two things we need to do to achieve the fingerprint mechanism.
The first one is the cache-control Header.
we need to set the cache-control header in the HTTP response header field to order the browser on how long to cache the resource in the browser.
When the browser receives an HTTP response, it will parse the response header, and using the cache-control header field(if any), the browser will decide how to cache the resource and how long to cache the resource.
Example, set the cache-control header for button.js file as below to let the browser cache the resource for 365 days.
“cache-control : max-age=31536000”
When the browser sees the above cache-control header in the button.js response, it will cache the button.js file for one year. All the network calls to fetch the button.js file in that one year will be served from the browser cache. The network calls won’t hit the server.
Now, we have optimized the way we fetch the button.js file from the server. Everything seems perfect. Nahhh!! We have a problem here.
If the developer changes the button.js file in the server, how does the browser fetch the updated button.js file? The browser will fetch the older version of the button.js file from the cache.
To solve this problem, we need second stuff. ie. File Hashing.
The browser will know what to fetch from the server by parsing the base file.
In the above example, we have included button.js file in the index.html. The browser parses the index.html file(base file), when it sees script tag with button.js file, it will check whether the button.js file exist in the cache or not.
If the file exist in the cache, it will check for the expiry time. If the expiry time is valid, the browser will fetch the file from the cache, otherwise, it will make a network to the server to fetch the file.
From this, we know that index.html(base file) is the deciding factor for the browser to know what to fetch. I call this deciding factor as the base file. because the deciding file can be a JS or CSS file.
If the developer updates the button.js file, rename the file and update the script tag, like below,
File name : index.html
…..
<script src=”button-1.js”></script>
…..
Since we have renamed the button.js file as the button-1.js file, when the browser parses the index.html(base file), it will check whether the button-1.js file exists in the cache or not. The cache contains the button.js file, not the button-1.js file. So, the cache check will return false and the browser will try to fetch the button-1.js file from the server and store it in the cache for future load.
In this way, we can make the browser fetch the content from the server if the content changed in the server (or) to fetch the content from the cache if the content has not changed in the server.
For every update, renaming the static file seems easy, but in production, it is very difficult to track and maintain the file name.
Instead of renaming with a dummy name, generate the hash value for the static file and append the hash value at the end of the file name. If we change/update the static file, a new hash value for that file will be generated, and that we append it at the end of the file name.
In our example,
Hash(button.js) = <hash_code>
Append that <hash_code> at the end of button.js, like,
File name : button_<hash_code>.js
In this way, we can use the browser cache effectively.
You might have the following questions,
1. what will happen to the previously cached files?
Those files reside in the browser until it expires.
2. Is there a fixed storage limit for the browser cache?
No. There is no fixed storage limit. The limit is based on disk space. Usually, the limit will be 1/3 of the system disk space. So you don’t need to worry about the limit.
Please do comment if you have any suggestions.
