by Howard Osborne
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
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.
Now let’s tell our browser we want the same page again by clicking refresh
Now the browser only asked for 7 files. So what happened?
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