I have two pages and after the first page loads, I use javascript image object like this:
var workshopBack = new Image();
workshopBack.src = "/images/wBack.jpg";
The wBack.jpg is the background for the next page, but it is huge, so I load it before in the first page itself. Now my question, when the user navigates to the next page, will the background be loaded from cache or will it be downloaded it again?
Normally loading an image will keep it in the cache for a while, but there are no guarantees.
There is no standard for how the browser cache should work, it's just implemented as best the browser vendor knows. It's entirely possible that some browsers have an implementation that will drop the image as soon as possible, because of its size. You just have to test in different browsers to see how they react.
Also, the state of the cache may also affect the result. Even if your browser keeps the image, some other user may have a different set of files in the cache, or a different cache limitation, that makes the browser drop the image. You can only make sure that it works in most cases, there is never a guarantee that it will work in all cases.
Related
If i have an image element with a default src(ex. img1.jpg) and then with javascript change to a different image(ex. img2.jpg) it will load the first image and then the second image.
But if i change back to the original image(img1.jpg), will that image be loaded again(total load times: 2)? or is it cached in any way.
If not, is there any convenient way to cache it when doing such a thing?
The image src will load the image once so if you have "img1.jpg" many times in the page will only load it once but it will render it multiple times. So to answer your question you will not have a problem loading it again and again like in your example.
Modern Browsers these days create cache and maintain it till the session. In your case if img1.jpg is loaded first by the browser its cached though its being replaced by img2.jpg later. but if you go back to img1 it will load much faster as its cached already
I tried looking this up in google but Im getting alot of turtorials on "how to" rather than what the side effects are.
When changing the src of an img, does this cause a double caching effect? What if someone had used jquery to create a slider/rotater/comic viewer/marquee/etc and had used jquery to do so?
On a mobile device, could the page stop working after the image rotates through with the device receiving some type of error similar to "page is too large?"
Could the images be cached in a way that that the browser remembers them? And by that I mean when you have an image with a specific name that you make an edit to and the browser loads a cached version of it. Could this cause false image loads if a randomizer code was placed to choose a random image?
I am just curious what kind of effects this could have on a browser by browser/visit by visit basis.
I wanted to test this, but I feel my results could be secluded or not broad enough to cover all scenarios when the knowledge may already be available.
This is purely for knowledge, not for a project. I figured someone else might wonder as well.
Updating the src attribute loads the new image.
Even though I would pre-load the image first, then replace or handle the image in that manner.
You can see a working example for both here: http://jsfiddle.net/je9w1n9m/
But I think your issue is more about how your caching headers are set-up for static content. If you have caching headers set-up right on your web server to tell the browser to cache the static content, then the image will return a 304 Not Modified response, and will be cached in the browser from the first time it loads.
Let's say that I have two accordion tabs. The first one loads hundreds of images and is open when the page loads.
I want to be able to stop the images from downloading if the user clicks on the second accordion tab. Will changing the src attributes of the images via js stop the images from downloading? Or do the requests just continue until completion and not show up on the page?
I have a script that loads the SO logo in exactly 3 seconds that I had made for another question.
http://alexturpin.net/slowimage/slowimage.php
Using it, I tried to reproduce the problem:
var img = new Image();
img.onload = function() {
alert("loaded");
};
img.src ="http://alexturpin.net/slowimage/slowimage.php";
setTimeout(function() {
img.src = "";
}, 1000);
http://jsfiddle.net/Xeon06/RrUvd/1/
From what I gather, in Chrome, the onload doesn't get fired, but the browser keeps on showing a spinner and if I go on the network tab and find my image and check it's content, it's there. So my answer would be no, the image still loads, at least in Chrome.
This is an interesting problem, I suggest you try and test it in as many browsers as possible and write some kind of blog post on it.
Your browser asks for that image with a specific HTTP GET request, as
specificated in HTTP protocol. Once it asks for it, the http server
starts the transfer.
So, it is between the browser (as http client) and the http server.
Since http protocol does not takes into account the option to abort a
transfer, the browser should implement a out-of-standard mechanism to
programmatically abort the connection. But since this is not specified
in any standard, i think you won't find any way to do that with
javascript or any client side code.
You can try window.stop() to stop all requests, but not individual
ones.
If you wanted to stop a single request for a large image, what you
could do is load the image into a document within a hidden IFRAME. The
onload event of the IFRAME can be used to load the image into the main
document, by which time it ought to be cached (presuming you have the
caching directives configured to do so).
If the image is taking too long, then you can access the IFRAME's
contentWindow and issue a stop command to that.
You need to have as many IFRAME elements as there are images that can
be requested simultaneously.
Taken directly from here & here.
Not sure if it will, just like the other comments. But I can suggest am approach that will work well. Assuming not all the images are visible, just set the right src attribute when they become visible.
So default the url to myGray.gif when it is not visible and set it to myImage.jpg when it does come into view.
When you close the current accordion, you can set the image source back to your lightweight gif again. (this prevents a bug related with gc on some versions of the ipad).
I'm dynamically switching background images. Naturally, they need to be preloaded to display promptly. I am preloading them, am able to following in FireBug as the images load. When the background image switches, I see the images download again in FireBug.
Here's my url: http://www.morganpackard.com/siteRoot/
Strangely, if I reload the page, everything works as expected. The steps I'm taking are as follows:
1) clear FireFox cache
2) reload page
Images load slowly, and, apparently are neither being preloaded nor cached. Every time there's an image swap, the image downloads again.
3) now reload the page again without clearing the cache
Images load and swap instantly, everything works as expected.
So it looks like I'm having to RELOAD before FireFox will read images from the cache. This is kooky. Any ideas?
Note: My images are ENORMOUS. I'll compress them, of course, but want to get this preloading this sorted first.
I didn't read your code, but for preloading to work, you must add the image to the document DOM, otherwise it can be garbage collected aggressively.
Checking with HttpFox, I am not seeing further http requests - when clicking around - for your background images after the initial load. If I hit "refresh" then the images are reloaded. I think this is correct and what you'd expect. However be aware that reloading of a page and its assets like images, css etc on a page refresh is dependent on both response headers and any over-rides for these specified in your browser/plugin tools. Take a look at pragma: no-cache and W3C Cache-Control (Section 14.9)
Edit: With firebug on, I am seeing reloads when I click around. This is presumably an artefact of Firebug. Turn off firebug and you wont have the reloads.
I have a bunch of images that I am preloading inside of a loop. One of
these images is also loaded by the html, so I get a good look at how
these two different methods perform. For measurement, I am using the
Network pane of the Safari Web Inspector, after clearing the cache.
The ClownFish image is 280KB, and when referenced by the HTML takes 14ms to
load, while the Aurora image referenced by JS in the preload is
116KB and takes 77ms to load.
var images = ['Aurora', 'ClownFish', 'DewDrop', 'EarthHorizon', 'FlowingRock', 'GentleRapids', 'GoldenPalace'];
images.each(function(elm){
var path = elm + '.jpg';
var preload = new Image();
preload.setAttribute('src',path);
});
Is this all overhead from setting up the Image() and then assigning
the src to it? Is there any way to speed this up?
Have you checked if this is also the case in Firefox (using Firebug)? And are those load times how long it takes to retrieve the image itself? Or is it how long from the start of the request until the image is loaded?
If the latter, it could have something to do with where/when the javascript gets loaded on the page, or the browser already has too many requests to the domain the images are on and has to wait until some of those complete before preloading your images.
I'd also be curious to see how long the load times are if you don't preload the images at all. Do you get low load times for all images if they're loaded by the html? If not, then maybe the web server is the issue.