How does the Production Build of React app use Caching to improve Runtime Performance?

Hello Everyone!! So today we are going to know about caching and how does it help in serving a set of files known as the production build of your react app, which is more efficient than your normal react app, runs fast and has better performance.

Getting Started!! Firstly let us suppose that you have already created a basic react app. To create its build version, run the following command -

npm run build

This might take some time, depending on the size of your project. Once it’s done, you will see a newly created folder, named “build”.

Now inside this folder, you’ll find a folder named “static”. And inside the static folder, you’ll find three folders, “css”, “js” and “media” respectively.

Now let us go inside the js folder.

You will basically find these types of js files.

This file represents the application code of your react app, which includes your pages, components, App.js, etc.

This file includes the vendor code, which has a low probability of getting changed, such as the node modules, etc.

How does Caching work?

Amazon Web Services defines Caching as follows -

In computing, a cache is a high-speed data storage layer which stores a subset of data, typically transient in nature, so that future requests for that data are served up faster than is possible by accessing the data’s primary storage location. Caching allows you to efficiently reuse previously retrieved or computed data.

So basically, Caching is nothing but storing files that do not change frequently, into local storage so that when required we do need to request them from the server and can be served them from local storage itself.

Our React project includes node_modules and static css, which tend to remain static and does not change frequently.

How to know if the files stored in the Cache memory have been changed?

Every js file in the build/static folder is named such that it includes a HASH code, the value of which depends on the contents of the file.

If the contents of any file in the project get changed then the HASH code for the file will get changed. And hence, the cache will get informed about the file changes.

Cache-Control Header

We can assign a time period for which the files in the cache will be stored safely and the cache will get updated once the time period ends.

We can even set the cache-control header to 1 year for static(assets) files because if we change the content of the asset files, the respective hash in the build files will get changed, which will cause the cache memory to download a fresh copy of the asset files.

For other files, we can set the cache-control header to no-cache, which will cause the client to always download a fresh copy of the respective file, such as the index.html, etc.

How is the build version different from other normal systems?

While we saw how cache improves the file serving process when the project is run.

In other systems, where we do not use a HASH and the cache header is set to 24 hours. Now, what if the developer suddenly updates the assets and deployed them.

Because the cache-control header is set to 24 hours, the cache files won’t get updated before this time period ends. Therefore, users won’t be able to view the fresh website.

Secondly, if some users delete their browser cache or do a hard refresh of the website, it will cause the browser to download the all-new set of files and hence the user would be visiting the fresh website. But those users who still have the same cache files would be visiting the same old website.

Hence, different users would be visiting different versions of the website.

Originally published at http://asquero.com.