When multiple instances of same images are embedded in an HTML, does that load the image once?
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
- Set the img element to the completely available state.
- 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.
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.
It may depend on the specific browser implementation, but I would expect the first reference to the image to hit the server and subsequent references to the same image URL to be served from the browser cache. So, only one network request for the image.
That is, IF the HTTP cache headers set by the server on the image response allow the browser to cache the image at all. If the cache header is set to something like "no-cache", then the browser is required to refetch the image for every reference. You can check to see what the HTTP headers on the image response are using a network packet sniffer like Fiddler.
If the browser doesn't populate the image URL in the browser cache until after the image has completely downloaded, then you could see multiple requests for the same image, but that seems very unlikely.