Cache Busting for an Angular App Deployed With AWS S3 and CloudFront

Caching is a very good way to load our web pages faster on users’ browsers, But that same cache becomes a problem when you have made a new release of your web application and this new release contains few very important bugs fixes or import feature. In that case, You expect your users to start using a new version of your application and you will have to handle cache-busting during such release.

In this post, I am going to share a checklist of things that you should do to bust the cache for an angular app deployed with AWS S3 and Cloudfront.

In this blog, I am assuming that you already know how to deploy an angular app on AWS S3 and Cloudfront. Also, you are using angular-cli.

Frontend app deployment with CloudFront and s3

Generate production build

To deploy any Angular / Reactjs or Vuejs application, we need to generate a build. If you are using angular-CLI, then make sure that you are generating a production build.

ng build --prod

This will set a number of flags, including — output-hashing=all which is required to generate build files with unique hashes. Your build output would look like this.

chunk {0} runtime.a5b5fc6b303bf4f57659.js (runtime) 2.48 kB [entry] [rendered]
chunk {1} 1.3eaffe77af2f5cf5cc60.js () 34.8 kB [rendered]
chunk {2} 2.54d0561213a13f87c70f.js () 46.7 kB [rendered]
chunk {3} main.4cd54d2a590c84799c74.js (main) 1.65 MB [initial] [rendered]
chunk {4} polyfills.cc0f1f379c61ac8668fe.js (polyfills) 45.5 kB [initial] [rendered]
chunk {5} polyfills-es5.fff1babb6b2975155bf2.js (polyfills-es5) 125 kB [initial] [rendered]
chunk {6} styles.cf3925058aa87715475d.css (styles) 9.13 kB [initial] [rendered]
chunk {7} 7.e18d700696420270428d.js () 1.43 kB [rendered]
chunk {8} 8.3ab11e7762b9eb57c76d.js () 70.3 kB [rendered]
chunk {9} 9.8cee7738482c27030a64.js () 9.49 kB [rendered]
chunk {10} 10.556452c0206871534497.js () 1.49 kB [rendered]
chunk {11} 11.a8474834281dac537636.js () 1.98 kB [rendered]
chunk {12} 12.b6b6e88016581aed72cb.js () 68.4 kB [rendered]
chunk {13} 13.e3cd5edabd462e8a6eee.js () 41.8 kB [rendered]
chunk {14} 14.7648624922bf971c0c67.js () 2.17 kB [rendered]
chunk {15} 15.8583c1e99a953a50803c.js () 1.42 kB [rendered]

Now, Notice that in our dist folder all files are having unique hashes in their names, except one file, index.html

Now, to deploy this build, we usually upload the dist folder on the s3 bucket and then we create distribution on CloudFront and set origin pointing to our s3 bucket.

Whenever someone visits your website, a request goes to CDN and since we had deployed a new build with a new file name, it would be cache miss for those files on CDN and they will be retrieved from origin s3 bucket. But, It would be a cache hit on the CDN side for index.html. So that won’t be retrieved from your origin s3 bucket. So your users would not able to see the latest updated version of your app.

Create Behavior in your CloudFront distribution

We need to create behavior to tell CloudFront that it should never cache index.html.

Set Minimum TTL, Maximum TTL and Default TTL equals 0. Check the screenshot of the configuration below.

So, This way we have handled cache busting on CloudFront side. But still, we need to bust cache on the user’s browser.

Update Index.html

Add Meta tag with cache-control information in the index.html

<meta http-equiv=”Cache-Control” content=”no-cache, no-store, must-revalidate” />
<meta http-equiv=”Pragma” content=”no-cache” />
<meta http-equiv=”Expires” content=”0" />

This will make sure that index.html is never cached in the user’s browser. So now whenever we make a release, users will get the latest version only.

That’s it. Thank you for reading.