I am using a JQuery Plugin called lightbox (which is great btw). Problem is, I am accessing images on external sites and I think they are blocking lightbox from preloading them.
Specifically I have confirmed that picasa gives the preloader a 404 (using firebug), but if I right click the failed request in the firebug "net" tab, and "Open in new tab" The image loads fine.
This happens with any images from picasa, unless I've already viewed them (in which case I believe they are pulled from the brower's cache rather than loading them again)
There are a a few differences between the headers sent by the browser vs the preloader (also from firebug):
the preloader's "Accept" header is:
image/png,image/*;q=0.8,*/*;q=0.5
vs loading the image directly in the browser:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
I suspect this is one way a remote server could differentiate a browser request from the javascript. What do you think?
Also, here is the preloader code from the plugin... just in case
// Image preload process
var objImagePreloader = new Image();
objImagePreloader.onload = function() {
$('#lightbox-image').attr('src',settings.imageArray[settings.activeImage][0]);
// Perfomance an effect in the image container resizing it
_resize_container_image_box(objImagePreloader.width,objImagePreloader.height);
// clear onLoad, IE behaves irratically with animated gifs otherwise
objImagePreloader.onload=function(){};
};
objImagePreloader.src = settings.imageArray[settings.activeImage][0];
update
apparently picasa is blocking me from displaying the full-size images at all whether part of the DOM or preloaded via javascript... not sure what to do about this
You could always add the preload IMG tags to the DOM in a hidden DIV instead of loading them with JavaScript. That way the browser is loading them "naturally".
solution
Picasa will let external sites load images up to 800px wide... if you try to use any larger than that on an external domain (not picasaweb.google.com) you will just get a 404
fortunately for me 800px is plenty... I was just trying to load the originals, which you're not allowed to do at all haha
Related
I am attempting to show a simple mockup to a potential client of how he could stream media from his own online radio station to a page. The radio station was built using an external site and in Safari rendering the station's share link in an iFrame works perfectly, and plays immediately on page load without the user having to do anything. Here is the pure html code; there's no JS for this page now:
<iframe src="https://lucasdraft.out.airtime.pro/lucasdraft_a" frameborder="0"></iframe>
The CSS:
iframe {
height: 50px;
width: 200px;
float: right;
}
But in Chrome, half the time when I try to load the page the iframe doesn't show up at all and the page loads continuously with the status at bottom left displaying "Waiting for available socket"- again this never happens on Safari. When it does load in Chrome, instead of showing the basic media player from the external source it shows a sort of gray semi-circle with three dots. If I click this gray blob it begins playing, but this is very un-intuitive to a user not to mention ugly. I assume this is a security feature in Chrome but haven't found any reliable way of fixing it. Increasing the size of the iframe does not change anything.
Safari (working as expected):
Chrome loading error:
Chrome with cache cleared, after loading the iframe:
Thanks and anything helps in fixing this pesky error!
For the Waiting for available socket, a quick google search got me this answer. Chrome hangs after certain amount of data transfered - waiting for available socket It's always a good idea to google something before asking.
For the visual problem. the Url in your Iframe is calling a video. Different browsers use different style for their video player. Chrome just needs a little bit more height. I find that 100px works well.
I had the same issue(Worked in safari but not in chrome). In my case the issue was the Ad-blocker . Ad-blocker usually writes scripts to override the iframe styles.
Once I disable the ad-blocker or load the project in incognito(private browser) window the iframe content loaded successfully.
I am using a JavaScript library to arrange few images on the webpage. The following browsers:
Firefox
IE 11
Microsoft edge
render the page as it was planned, the problem occurs with Chrome browser. It messes up the complete layout.
The above browsers don't load any content unless all the images have been downloaded, until then it shows a blank white screen, and all of a sudden it will show all the content rendered perfectly. And in case of Chrome, the browser displays content on the go, as in you can see the images appearing in a scanline fashion.
I've tried calling the function that arranges these images inside:
$(window).load(function() {})
and it didn't fix the issue, I tried calling this in the <head></head> and also just before closing </body>, that didn't fix it either. Is this a Chrome related issue?
What should be the correct point in time where the function should be called?
There is a nice library on the web with a comprehensive name imagesLoaded designed to fix your issue! It is supposed to work cross-browser of course, so no differences in behaviour in Chrome or other browsers.
With its help, you can run your code at the moment when all images loaded in specific DOM element or elements controlled by jQuery selector. Like:
$('body').imagesLoaded( function() {
// images have loaded
});
There are also .done, .fail, .progress callbacks supported if you need, so check the docs.
In some cases you have to wait until the image loads to get a parameter not specified in the <img> tag, such as height for example. Then you may use $(window).load
In other cases, for example, adding some classes to the images, you can do it before the image load.
If you want to load the images after the page loads completely or when the user really scroll and see each image, Lazy Load is a good plugin and it support callbacks.
Images should load First as hidden, Then your script should run like
$(document).ready(function(){
// here do the scripting may be showing them one by one
});
I have looked at a number of SO questions on how to preload images, I have created a function
$(images).each(function () {
var img = new Image();
img.src = this;
$(img).appendTo('body').css('display', 'none');
});
Which appends the images to the dom. However when I add a product to my cart, (the minicart will contain the images which have been preloaded), chrome still produces a request on that minicart image even though it has been preloaded (I can see the image in chrome developer tools). How do I get chrome to use the image which has already been loaded instead of getting another one from the server?
your server is sending wrong headers; do a search about Cache-Control, Expires, Etag and Pragma and set them to cache your images instead of download
chrome is buggy or it intentionally downloads the image twice. for example setting display:none too early may cause the problem, use position:absolute;left:-100000px; instead
your developer tools is set to disable cache (click on the gear icon, then uncheck General > Disable cache (while DevTools is open) )
I have a website where sometimes it loads quickly, however sometimes it seems as though the page has stopped loading half way through, possibly due to a script.
The website is http://www.pinspired.com - The tabbed sidebar on the right is the problem. I am using a simple jquery tab plugin and twitter and facebook script in the tabs.
Firstly, does the page load quickly for you?
How can I find out which script is stopping the rest of the page loading. It is hard to test as it only happens occasionally.
Thanks in advance.
I just ran the dev tools and it looked like the jquery.carousel plugin is what took the longest.
That aside, my feeling is that you should reconsider using an iframe to load in the carousel. I do know that multiple iframes on a page can slow the page down. And considering the size of the content you are loading inside that iframe, it might explain the delay. You might want to do some research on iframes and consider the order in which iframes are loaded into the DOM.
Your site's loading fine here.
For the Facebook "Like Box", consider using the iframe version.
http://developers.facebook.com/docs/reference/plugins/like-box/
After clicking the "Get Code" button, select "IFRAME". This may remedy your issue.
I suggest you have a look at the chrome developer tools. You can see how long it takes to load each resource (87 request just to load the landing page - wow!), you can profile scripts to see if something takes very/too long and you can even do an audit and let it check several things you can possibly optimize.
For example
merge the javascripts you are loading from the same domain
set the webserver to use gzip to send script/html files compressed
many resources are explicitly set to be not cachable; for example all the product images and the social media pins (preventing that they are loaded over and over again and will speed up things a lot after the they first page load)
merging images like the social media pins and use css sprites
provide different/only the needed css scripts for each site; according to chrome almost 300kb of css rules are unused on the frontpage
You can find out all that stuff usign the Chrome Developer Tools. All you need is Chromium/Google Chrome.
If it is really the facebook script couldn't you just add a slight delay before loading the fb plugin? Like 500 - 1000ms or so after everything else (well most of it) is loaded.
EDIT: The answer drewcode posted is right. It looks like jquery.jcarousel is causing the delay. See here:
Suppose in Javascript that you assign the SRC to an IMG tag. It is a large SRC and you want to cancel it before it has finished loading. Assigning the SRC to another image will not stop the data from loading.
That is, in the middle of the load you can assign the SRC to another smaller image and the smaller image will be loaded and appear in your browser. However, the original SRC still continues downloading.
Similarly, deleting the IMG node will not prevent the SRC from continuing to download. No guesses please, look at the repro steps.
REPRO
Load this URL in Chrome in Windows: http://68.178.240.17/imgLoadTest/imgLoadTest.htm
Open up the developer panel by pressing CTRL-SHIFT-J
On the top row of icons in the Chrome developer panel click the Network icon to watch network activity.
On the web page loaded in Step 1 click the Load Image button and watch the developer panel as a large (32meg) image starts loading.
On the web page click the Try To Cancel button to load a different image.
A small image loads, but watch the network in the developer panel and notice that the large image continues to download.
Quick answer
Setting the src attribute of the img tag to the empty string will interrupt the current download, even on Chrome.
Details
Nowadays most of browsers implemented that out-of-standard mechanism thought in the old answer to programmatically abort the connection. This is not achieved through a protocol request, but with a client-side in-memory operation. Keep in mind that is not a standard behaviour, but most of vendors courtesy. That is, it could not work on every browser.
I've prepared a jsfiddle showing this mechanism in action (keep an eye at the network panel of the inspector).
Old answer (2011)
Your browser asks for that image with a specific HTTP GET request, as specified 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.
Cancel with transparent base64 encoded GIF to avoid additional requests and double page load on android:
var img = new Image();
img.src = 'http://google.com/favicon.ico';
img.src = 'data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEAAAAALAAAAAABAAEAAAI=;'
Although I can't find the bug report now, I believe this is a long-standing logged WebKit bug. Firefox (and IE I think) have more sane behavior. I'm going back a bit in my brain, but if I recall on those browsers, resetting the img.src will in fact cancel outstanding downloads. I am positive that Firefox does this when a download is "waiting in line" for a chance at an open HTTP connection, and I seem to recall that it will actually force close connections sometimes.
I've never found a way to coax WebKit based browsers into cancelling an img download in progress, whether it is just queued or already actively downloading.
This really sucks if you're making something like a mapping client and need more fine grained control over images.
Setting the .src property to an empty string should cancel the load:
//load image from url
var img = new Image();
img.src = 'http://somedomain.com/image.jpg';
......
//cancel load
img.src = '';
Yes, page is downloaded twice on Android when an img tag has an src="" attribute.
This still occurs on recent Android versions.
I have not found any other browser that does that.
But I found a solution: use an img tag without src attribute.
The ultimative answer is web workers.
Load the image inside an webworker and stopping the web worker will stop the image loading.
You can get the idea from this code:
https://github.com/NathanWalker/ng2-image-lazy-load
this work for me:
imageVarName.src = '';
imageVarName.onload = null;
imageVarName.onerror = null;
the src property must be a valid non-empty URL
So null or empty string are not legal (even though they sometimes work).
Use:
img.src='http://xxxx';
img.onerror=null;
(see here)
Sadly, setting src to an empty string does not work in WebKit-based browsers like Safari. Here is the link to the bug report which Stella mentioned.
https://bugs.webkit.org/show_bug.cgi?id=6656