Splitting React Core Libraries and Applying Akamai CDN Caching

To optimize performance in a React project, I split the React core libraries into a separate bundle called react-vendor.

Why split out the React core libraries?

I moved the React core family of libraries into a separate react-vendor chunk.

1
2
3
4
5
6
7
8
9
10
11
12
13
14// vite.config.ts
build: {
  rollupOptions: {
    output: {
      // Split only the React core libraries into a separate vendor chunk
      manualChunks(id) {
        if (/node_modules\/(react|react-dom|scheduler|react-router|react-router-dom)\//.test(id))
	{
          return 'react-vendor';
        }
      },
    },
  },
},

I split out the React core libraries because they change less often than the application code.

Before this, the application code and the React core libraries were bundled together into a single JS file.

For example, suppose the output looks like this.

1index-ABC123.js

When part of the application code changes later, the whole bundle is rebuilt and the file hash changes too.

1index-GHI789.js

Even if nothing in the React core libraries actually changed, they are bundled into that one file, so the React libraries have to be downloaded again as part of the new file.

If the React core libraries are split into their own file instead, the structure looks like this.

1
2index-ABC123.js
react-vendor-XYZ789.js

Then, even when the application code changes and a new build is produced, the react-vendor hash stays the same as long as the React core libraries have not changed.

1
2index-GHI789.js          ← changed
react-vendor-XYZ789.js   ← same

In other words, even when the application code changes, the unchanged React core libraries can keep using the same URL.

When libraries that change infrequently are split into a separate file like this, you can expect a benefit once they are used together with a CDN cache.

For example, if react-vendor-XYZ789.js was cached on the CDN from the previous deployment and the next deployment only changes the application code, the existing CDN cache can be reused without fetching that file from the Origin again.

Bundle split results

In the actual build output, react-vendor was about 72.94KB and index was about 129.13KB, both gzipped.

So the initial JS transfer size of the two files was about 202.07KB gzipped, and react-vendor made up about 36% of it.

So the goal of this work was to split the React core libraries into a separate bundle and set things up so that these static resources could be cached on the Akamai CDN.

But Akamai caching was not being applied

After splitting out react-vendor, I checked the Akamai cache status of the static resources in production.

The React static resources were not being cached properly in the Akamai Edge Cache.

The Akamai debug headers showed that they were in a non-cacheable state, as below.

1X-Check-Cacheable: NO

To find out why static JS files were not being cached, I looked at the response headers coming from the Origin and at how static resource requests were handled.

I found two things that were getting in the way of caching.

Why caching was not applied

1. The Vary header

First, the responses for the React static resources included the following Vary header.

1Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers

While tracking down the cause, I found that CORS-related logic was running as part of Spring MVC's static resource handling.

Because static resource requests were also subject to CORS processing, the Vary header was being added to responses whether or not the request was actually a CORS request.

But the content of these static resources did not change depending on the request Origin.

In other words, a Vary header that caching did not actually need was being added, and because of it, Akamai was not caching the resources.

Akamai's official documentation also says the Vary header can affect caching and explains how to remove it when needed.

2. Set-Cookie

The other problem was that the static resource responses included Set-Cookie.

Shared cookie-handling logic also ran when the React static resources were requested, so a Set-Cookie like the one below was being added to the response.

1Set-Cookie: INFO=...

It turned out this cookie was not needed to serve static JS/CSS resources.

So I made sure the cookie is not created for static resource requests.

Vary and Set-Cookie were not problems with the React static resources themselves. The problem was that the Origin was adding unnecessary response headers to static resource responses, which got in the way of CDN caching.

The fix

After finding why caching was not applied, I fixed each problem and then applied a caching policy for static resources in Akamai.

1. Removing the Vary header

For the Vary header, I could have changed the application's shared logic directly, but changing shared logic could affect other requests.

To keep the impact on the existing application's behavior to a minimum, I handled it by removing the Vary header in Akamai, only for the React static resources.

2. Handling Set-Cookie

For Set-Cookie, I changed the Origin to handle static resource requests separately so that the unnecessary cookie is not created.

This keeps the unnecessary Set-Cookie out of static JS/CSS responses.

3. Applying Akamai CDN caching

After fixing the Vary and Set-Cookie issues, I requested a caching policy in Akamai for the React static resource paths so the CDN cache would actually apply.

The caching policy was applied so that the React static resources served by each service could use the Akamai Edge Cache.

Results

After the caching policy was applied, I requested the same static resources repeatedly to check whether the Akamai Edge Cache was working.

I confirmed that caching was now working properly, as shown below.

1
2cache-control: max-age=2592000
server-timing: Hit from child

Repeated requests also produced TCP_HIT at the Akamai Edge, which confirmed that the static resources were being served from the CDN Edge Cache rather than from the Origin.

This gave us a setup where, even when application code changes and the index bundle's hash changes, the unchanged react-vendor can reuse the existing CDN cache.

Takeaways

At first I set out to confirm the CDN caching benefit, which was one of the reasons for splitting out react-vendor, but in production the cache was not being applied properly.

While looking for the cause, I learned that Vary and Set-Cookie can affect CDN caching, and analyzing and fixing the cause myself gave me a deeper understanding of CDNs and caching.

In the end, I was able to get the CDN caching I first aimed for working properly. I think this work was a chance not only to optimize performance but also to learn new skills and grow a step further.