Sequence of steps browser will follow to read the cached image/content - html

Lets say that i have img tag like this,
<img src = "myimage.jpg" width ="50" height = "50">
When browser first encounter this, it will download the image file and will render it. When again refresh my page, when the browser encounters this line, will it send request to download the file again or it will read from the cache. What are all the sequence of process it will take.
Another Q. comes to my mind immediately is, well if i change the image content but not the image name(myimage), If browser reads the cached image, the content of the image will not be identical with in my server. How to overcome this issue?
Not satisfied with the answer. Can some one tell me, What are all the sequence of process browser will do in these cases?

The browser will send a request for the image to the server even if it has it cached already (at least according to the network log in firebug). As far as I know, the server returns a "last downloaded/modified date" which can trigger a new download if too much time has passed (normally after 3 days or so the browser will redownload cached content).
The easiest way to overcome this is to add a version or release date to the filename so that the browser will ignore its cache.

What the browser does depends on the HTTP header that was returned with the image the first time. Depending on the cache settings for the response, the browser can:
Request the image again,
Request the image if it has changed, or
Use the image in the cache without asking the server

Related

How to force HTML Page Refresh from Server

Currently, I am facing an issue with HTML page. So here if a user visited the site then the browser is caching the entire HTML page. So when the user hits the URL again then the browser taking that HTML from the cache instead of calling/requesting to the server for HTML contents. Here our Team member forgot to add meta tags which would force the browser to take content from Server each time. Is there any way that we could resolve the issue? Since the page request itself not reaching the server so User will not see the refresh contents of the website. If user do Ctrl+F5 then they can see updated contents. I went through many sites and stack overflow questions but I did find a solution for forcing HTML page to load contents from server using meta tags.But existing users is there any resolution that we could apply?
Problem is here the page did not call server to get contents it just loads from cache.
There's nothing you can do.
You've previously instructed the browser to cache the file (presumably for a long time) and not check for updates (via ETags or If-Modified-Since) so it is going to use the cached version until its cache expires (from the user intervening or automatically (which might be sooner than your caching instructions said)).
There's no way to provide new caching instructions to the browser without it requesting them from the server (which it won't do because of the existing rules).

How is it possible inline base64 data uri (image) is cached?

I am using as background image a data uri base64 encoded image directly inline inside the HTML page.
I read everywhere that contrary to unencoded images, they're not stored in cache , which is indeed sometimes a performance problem.
But when looking at my chrome dev tools, I see "cached in memory"...
Are inlined-in-the-html base64 image cached ?
If yes : my question is: I checked it originally because i wanted to analyze the time to load the base64 inlined-image. So i am unable now to see on first download/visit the time spend to decode and load it? I tried clearing my browser history but contrary to other caches (like standard assets like images), it remains, that is to say even if i clear my browser history/caches, the next time I load it, it still is written in chrome dev tools as 0ms/"from memory cache": how can I clear it to see what happens for first time visitors ?
Note: Of course "disable cache' is selected inside chrome dev tools .
Also, I am not sure it is important but here is the base64 and html code (it's pretty small: less than 900 bytes)
<div style="background-image: url('data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wAARCAAKAB4DAREAAhEBAxEB/8QAFgABAQEAAAAAAAAAAAAAAAAABQYE/8QAJBAAAgEEAQMFAQAAAAAAAAAAAQIDAAQREgUTITEyQUJRcZL/xAAWAQEBAQAAAAAAAAAAAAAAAAAEAgP/xAAdEQACAgIDAQAAAAAAAAAAAAAAAQIDESEEInEx/9oADAMBAAIRAxEAPwCOtrYGJmdY36iEIerqUOR3I9/yqRJssYAk2jakg47HIpUFoNYygsZY7PmYmcqge2dYiQMb/Xfxmj8pPRvxWt5Bb6BYbyUB9hIRJqRgrnPmpqei7liQInmqiRIWsPUKVENIT5FQZeJJbUfId/SUW5934IpXReg7Mz8ldFyWJkfJJz8qx+JG7WWz/9k=');" ><a href="/home">
When I repeat your test Chrome makes two requests. The first one fetches the HTML page and is a normal request. The second fetches the image and is served from memory. That makes sense as the image was included in the first request embedded in the HTML itself.
In other words inlined images are not cached unless the page they live in is cached.

Notification to the Browser so that it displays new image

I want to achieve:
I have a html page that displays an image.
which is pretty easy. [say my image file name is xyz.jpeg]
When the file changes or replaced with new content, say, the server or by some other mechanism the file is getting changed,
Now I want this modified image gets displayed in the browser WITHOUT REFRESHING the web page
So, kind of a notification system in which the browser is notified with new image, and gets displayed.
I am not expecting the exactly source code, but a direction of which tool that can be used?.
I have come across websocket, but I am not sure if this solves this purpose.
The image can be refreshed on timely manner(for eg 10 seconds) using javascript, ie request will be send to server in specified time interval, and the image will be updated, this is pretty easy to code also. Please refer this question
However this solution has got a negative impact on performance, since the number of request to be served is too high if the page is accessed by multiple users.
Hope this solves your doubt.

how src attribute of img tag is executed?

Consider the following code :
<img src="http://website.com/Page/1"/>
"1" is a parameter to insert in some table in the "Page" page in website.com.
Will the visitor to this page (that contains the code above) cause an execute of the page and insert 1 to the table ? If the page contains some Javascript code. Will it be executes if we visit the page that contains the code above ?
A browser, if configured to load and display images, will first check whether it has the document matching URL in its own cache as fresh (by some caching criteria). If not, it will send, via HTTP, a GET request to mysite.com for the resource /Page/1. What happens then is up to the server. It may just pick up an image file from its resources and send it to the browser, or it may generate an image an send it, or it might (instead of or in addition to such things) store or update something in its database, or just a counter in a file, or whatever it has been programmed to do.
If the resource sent by the server is image data, the browser will try to display it. If it happens to be e.g. an HTML document, it will be discarded, and the browser will display the value of the alt attribute instead, or an icon of a broken image, or both.
When the browser finds this img tag in a visible area (so it should not be hidden with display: none for example), it executes the image as a http request. That's how statistic tracking works, too.
So as it's a regular http request it will execute the server-side code for that URL, which should in return deliver an image (be it just a blank 1x1 gif), so the browser does not report an error.
But keep in mind the browser might cache the image if you visit this page the second time. So either append a random string or timestamp at the end (e.g. http://website.com/Page/1?23423412341) or tell the browser with htaccess to not cache it.

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

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?
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.