In this post, we explain how to cache website assets using HTTP headers and caching software. Read on to learn how caching can speed up your website.

Lots of things happen on the back end of a website that many non-technical website managers and business owners don’t realize contribute to slow page load times and bad user experience. One of the biggest culprits when it comes to slow page load times is caching.

Without caching enabled, a visitor’s browser has to make lots of individual requests for assets like images, CSS and JavaScript files. Not only does this slow down your website, it sucks up energy and increases your site’s carbon footprint.

Caching Explained

Resurrecting the fast food metaphor we used in a previous blog post, let’s make a trip back to that fast food restaurant and make the following analogy:

You: you
Web browser: cashier
Web server: Fryer, food chute, drink station

Every time you order food, the cashier has to make a round-trip walk from where you’re standing to the food chute to retrieve your items. It’s the same when you request a website. Whenever you request a website, the browser has to make a round trip from where you are to the web server and back.

Fortunately, at a fast food restaurant, the cashier can make one trip to the food chute, fryer and drink station to retrieve the three or four items you’ve ordered. Unfortunately, your browser can’t carry more than one item at a time. Each time a browser makes a request for a web page, each image, each Javascript and CSS file, and the HTML document itself represents one round trip your browser makes between you and the web server. That’s a lot of trips, and it can significantly slow down your website, which is bad news. Even very slight speed decreases can have a dramatic impact on retention, conversion and revenue. For instance, Yahoo! found a mere 400 millisecond of additional delay resulted in a 9% drop in traffic.

The front page of Mightybytes.com loads 35 different assets, each requiring a round trip. Imagine getting stuck behind a guy at a fast food restaurant who ordered 35 cheeseburgers and the cashier had to walk from the register to the food chute and back for each burger. You’d be livid, and so would the rest of the customers.

Fortunately, there are methods you can use to speed up that round trip so your website not only loads faster, but uses less energy.

Here are two methods to eliminate or speed up the round trip your browser makes.

Magically produce food at the counter: Force browser to cache assets

If there was a way the cashier could keep a bunch of all the different kind of foods they sell right there at the counter, they wouldn’t need to take a walk to build your order. Your browser, however, can keep a cache of documents locally so that the next time it requests that image, script, CSS file or HTML document, it’s served to you lightning-fast because it’s being read from your browser’s cache and not from a delay-inducing call to the web server.

How it’s done:

Note: Mightybytes uses Apache as our web server of choice. The instructions for configuring headers will be Apache-specific, but the headers and values themselves are part of the HTTP specification and will operate the same when served using any web server.

It all comes down to the values for a few HTTP response headers, which are pieces of metadata that accompany the response the web server returns to your browser. Those headers are, in general order of precedence:

• Cache-control: A specific duration, specified in seconds, that you want this asset to expire.
• Expires: A specific date that you want this content to expire.
• ETag: A string that the web server changes whenever an asset is modified. Your browser sends this back to the web server after the first time the asset is loaded. If it changes, the web server resends the asset.
• Last-Modified: A specific date that this content was last modified.

The Cache-control and Expires headers are considered strong caching headers because they define a specific date or duration to cache this asset. Last-modified and ETag headers are considered weak caching headers because they rely on having previously loaded the asset to determine whether or not to cache the asset.

Using mod_headers in your Apache configuration file or .htaccess file, you can specify certain assets be cached for a given duration using the Cache-dontrol or Expires header.

Cache images for one week:

<FilesMatch "\.(jpg|jpeg|png|gif)$">
  Header set Cache-Control "max-age=604800, public"
</FilesMatch>

Cache CSS and JS files for one week:

<FilesMatch "\.(jpg|jpeg|png|gif|swf)$">
  Header set Cache-Control "max-age=604800, public"
</FilesMatch>

Expire a page at a given date and time:

<FilesMatch "fluxcapacitor.html$">
  Header set Expires "Fri, 26 Oct 1985 01:22:00 GMT"
</FilesMatch>

Last-Modified header can similarly be set by the above methods.

<FilesMatch "fluxcapacitor.html$">
  Header set Last-Modified "Tue, 27 Jun 2012 01:21 GMT"
</FilesMatch>

The ETag header can be set using the FileETag directive.  The Apache documentation has a more indepth description of what attributes can be  taken into consideration when generating the ETag value.

FileETag INode MTime Size

The W3C specification for caching in HTTP gives the complete picture of how these headers direct the browser to cache or retrieve assets.

Launch food from food chute toward the counter: Use software caching

We know that the delay in serving food is due to the cashier walking from the counter to the food and back. Rather than send the cashier to the food, what if we hired a MLB pitcher to launch that food at the cashier? This is the idea behind software like Varnish.

When you request an image or a script, the web server normally goes to the hard drive, reads that image or script and sends it back to the browser. With Varnish installed and configured, the first time that asset is requested, a copy is stored in memory. Upon subsequent requests, the version of that asset stored in memory is returned. Since reading from memory is faster than reading from the hard drive, that read time is virtually eliminated, thus speeding up the round trip.

Squid can perforrm the same kind of caching as Varnish and can also provide CDN-like functionality by becoming a proxy cache. Imagine, if the restaurant’s salary cap won’t let us hire an MLB pitcher or the player’s union won’t let the pitcher throw cheeseburgers, we can move the food chute closer to the cashier to reduce the time it takes to walk there and back.

Both Varnish and Squid require more advanced knowledge of managing web servers and other server-based software to operate effectively.