Cloud Four Blog

Technical notes, War stories and anecdotes

Should I Remove ETags From My Headers?

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.

Related Articles

Easy Steps To Speedup Your WordPress Blog

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?

Here at Cloud Four, we are big fans of the work done by the Yahoo! Exceptional Performance team to research and publish best practices for improving web performance. For us, the big finding was that most of the end-user response time — as much as 80% of the total page delivery time — occurs after the server has finished all its back-end work to create the page. Why such a long delay? Well, we’ve all been steadily increasing the number of Javascript, stylesheet, and image references on our fancy blog pages, and that means the browser has a lot of work to do before it can completely render the page for the reader. This finding is good news for most of us, since improving the page layout and rendering behavior are well within the skillset of almost anyone who can setup WordPress and install plugins.

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.


<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript application/x-httpd-php application/rss+xml application/atom_xml
</IfModule>

3. Add an Expires Header


Add the following lines to your .htaccess file. This action tells the web server to add an Expires header for files that are unlikely to change in the near future. The reader’s browser will then cache the files until the expiration date, not even bothering to check for a new, updated version in the meantime. Note that if you DO change any files with a far future expiration date you will need to change the file’s name, otherwise any browser with a cached version will fail to fetch your new version. You are most likely to experience this issue with CSS or Javascript files, so don’t say I didn’t warn you.

    <IfModule mod_expires.c>
      ExpiresActive on
      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"
      ExpiresByType application/javascript "access plus 1 month"
      ExpiresByType application/x-javascript "access plus 1 month"
    </IfModule>
  

If mod_expires is not available on your system, you can try this instead:

    <FilesMatch ".(ico|jpg|jpeg|png|gif|js|css)$">
      Header set Expires "Sun, 22 Apr 2018 01:10:54 GMT"
      Header set Cache-Control "max-age=315360000"
      Header unset Pragma
    </FilesMatch>
  
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.

    FileETag none
  
5. Install the PHP Speedy WordPress Plugin


The PHP Speedy WordPress Plugin is a real gem, implementing several of the Yahoo! best practices: combining multiple files to reduce HTTP requests, minifying Javascript and CSS, compressing the files via GZIP compression, and adding far future Expires headers. You should configure PHP Speedy to minify everything, compress Javascript and CSS, and add far future expire headers for both Javascript and CSS. There is no reason to enable GZIP compression for the web page itself, since we are doing that via apache.

Since this plugin modifies the way your page references Javascript and CSS files, take some care to test your site after activating your configuration. PHP Speedy appears to preserve the load order of the files, which is the main thing I care about. And if necessary you can exclude specific files from this optimization step. Still, I recommend that you test like crazy on this one.

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 -->
  

Results!

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 (!)

Where Next?

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.

Good luck!

WordPress Plugins You Need

Resources