Issue link: https://read.uberflip.com/i/1146286
ETags: Use 'Em or Lose 'Em | 93 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 serv- ers have a higher load, you're consuming greater bandwidth, and proxies aren't cach- ing 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: 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 for more details). Apache versions 1.3.23 and later support the FileETag directive. With this directive, the inode value can be removed from the ETag, leaving size and timestamp as the remaining components of the ETag. Similarly, in IIS you can set the ChangeNumber to be identical across all servers, leaving the file timestamp as the only other piece of information in the ETag. Following these suggestions leaves an ETag that contains just the size and time- stamp (Apache) or just the timestamp (IIS). However, because this is basically dupli- cate information, it's better to just remove the ETag altogether—the Last-Modified header provides sufficiently equivalent information, and removing the ETag reduces the size of the HTTP headers in both the response and subsequent requests. The Microsoft Support articles referenced in this section describe how to remove ETags.