Mastering Cache Control: Optimizing Performance for React Applications

Hi, everyone. Today we're going to talk about utilizing caching to optimize our web application performance. I'm Yael Bala. We're a digital health and FinTech startup. It's nice to be here at React Day Berlin.

Let's start. When we talk about caching in the context of React web applications, we usually discuss state management and how to avoid redundant network requests. However, here we're going to talk about what we can do to cache data and resources outside of our React application, how this caching behaves, and how we can control it and avoid caching problems.

But first, let's start with why we need caching. Even today with fast Wi-Fi, code splitting, SSR, it still takes time for a web application to load. And one of the ways to improve it is using cache. We can also use cache, by the way, to serve content offline or when the server is unavailable, and we can also reduce the load on the origin server, which can ultimately improve the performance of all of the users.

So what should we cache? So static resources are natural candidates for caching, images, media files, scripts, and CSS. But it's also important to note that we can also store application data, like the list of latest articles or posts, or default settings that can help us load faster. We don't want to store data that will not be correct when it's old, for example, showing a user balance. If we display an outdated value, the user will not be happy.

We also should be careful with caching secure content, because we don't want it to be displayed unless the user is authenticated. Where can we cache? What are our caching options? For that, let's look on the request journey. When we issue a request from a web application, I would expect it would go to the server and get the value back, right? We actually have several stops on the way that can help us cache the data. The first stop is the service worker. It can intercept all kinds of network requests and can load the response from its cache. The service worker, if it can't handle the request, the browser may then serve the content from its own cache. And if not, the request will continue to the next stop, the CDN. It is recommended to have CDN in place, and if the resource is cached there, it's great. And if not, it will go all the way to the server. And the server, when returning the content, also provide additional information about the caching. It does this using different headers that we will discuss later.

Let's look on our first stop, the service worker. The service worker is just a script, a JavaScript. It runs in the background outside of your application, and it can do many things, including intercepting network requests and deciding whether to return the content from the cache or not. Here is an example of a script that listened to a fetch request and returned data from cache. There are very common strategies that you can use inside a service worker. You don't need to reimplement them. You can import them from a library and NPM package and use them. They offer a variety of options. For example, network first is the basic. This strategy tries to fetch data from the network. And if the server does not return the content, it will take the latest value from the cache. Another useful one is tail while revalidate. This strategy serves the offline content from cache immediately, but it also issues a new request, and when the results return, it updates their content for the user. If the service worker can't return the data, the next stop is the browser cache. The browser HTTP cache is a built-in mechanism in the browser.

It stores resources that have caching headers or rules set by the server. And if you look in the network tab in the developer tools, you can see which resources are loaded from network and which are loaded from disk. For example, here you can see a library. And you can see also the time, it only took three milliseconds.

The browser cache and the service worker cache both aim to reduce network calls, but their purpose diverge. The browser cache is limited to HTTP caching, adhering to server-defined rules. While the service worker allows developers to create custom caching logic. It enables more complex scenarios like offline first strategies or any kind of dynamic caching.

Relying on the server HTTP caching means you're using the server to tell us how to cache a resource and for how long. Developers can influence this behavior by setting the appropriate header on the back-end side. There are two main headers that are in use, cache control and eTag. The cache control header specifies if and how long a resource can be cached. It can include values like max age, which indicates the number of seconds the cache can store the file before it expires. But we can also set values like no store or must revalidate to define stricter caching rules.

The eTag header helps control cache validation. The server returns an ID that represents the content version and the HTTP, next time when the browser cache will want to use this value, it will ask the server if the content is changed by sending the eTag value. And if the server responds with a 304 status, it means that the browser can use the cache value. This is a great option for large files that is hard to query or send over the network. If the browser cache can't return the value, the request goes to the CDN.

The CDN, it's a content delivery network, consists of proxy servers located globally. The goal of the CDN is to deliver content efficiently. These servers maintain cached resources, allowing users to receive content from the nearest server and reducing network delays. CDN proxy servers also use HTTP caching and respect the cache control and eTag headers. You can set different values for the CDN.

If the browser cache can't return the value, the request goes to the CDN. The CDN, it's a content delivery network, consists of proxy server, servers located globally. The goal of the CDN is to deliver content efficiently. These servers maintain cached resources, allowing users to receive content from the nearest server and reducing network delays. CDN proxy servers also use HTTP caching and respect this crash control and eTag headers. You can set different values for the CDN.

For example, you can use S max age for CDN specific caching duration. You can also specify if it's private content that can only be cached locally. CDN provides another important tool in validation. You can use this in order to issue requests to clear cached content from the CDN proxies, which propagate across the network. Unlike browser cache, when clearing requires user action, CDN validation can be done from a central location.

Well, we almost finished our 10 minutes. Let's see what we can store at each caching point. At the service worker, we can store prefetched API responses for offline use. For example, a list of tasks in a to-do app. For example, we can use default user properties. Just ensure sensitive data is encrypted or protected to mitigate security risk. In the browser cache, you can use it to cache images, fonts, scripts, and other static content. Ensure file name changes when the content changes to prevent stale cache issues. In the CDN, you can cache static resources for a much longer duration and also share data like main categories, main products, article, content, and so on.

To summarize, caching helps improve performance and enable offline functionality. Different caching mechanisms exist along the request journey, and we have tools to control the cache behavior. The key takeaway, take a look on the network tab, see what requests you have and what takes a lot of time, and check which cache you can use to improve performance. Thank you. I hope you find this session interesting. If you have questions or comments, feel free to contact me in LinkedIn or via the conference chat. Have a great day.