Configure Entity Tags (ETags)

What are entity tags?

Entity tags, or known as the ETag HTTP response header, are cache validators which help the browser determine if it can retrieve the requested resource from local cache or if it must be retrieved from the server. This mechanism helps improve loading times since if the resource can be retrieved from local cache, the browser does not need to make an additional request to the server.

A traditional ETag is comprised of three separate components which make it an unique identifier for each resource:

• INode
• MTime
• Size

An example of what an ETag may resemble containing all three components would be similar to 13630e1-b438-524daace96280. However, this may change in structure depending upon the web server, if the ETag is using strong or weak validation, and if you configure entity tags.

The problem with entity tags

Although entity tags can be useful for minimizing the amount of round trips (thanks to caching), there does exist a problem in using this method. In the traditional sense, etags are meant to be used on a website which only delivers content from a single server. Therefore, for websites that are delivering various resources from multiple servers using either Apache or IIS, entity tags do not work well. etags generated for the same components across various servers will not be recognized from one server to another and therefore will return a status of 200 instead of 304 Not Modified.

This means that instead of retrieving content from local cache, it will make a request to the origin. Consequently, not only will your users experience slower page speeds, but your origin server will also be under greater load and thus consume more bandwidth. Thankfully, this ETag issue can be resolved by configuring them correctly for multiserver use.

How to configure entity tags

This section shows the simple process of how to configure entity tags on your origin server. For those using Apache 2.4 or higher, there is no configuration required as Apache has updated the FileETag directive. However, to configure entity tags for websites running on older versions of Apache, the INode portion of the ETag can be stripped by modifying the snippet within your httpd.conf file from

FileETag INode MTime Size

to

FileETag MTime Size

This will remove the first section of the ETag and will leave you with something similar to b438-524daace96280. Now that there is no server component within the ETag, this fixes the multiple server issue.

ETag vs Last-Modified

Website owners who are using multiple servers to deliver content can decide whether they want to specify a cache validator using ETag or Last-Modified. As long as you are using a web server which solves the ETag INode issue, or have properly configured it yourself, both options are valid. To learn more and visualize the differences between both options, read our 304 Not Modified article.

However, if you choose to use Last-Modified header, which validates the component based on a timestamp, you can simply remove the ETag and use Last-Modified in conjunction with Expires or Cache-Control. In Apache, removing etags is done by adding the following to your configuration file.

Header unset ETag
FileETag none

Doing so completely removes the ETag header which also reduces the overall HTTP header size. In any case, using ETag or Last-Modified headers are both valid options in regards to improving browsing cacheability and website speed.