Last time, I learned how to implement caching for WordPress Blogs with plugins. This time, we’re going to learn how to control caching for everything on our site to help speed it up in most instances.
To find out about our speed, we started out from scratch with no changes and used Mozilla Firefox, Firebug, YSlow and Google’s Page Speed to get a benchmark of where we were, and each time we made a change we cleared the cache and checked how much improvement we get out of each change we make. We were able to take our score from a middle C (76) to a high B (87), and there are still some things we can do.
We’d like to point out that regardless of your browser of choice, keeping Firefox around only for these tools is well worth the space it takes up sitting there.
Tenni Theurer wrote an excellent post on these issues on the Yahoo blog:
When the browser saves a component in its cache, it also saves the Expires and Last Modified values. Specifying an Expires date in the past forces the browser to request the image every time the page is viewed (with a few exceptions, such as when users click the browser’s “back” button to return to a page). If the image is already in the browser’s cache and is being re-requested, the browser will pass the Last-Modified date in the request header. This is called a conditional GET request and if the image has not been modified, the server will return a
304 Not Modifiedresponse.
Remember years ago when everyone wanted:
<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">
in their pages so their users always got the latest pages and your goal was to force your visitors to re-download everything?
Yeah, stop that. 🙂
Rather than trying to control caching with your code (which isn’t very flexible and in Internet Explorer’s case, useless), you can control your site’s caching with the web server itself through directives in .htaccess. Here’s an example using mod_expires:
<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 1 month" ExpiresByType text/css "access plus 1 week" </IfModule>
What it’s saying is fairly obvious, and its directing the browser how long it should assume that certain components by type won’t change, with a default of when you hit it plus a month in the future. Because I tend to tweak the CSS file a little here and there and because a tweaked CSS file can break a design, I dropped that one to a fairly short refresh time, but for everything else one month is fine.
You can read more about mod_expires on the Apache site, and there’s a great page on the AskApache site that includes some cheat sheets for deciding on time as well as examples of how to define different expire times for different things.