When it comes to delivering the best user experience for your visitors on the web, one of the most important factors is the speed and responsiveness of your site. Caching is one way to help achieve this.

Why do we need web caching, what's the motivation?

Imagine this scenario, you live on the East Coast of the USA (Boston, Massachusetts) and you want to visit my website hosted on the West Coast of the USA (say Stanford, California). How long would it take to get a message to Stanford and back (the round-trip time)?

The speed of light gives us a theoretical limit on the answer to this question. [1]

  • The distance from Boston to Stanford is 4320km.
  • The speed of light in a vacuum is 300 x 106 m/s.
  • The speed of light in fibre is about 66% of the speed of light in a vacuum.
  • The speed of light in fibre is 300 x 106 m/s * 0.66 = 200 x 106 m/s.
  • This means the one-way delay to Stanford is 4320km / 200 x 106 m/s = 21.6 ms.

So the theoretical limit to get a message from Boston to Stanford and back is 21.6 ms * 2 = 43.2 ms.

In reality, it can take much longer!

With that scenario in mind, lets look at some web caching.

A basic understanding of how browsers communicate with web servers and the HTTP protocol may help in understanding the rest of this post. You can find some good answers from this Stack Overflow question, How does the communication between a browser and a web server take place?

Case 1: 200 OK (no caching)

In this case, the browser does not use its cache, or the resource isn't in the cache, so makes a request to the web server. The web server processes the request and sends a response back to the browser.

Browser: Send me the latest version of Derek's web page.

Server: Sure let me get that for you...

Server: Here is the web page. By the way, it expires in 24 hours so try not to bother me until then.

No caching / force reload

Above is a screenshot showing the HTTP request and response headers for an example request. The browser specifies the basic request headers and waits for a response from the server.

The server acknowledges this, processes the request and responds with a 200 OK. The response also includes a timestamp for when the resource expires. This is in the Expires and Cache-Control headers (86400 seconds = 24 hours).

Case 2: 304 Not Modified

In this case, the browser has a copy of the resource but requests an updated version from the server.

Browser: I have a copy of Derek's web page but I want to check with you if it has been modified since the last time I asked.

Server: Here is the web page. It hasn't changed. By the way, it expires in 24 hours so try not to bother me until then.

Server cache

In the request, the browser specifies the If-Modified-Since and If-None-Match headers. When the server gets these headers, it can determine if the browser has an out of date version of the resource or if the resource on the server has been modified.

In this case, the resource hasn't been modified so the server responds with 304 Not Modified.

Case 3: 200 OK (cached)

In this case, the browser doesn't communicate with the server at all.

Browser: Hmm this Server doesn't like being bothered, oh and it takes a long time to reply to me since it's so far away. I have a copy of Derek's web page right here and it hasn't expired yet. I'll show this to the user.

Browser cache

Although the screenshot above shows request and response headers, the browser does not communicate with the server to load the resource. The browser looks in its cache and loads the resource since it hasn't expired yet.

Timing comparison

The first screenshot below shows the server response time for cases 1 and 2. In these cases, the browser makes a request to the server and has to wait for a response. There is no significant timing difference between case 1 and 2 in my example because it was only a small HTML file that was requested. The time taken for the server to serve the HTML file is negligible in comparison to the round-trip time between browser and server.

Timing example for server response
Timing example for browser cache

However, there is a clear difference with the third case where the browser uses its cache. No request to the server needs to be made so the file is available to the browser almost instantly.

Conclusion

We've demonstrated that it's beneficial to utilise the cache headers available in the HTTP protocol. The aim should be to utilise the browser cache as much as possible and reduce the number of requests that have to be made to the server.


  1. It's the Latency, Stupid http://rescomp.stanford.edu/~cheshire/rants/Latency.html ↩︎