Stating with this whole website performance an ETag topic opened pandoras box. It’s a real mess and lame compromises all over the place. But I have to admit that the whole thing is not as easy as I expected it to be.
Anyway … today I had a nice discussion with a colleague about this topic. He’s a senior front-end developer. This means he is a real pro in HTML, CSS, Java-Script and stuff like this and he’s the one who showed me the whole Yahoo! performance stuff. After this discussion I wanted to check some things out in detail.
Stating with this whole website performance an ETag topic opened pandoras box. It’s a real mess and lame compromises all over the place. But I have to admit that the whole thing is not as easy as I expected it to be.
Anyway … today I had a nice discussion with a colleague about this topic. He’s a senior front-end developer. This means he is a real pro in HTML, CSS, Java-Script and stuff like this and he’s the one who showed me the whole Yahoo! performance stuff. After this discussion I wanted to check some things out in detail.
First I wanted to check if the Apache was sending two different ETags if you have to Apache web servers delivering the content of a website. A simple test with wget verified it:
wget --no-dns-cache -S http://www.a-domain.de/flash/ballons_main.swf
--09:14:26-- http://www.a-domain.de/flash/ballons_main.swf
=> `ballons_main.swf'
Resolving www.a-domain.de... 84.xxx.xxx.x17, 84.xxx.xxx.x33
Connecting to www.a-domain.de|84.xxx.xxx.x17|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Thu, 22 May 2008 07:14:26 GMT
Last-Modified: Tue, 20 May 2008 15:49:24 GMT
ETag: "1041e6-7b2c8-6c9fc900"
Accept-Ranges: bytes
Content-Length: 504520
Keep-Alive: timeout=15, max=45
Connection: Keep-Alive
Content-Type: application/x-shockwave-flash
Length: 504,520 (493K) [application/x-shockwave-flash]
When requesting the first web server the ETag “1041e6-7b2c8-6c9fc900″ war returned …
wget --no-dns-cache -S http://www.a-domain.de/flash/ballons_main.swf
--09:14:26-- http://www.a-domain.de/flash/ballons_main.swf
=> `ballons_main.swf'
Resolving www.a-domain.de... 84.xxx.xxx.x17, 84.xxx.xxx.x33
Connecting to www.a-domain.de|84.xxx.xxx.x33|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Thu, 22 May 2008 07:14:26 GMT
Last-Modified: Tue, 20 May 2008 15:49:24 GMT
ETag: "b824e-7b2c8-6c9fc900"
Accept-Ranges: bytes
Content-Length: 504520
Keep-Alive: timeout=15, max=45
Connection: Keep-Alive
Content-Type: application/x-shockwave-flash
Length: 504,520 (493K) [application/x-shockwave-flash]
… after requesting the second web server the ETag “b824e-7b2c8-6c9fc900″. So if you do not disable the INode usage for the ETag calculation the whole mechanism will not work. But does this really matter. As you can see the DNS caching was disabled for the test. In a real life situation the DNS caching we be activated and my browser will talk only to one web server and the INode issue won’t matter at all.
But if we have multiple web server and the internet browser will only talk to one of them, why do I need the ETag? The Last-Modified header will be enough, won’t it?
So my conclusion is use either the Last-Modifed header or the ETag header but using both header makes no really sense at all. This should be right in any case for the Apache HTTPD, the Microsoft IIS or any other web server delivering static content. I also recommend using the Last-Modified because the ETag calculation requires more computing time. There is only one scenario I can provide where the ETag will work and the Last-Modifed Header will not. If someone is changing content and does not modify the last modified time stamp. But this should be rather uncommon.
But how is the situation at dynamic content creation? My favorite web framework is Java Servlets and all related technologies (JSP, JSF, Tapestry, and so on) and after that very disappointing chapter with the ETag I decided to take a closer look at the facilities the servlet and JSP APIs are offering. Another sad very sad story at my actual point of view right now. But for tonight it is enough. Later more about it …
