e-testing Blog

Caching

by Howard Osborne

Caching for Good Performance Testing

In this deep dive we are going to look at how browsers play their part in optimising application performance.

We are going to use the etesting shop at: http://shop.etesting-lab.com

webcam_etesting_shop_caching

When we ask for the homepage, our browser actually asked for 24 components (when you try this you may get an image or two more). You can see this using the developer tools that come with modern browsers.

 

caching_tools_url

Now let’s tell our browser we want the same page again by clicking refresh

caching_tools_url_2

Now the browser only asked for 7 files. So what happened?

Let’s have a closer look at what we received when we initially asked for one of the JavaScript files (jquery-ui-1.10.0.custom.min.css). As well as getting the file in the body of the response, we also got the following headers (only some are shown for simplicity):

javascript_caching_etesting

 

The browser has read the max-age value for the Cache-Control header which tells it how long it can keep its current resource before asking for an updated version. In this case, it is 86400 seconds or a day. If we ask for the page again tomorrow, it will also ask for this file.

Another, and older, approach is to use an Expires header. In this case, rather than setting a time interval, a date is given when the resource need next be requested. If a far future date is set, resources that are unlikely to change can be cached for up to a year.

Different file, different name…
So what should you do if you need clients to get an updated version of a file but have told the browsers previously that they don’t need to get an updated file just yet? The simplest answer is to update the filename. If fact you can go one step further by embedding the version of the file (or some other unique identifier) into the name.

Different browsers, different settings…
If you tried the steps above and didn’t get fewer files the second time around, it may be that your browser has not respected the cache-control header, perhaps it was more interested in another header: ETags. We will look at this in the ETags deep dive

Ready for Part 4? Read about E-Tags Here >>

Missed part one? Read about minifying now >>

Missed part two? Read about compression now >>

CLICK HERE FOR UPDATES

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

logo