An HTTP Caching Strategy for Static Assets: Testing the Implementation

This post is the fourth in a four-part series:

1. An HTTP Caching Strategy for Static Assets: The Problem
2. An HTTP Caching Strategy for Static Assets: Generating Static Assets
3. An HTTP Caching Strategy for Static Assets: Configuring the Server
4. An HTTP Caching Strategy for Static Assets: Testing the Implementation

For this, we’ll use the Chrome browser. First, we’ll clear our browser cache. Next, we’ll open the Chrome developer tools and show the Network tab. Then, we’ll load up our site. In our case, that’s https://launch.adobe.com. Once we get past the Launch login screen, we should see something similar to this:

Requests with empty cache

The returned status code is 200 for all the files shown. As expected, we received the full contents of all the files and nothing was pulled from the browser cache (it was empty). Note that thelaunch.adobe.com entry is the request for our index.html file.

The satelliteLib-2ca5ab87343f3c882e4ab68f2f6a886eaea6e40b.js file was served from Akamai and doesn’t run through this particular HTTP server we’re configuring, so we’ll ignore that file in this analysis. For you astute readers, you may recognize this filename as a DTM library. Why are we using DTM on Launch? Why are we not use Launch on Launch? 😱 At the time this screenshot was taken, we were using the DTM library as part of testing our recently released feature: DTM-to-Launch embed code migration!

If you click through the different files, you’ll see that our index.html was returned with a Cache-Control header with a value of no-cache. It was also returned with an ETag header:

All the content-addressed files, on the other hand, were served with a Cache-Control header with a value of public,max-age=31536000,immutable and do not contain an (unnecessary)ETag header.

Now, type https://launch.adobe.com in the location bar and hit enter again. We should see something like this:

Requests with primed cache

This one is more interesting. This time, our index.html file was returned with a 304 status code. If you click on the entry, you’ll see that the request from the browser to the server included this header:

This is the browser telling the server that the browser already holds index.html in its cache and the file’s ETag is 5a9ec1e2-a03. The server compares the ETag the browser sent with the ETag of the index.html held on the server. In this case, they match; the file hasn’t been changed since our first request. The server responds with a 304 status code, telling the browser that it is okay to use the file it already holds in its cache. Notice in the screenshot that the size of the response is 198 bytes, which is much smaller than the response from the first request, which was 1.3 kilobytes. This is because the second response did not include the file contents. This is a good thing.

For our content-addressed files, you’ll notice the 200 status code is gray and it says the files were retrieved from either memory cache or disk cache. This means the browser did not actually send any request to the server for these files; they were pulled straight from cache. This is also good.

The next time we deploy changed files, we should load our site again without first clearing our cache and verify that the browser appropriately delivers the latest files.

Caching: One piece of performance

Our caching strategy for static assets has served us quite well, but it’s only one piece of the performance puzzle. We also need to consider caching for API requests. File size, number of requests, server response times, and how we load files are also big factors in responsiveness of our user experience. We need to take a close look at each piece of the puzzle and start addressing the biggest opportunities for optimization.

This post is the fourth in a four-part series:

1. An HTTP Caching Strategy for Static Assets: The Problem
2. An HTTP Caching Strategy for Static Assets: Generating Static Assets
3. An HTTP Caching Strategy for Static Assets: Configuring the Server
4. An HTTP Caching Strategy for Static Assets: Testing the Implementation

Follow the Adobe Tech Blog for more developer stories and resources, and check out Adobe Developers on Twitter for the latest news and developer products.