ETags: Use 'Em or Lose 'Em
If you have multiple servers hosting your web site and you're
using Apache or IIS with the default ETag configuration, your users are
getting slower pages, your servers have a higher load, you're consuming
greater bandwidth, and proxies aren't caching your content efficiently.
"But wait!" you say, "I followed Rule 3 and added a far future Expires
header to my components. There
shouldn't be any conditional GET requests."
Even if your components have a far future Expires
header, a conditional GET request is
still made whenever the user clicks Reload or Refresh. There's no way
around itâthe problem with ETags has to be addressed.
One option is to configure your ETags to take advantage of their
flexible validation capabilities. One example might be a script that
varies depending on whether the browser is Internet Explorer. Using PHP
to generate the script, you could set the ETag
header to reflect the browser
state:
<?php if ( strpos($_SERVER["HTTP_USER_AGENT"], "MSIE") ) { header("ETag: MSIE"); } else { header("ETag: notMSIE"); } ?>
If you have components that have to be validated based on something other than the last-modified date, ETags are a powerful way of doing that.
If you don't have the need to customize ETags, it is best to simply remove them. Both Apache and IIS have identified ETags as a performance issue, and suggest changing the contents of the Etag (see http://www.apacheweek.com/issues/02-01-18, http://support.microsoft.com/?id=922733, and http://support.microsoft.com/kb/922703 ...
Get High Performance Web Sites now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.