In a recent post, I presented a few easy steps that anyone can take to speedup their WordPress blog. My aim in that post was to introduce a basic methodology for measuring performance (YSlow), along with a fairly simple recipe for improving a web site’s YSlow score, and thereby its performance. Much to the horror of my sysadmin friends, I encouraged people to blindly follow the instructions as given — though in my defense I did also strongly encourage readers to peruse the related articles for more information!
In the comments, reader zuborg asks:
“Very funny to observe that wordpress blog posts recommend to remove ETags from http-headers. Did somebody investigate what is and for what purpose it was designed?”
This is a very good question, and one I would like to respond to in more detail here.
What Are ETags?
The Caching Tutorial for Web Authors and Webmasters article provides an excellent introduction to caching, including a good section on cache validation and ETags. I consider the article a must read for anyone interested in how Internet caching works. I’ll quote from that article here:
“HTTP 1.1 introduced a new kind of validator called the ETag. ETags are unique identifiers that are generated by the server and changed every time the representation does. Because the server controls how the ETag is generated, caches can be surer that if the ETag matches when they make a If-None-Match request, the representation really is the same.”
“Almost all caches use Last-Modified times in determining if an representation is fresh; ETag validation is also becoming prevalent.”
So ETags provide a unique identifier that can work in conjunction with, or in lieu of, the Last-Modified header to reduce the amount of data traffic associated with sending files from the server to the web browser. This certainly sounds like a useful feature to improve overall performance.
Rational for Removing ETags
In 2006, Yahoo! published some performance research in which they state “Our experience shows that reducing the number of HTTP requests has the biggest impact on reducing response time and is often the easiest performance improvement to make.” One outcome of that research was a set of recommendations for reducing the number of HTTP requests, and one of those recommendations was to configure your ETags or simply remove them entirely. If ETags help with caching, then why would Yahoo! suggest removing them?
Let’s see what Yahoo! has to say:
“The ETag format for Apache 1.3 and 2.x is inode-size-timestamp. Although a given file may reside in the same directory across multiple servers, and have the same file size, permissions, timestamp, etc., its inode is different from one server to the next.”
“The end result is ETags generated by Apache and IIS for the exact same component won’t match from one server to another. If the ETags don’t match, the user doesn’t receive the small, fast 304 response that ETags were designed for; …”
“Even if your components have a far future Expires header, a conditional GET request is still made whenever the user hits Reload or Refresh.”
So there you have it. Yahoo! recommends removing the ETags because conditional GET requests are made whenever the user hits Reload or Refresh — and we’re all about eliminating superfluous requests whenever possible.
What If I Want ETags Anyway?
There is some interesting discussion in the comments associated with the Yahoo! blog post about removing ETags, with many people extolling the virtues of ETags and suggesting ways to retain them. Some people have recommended removing the inode component of the ETag, resulting in an ETag that includes the file size and timestamp only. For Apache, you can use the FileETag directive as follows:
FileETag MTime Size
In the Yahoo! blog comments, Steve Souders (now with Google) makes the point that an ETag composed of the modification time (MTime) and size is providing essentially the same information as the Last-Modified header, and questions whether ETag validation is superior to Last-Modified validation in any case.
Ultimately, configuring or removing ETags is up to you. Since our strategy is to provide a far futures cache expiration date, I am perfectly comfortable removing the ETags. Doing so makes it easy to use the YSlow grade as a quick evaluation tool, but as @zuborg reminds us, actual performance is something you ought to evaluate for yourself.
We recently finished optimizing several WordPress blogs for improved performance and I thought “wouldn’t it be great to share our experiences with everyone?” After all, when I look around at all the blogs I know and use, I see that very few are taking advantage of even the simplest performance improvement techniques — surely it’s just a matter of getting the information out there for everyone to use?
A quick search for “wordpress speedup” or “wordpress optimization“, however, reveals that we aren’t suffering from a dearth of information. On the contrary, many, many people have posted articles about their specific techniques and experiences (I’ve listed the best of these in the Related Articles section; you really should read them). This leads me to believe that most bloggers are either apathetic about their site performance or intimidated by the prospect of diving into something they know little about. I tend to think it’s probably the latter, so let’s see if we can make it a little less scary, eh?
What You Should Do Right Now
Here’s the short answer: install a couple plugins, add a few lines to your .htaccess file, and reap the rewards. It is almost certainly guaranteed that you will see an immediate improvement in your site performance, shaving seconds off each page load and impressing your readers. If you truly want to know how and why all this stuff works, you’ll enjoy reading the related articles for more information and insight.
- 1. Use Firefox, Firebug, and YSlow to measure yourself
The Yahoo! team has published their 34 rules for speeding up your web site and a tool for evaluating web sites against those rules. Strictly speaking, you do not need to install these tools, but I think you will enjoy seeing your YSlow score move from where it is today (probably an “F”) to where it should be (at least a “B”). And joy of joys, your actual site performance will improve accordingly.
- 2. Enable GZIP compression
Add the following lines to your .htaccess file (the AddOutputFilterByType should all be on one line). This action tells the web server to compress files before sending them to the browser, resulting in reduced bandwidth and faster delivery to the browser. Adding compression is a very safe option.
- 3. Add an Expires Header
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
If mod_expires is not available on your system, you can try this instead:
Header set Expires "Sun, 22 Apr 2018 01:10:54 GMT"
Header set Cache-Control "max-age=315360000"
Header unset Pragma
- 4. Disable ETags
Add the following line to your .htaccess file. This action tells the web server to remove ETags from the HTTP response. For most websites, removing ETags will not affect your performance at all, but it will increase your YSlow score. Removing ETags is a very safe option.
- 5. Install the PHP Speedy WordPress Plugin
- 6. Install the WP Super Cache Plugin
The WP Super Cache Plugin helps performance by dramatically reducing the time it takes the server to deliver the initial HTML file for the page. There are other steps you can take to optimize your server-side performance, such as eliminating unnecessary plugins and optimizing your page templates, but while you’re thinking about all that, this one little action will make a world of difference. My one configuration note here is to go ahead and enable “Super Cache Compression.” This option is disabled by default, but I recommend that you enable it and just run a quick test to ensure the page is being delivered correctly.
You can verify that the cache is configured and working correctly by visiting the site as an anonymous user and viewing the page source. Compressed pages being served by the cache should by quite fast and the last three lines of the page file will look something like the following.
<!-- Dynamic Page Served (once) in 1.422 seconds -->
<!-- Cached page served by WP-Super-Cache -->
<!-- Compression = gzip -->
By using these techniques, and by adding a bit of image optimization and consolidation, we have seen dramatic performance improvements for the sites we’ve optimized. Typical page loading times have dropped from 5-10 seconds to one second (or less for pages cached by WP Super Cache).
Without sacrificing any page functionality or quality, we have been able to:
- reduce the empty cache total size by 50% or more
- reduce the empty cache HTTP requests by 50% or more
- reduce the primed cache total size by 90% (!)
- reduce the primed cache HTTP requests to as few as 1 or 2 requests (!)
Well this first part was certainly easy: edit one file (.htaccess) and install two WordPress plugins. These simple steps have probably provided some immediate relief for your readers, and that’s a good thing. From here, I would strongly suggest you review the related articles for other front-end improvements, such as optimizing images and using sprites to reduce the number CSS images on your site. There’s quite a bit more you can do without becoming a programmer or system administrator.
If you do have administrative access to your server, however, you can also begin experimenting with ideas to improve the back-end server performance. You might consider installing a PHP accelerator, such as eAccelerator, to speedup PHP script execution. Or you might want to expend some effort tuning MySQL for your site. For most people, however, these advanced topics are beyond their skill and training, or are simply unavailable in their current hosting environment.
If you decide try any of the techniques in this article, I’d like to hear about your experience, and about what you think you’ll try next.
- 38 Ways To Optimize And Speed Up Your WordPress Blog , April, 2008
- 20 Tips and Tricks To Speed-Up Your WordPress Blog, August, 2008
- Tips To Get A Good YSlow Rating, May, 2008
- How-To: Optimize Your Site For Speed, April, 2008
- WordPress Optimization Guide, November, 2008
- Quick Tips For WordPress Speed Up, March, 2008
- WordPress Performance: Why My Site Is So Much Faster Than Yours, April, 2007
- Yahoo! Best Practices for Speeding Up Your Web Site
WordPress Plugins You Need