Adobe Tech Blog
Published in

Adobe Tech Blog

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.

--

--

--

News, updates, and thoughts related to Adobe, developers, and technology.

Recommended from Medium

My GSoC’21 Journey: Week 2

How to validate a PDF Document in C# .NET Framework

My first week as a Northcoders bootcamp-ee.

When Is It Time to Upgrade My Email Archiving Solution?

Convert a PDF to PDF/A in Python

AWS Lambda in Java and Terraform

Scanning the code of Orchard CMS for Bugs

Are you really sure you want Apache Kafka?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aaron Hardy

Aaron Hardy

I am a software engineer at Adobe working on the Adobe Experience Platform Web SDK. I am a fan of documentaries, podcasts, and bikes.

More from Medium

ABN AMRO introduces the IBAN-Name Check API powered by SurePay

Feature Toggles — Nature inspired design

How to Onboard 10+ new Business Analysts at the same time?

Powering Adobe MAX with App Builder and I/O Runtime

Chimera card collection built with Adobe App Builder surfaces personalized Adobe MAX content tiles based on user activities and recommendations, across relevant pages on Adobe.com