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.
Related
In my web page I have the same image used ~5000 times in different places.
I always heard that browser will automatically cache images and I should not worry about it, yet, when I profiled my page load in Chrome, it does not seem to be the case. Please find attached screenshot of profiling result:
All the marked red areas is downloading the same image over and over again. It is marked as "Receive Data", so I assume it is indeed downloading it every time.
When I check Resource URL being downloaded, each instance has additional unique id added, like: "https://localhost:44344/images/MenuNode.png?1588089781084", which is not present in my code.
All those downloads are adding up to a noticeable chunk of time.
Is there a way to only download this image once, to speed up overall page load time?
Ok, I found it, for some reason a library I was using to draw charts was detecting all images inside it's nodes html and adding unique identifier to them...
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.
I have a series of overlapping questions, the intersection of which can best be asked as:
Under what circumstances does an # character (an anchor) in a URL trigger an HTTP fetch, in the context of either an <a href or an <img src ?
Normally, should:
http://foo.com/bar.html#1
and
http://foo.com/bar.html#2
require two different HTTP fetches? I would think the answer should definitely be NO.
More specific details:
The situation that prompted this question was my first attempt to experiment with SVG stacking - a technique where multiple icons can be embedded within a single svg file, so that only a single HTTP request is necessary. Essentially, the idea is that you place multiple SVG icons within a single file, and use CSS to hide all of them, except the one that is selected using a CSS :target selector.
You can then select an individual icon using the # character in the URL when you write the img element in the HTML:
<img
src="stacked-icons.svg#icon3"
width="80"
height="60"
alt="SVG Stacked Image"
/>
When I try this out on Chrome it works perfectly. A single HTTP request is made, and multiple icons can be displayed via the same svg url, using different anchors/targets.
However, when I try this with Firefox (28), I see via the Console that multiple HTTP requests are made - one for each svg URL! So what I see is something like:
GET http://myhost.com/img/stacked-icons.svg#icon1
GET http://myhost.com/img/stacked-icons.svg#icon2
GET http://myhost.com/img/stacked-icons.svg#icon3
GET http://myhost.com/img/stacked-icons.svg#icon4
GET http://myhost.com/img/stacked-icons.svg#icon5
...which of course defeats the purpose of using SVG stacking in the first place.
Is there some reason Firefox is making a separate HTTP request for each URL instead of simply fetching img/stacked-icons.svg once like Chrome does?
This leads into the broader question of - what rules determine whether an # character in the URL should trigger an HTTP request?
Here's a demo in Plunker to help sort out some of these issues
Plunker
stack.svg#circ
stack.svg#rect
A URI has a couple basic components:
Protocol - determines how to send the request
Domain - where to send the request
Location - file path within the domain
Fragment - which part of the document to look in
Media Fragment URI
A fragment is simply identifying a portion of the entire file.
Depending on the implementation of the Media Fragment URI spec, it actually might be totally fair game for the browser to send along the Fragment Identifier. Think about a streaming video, some of which has been cached on the client. If the request is for /video.ogv#t=10,20 then the server can save space by only sending back the relevant portion/segment/fragment. Moreover, if the applicable portion of the media is already cached on the client, then the browser can prevent a round trip.
Think Round Trips, Not Requests
When a browser issues a GET Request, it does not necessarily mean that it needs to grab a fresh copy of the file all the way from the server. If it has already has a cached version, the request could be answered immediately.
HTTP Status Codes
200 - OK - Got the resource and returned from the server
302 - Found - Found the resource in the cache and not enough has changed since the previous request that we need to get a fresh copy.
Caching Disabled
Various things can affect whether or not a client will perform caching: The way the request was issued (F5 - soft refresh; Ctrl + R - hard refresh), the settings on the browser, any development tools that add attributes to requests, and the way the server handles those attributes. Often, when a browser's developer tools are open, it will automatically disable caching so you can easily test changes to files. If you're trying to observe caching behavior specifically, make sure you don't have any developer settings that are interfering with this.
When comparing requests across browsers, to help mitigate the differences between Developer Tool UI's, you should use a tool like fiddler to inspect the actual HTTP requests and responses that go out over the wire. I'll show you both for the simple plunker example. When the page loads it should request two different ids in the same stacked svg file.
Here are side by side requests of the same test page in Chrome 39, FF 34, and IE 11:
Caching Enabled
But we want to test what would happen on a normal client where caching is enabled. To do this, update your dev tools for each browser, or go to fiddler and Rules > Performance > and uncheck Disable Caching.
Now our request should look like this:
Now all the files are returned from the local cache, regardless of fragment ID
The developer tools for a particular browser might try to display the fragment id for your own benefit, but fiddler should always display the most accurate address that is actually requested. Every browser I tested omitted the fragment part of the address from the request:
Bundling Requests
Interestingly, chrome seems to be smart enough to prevent a second request for the same resource, but FF and IE fail to do so when a fragment is part of address. This is equally true for SVG's and PNG's. Consequently, the first time a page is ever requested, the browser will load one file for each time the SVG stack is actually used. Thereafter, it's happy to take the version from the cache, but will hurt performance for new viewers.
Final Score
CON: First Trip - SVG Stacks are not fully supported in all browsers. One request made per instance.
PRO: Second Trip - SVG resources will be cached appropriately
Additional Resources
simurai.com is widely thought to be the first application of using SVG stacks and the article explains some browser limitations that are currently in progress
Sven Hofmann has a great article about SVG Stacks that goes over some implementation models.
Here's the source code in Github if you'd like to fork it or play around with samples
Here's the official spec for Fragment Identifiers within SVG images
Quick look at Browser Support for SVG Fragments
Bugs
Typically, identical resources that are requested for a page will be bundled into a single request that will satisfy all requesting elements. Chrome appears to have already fixed this, but I've opened bugs for FF and IE to one day fix this.
Chrome - This very old bug which highlighted this issue appears to have been resolved for webkit.
Firefox - Bug Added Here
Internet Explorer - Bug Added Here
I have a single 3.3ko image that i display in 15 different img HTML balise in my web page.
I am wondering if the Base64 encoded method is not a bad idea for this use case, since it significantly make the page heavier to load (since i display the image 15 times), than using a "classic URL".
However i am not sure that a bigger HTML page to load still slowly than a lower one which have to reach the image from the server, what is theorically the best choice here ?
OK,
If you load the base64 image in the page 15x then you add about 510,000 bits of data to the total page size. This data has to be transferred from the server to the client and will take just over 0.5 seconds (over a 1mb line) + the propagation delay for the page which will be around 75ms. So the total is around (aprox 500ms + 76ms) => call it 600ms.
If you include put the image on the Server and reference it from the various parts of the page by URL) It has to transmit around 34,000 bits and once downloaded will pull the image from the local download cache a further 14 times + propagation delay for the image and a propagation delay for the page page. Getting the image from cache takes almost no time typically < 1ms) The overall expected cost on a 1mb line would be roughly (34ms + 76ms + 14ms + 76ms) => about 200ms.
This is a highly simplified view of what happens and a number of factors come into play as a page is loaded. The number of hosts domains, Download threads, Script execution, CSS styling, positioning, paint events, layout events and so on.
You can put base64 strings directly in the background: url() CSS tage if its going to be used behind a DIV or button and repated on you page.
But its typically a good thing to put the resource on the server and download it as required by URL in the places its needed. Not only for your sanity when it come time to copy and paste 15 Base64 string into your page when the image changes :)
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