When multiple instances of same images are embedded in an HTML, does that load the image once?

Question

If I use the same image within a single page multiple times, will each load separately, taking up the bandwidth and traffic, or will only one be loaded and rest embed code will reuse the image?

For example, let's say I did this:

<img src="http://img.to/image.jpg"/> <img src="http://img.to/image.jpg"/> <img src="http://img.to/image.jpg"/> <img src="http://img.to/image.jpg"/> <img src="http://img.to/image.jpg"/> <img src="http://img.to/image.jpg"/> ... <img src="http://img.to/image.jpg"/> <img src="http://img.to/image.jpg"/> 

and image.jpg is 100kb. When the browser loads this page, will it waste up (100Kb * # of img tags) of traffic? or will it just load one image.jpg and reuse it for the rest of the tags?

Answer 1

Browsers that implement 5th version of HTML specification may reuse images regardless of cache related HTTP headers. Probably only single network request will occur.

Specification defines image key.

7.2 Let key be a tuple consisting of the resulting absolute URL, the img element's crossorigin attribute's mode, and, if that mode is not No CORS, the Document object's origin.

When browser downloads first image source it adds it to list of available images using key.

If the download was successful and the user agent was able to determine the image's width and height

1. Set the img element to the completely available state.
2. Add the image to the list of available images using the key key.

When browser sees another image with same key it will take it from a list of available images.

7.3 If the list of available images contains an entry for key, then set the img element to the completely available state, update the presentation of the image appropriately, queue a task to fire a simple event named load at the img element, and abort these steps.

Nevertheless, browser may remove image from list of available images at any time.

Each Document object must have a list of available images. Each image in this list is identified by a tuple consisting of an absolute URL, a CORS settings attribute mode, and, if the mode is not No CORS, an origin. User agents may copy entries from one Document object's list of available images to another at any time (e.g. when the Document is created, user agents can add to it all the images that are loaded in other Documents), but must not change the keys of entries copied in this way when doing so. User agents may also remove images from such lists at any time (e.g. to save memory).

For more information see How does a list of available images used when parsing document with multiple img nodes with same src? issue in HTML Standard repository on GitHub.

Answer 2

Try it — when looking into caching issues, a tool like Firebug for Firefox or the Developer Tools within Chrome are very beneficial. If you open the 'Net' panel in either and reload a page, you will see what HTTP status code was sent for each item. 304 (Not modified) means that the item was retrieved locally from the cache.

As dthorpe says above, cache headers are important here. As well as making sure that 'no-cache' hasn't been set, if you have access to your server configuration you should be pro-active — if you know a resource isn't going to change you should make sure to set either an 'Expires' header (which tells browsers a date after which the cached copy should be considered stale) or a 'Cache-Control: max-age' header (which gives a number of days/hours rather than a set date).

You can set different time-scales for different mime-types/folders too, which allows you to get clients data to refresh HTML content often, but images and stylesheets rarely.

Here's a nice intro video/article by Google that's worth checking out.