e-testing Blog

E-Tags

by Howard Osborne

E-Tags, Good Performance Testing

In this deep dive we are going to look at E-Tags and how they optimise application performance.

To do this we are going to take look at the etesting shop. Open you browser and navigate to http://shop.etesting-lab.com

etags_webcam_etesting_deep_dive

Well that looks nice – lots of bargains but before we do any shopping let’s have a look at what we really asked for when navigating to this page.

etags_navigating_deep_dive_series

In total we received 25 items. As well as the page itself we also got some stylesheets to tell the browser how to render elements on the home page, JavaScript files to some more functionality on your machine such as making the slider move and some images to show you what you can buy.

The slowest overall item was the home page itself, but this was mainly down to taking a long time to do some server-side processing before actually starting to download the document. Once it got started, it download pretty quickly.

etags_server_deep_dive_series

However, the speed of the next four resources are more about the size of the file to be downloaded.

etags_resources_deep_dive_series

Now what happens if we reload this page?

etags_reload_resources_deep_dive_series

The server still takes a while to do some work before sending the main page but the rest of the resources are lightning-quick, or so it seems. In the third column we see a different response code. Before the codes were all 200, but now they are 304 – page not modified.

Instead of sending us the resource, the server has told our browser to just use the one it already has. Pretty neat. But how does it know it can rely on what the browser already has?

Let’s look at some of the header information sent by the server when an image file was requested:

Accept-Ranges: bytes

ETag: “0ec7c8e4c82ce1:0”

Server: Microsoft-IIS/8.0 X-Powered-By: ASP.NET

The server sent an etag, which is a unique identifier for this resource.

When the page was subsequently requested, the browser sent the following header information.

Accept: image/webp,image/*,*/*;q=0.8

If-None-Match: “0ec7c8e4c82ce1:0”

Accept-Encoding: gzip, deflate, sdch

Now the server knows which resource the browser has. It can check to see if this is the same as the current copy it has and if so, sent a 304 response to the browser to just use what it already has.

A simple yet effective idea; and that really should be all there is to say on the subject, except what can be used for good can also be used for evil, or at least things we may not overtly consent to. By supplying a unique code to a client which it will then send back to the server next time, there is now a method for tracking the use of a resource by an individual – cookies by the backdoor.

So the future of ETags depends on how responsibly it is used. If they get abused, we may see similar rules on consent as there are with cookies. But for now, they remain a key tool in keeping unnecessary traffic to a minimum.

Missed part 1? Read about minifying now >>

Missed part 2? Read about compression now >>

Missed part 3? Read about caching now >>

CLICK HERE FOR UPDATES

Subscribe to our RSS feed and get the latest updates in your inbox weekly

logo