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.
Here, we’ll explain how to cache your assets in the browser by using HTTP headers and caching software.
Resurrecting the fast food metaphor I used in a previous blog post, let’s make a trip back to that fast food restaurant and make the following analogy:
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.
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.