| 1:33 pm on Dec 4, 2002 (gmt 0)|
When the browser renders a page, it also builds a list of other elements it needs to fetch, such as stylesheets and images. The order the elements are fetched in, is entirely browser dependent and probably without any guarantees on the order. Natural choices would be a FIFO (first in, first out) or a LIFO (last in, first out), but it could also be just random. Most of the browsers are also multi-threaded, so they actually do more things at a time, so they might have several images in the download pipeline, added to the randomness of the downloads.
So you can't rely on any particular order.
| 2:51 pm on Dec 4, 2002 (gmt 0)|
but the imgs is actually load from top one to the last one
i'm not making it must be the first load, but as ahead as possible
<link rel="stylesheet" href="a.gif" />
hope this will cheat the browser to preload a.gif without side effect
what i want to do is preload the imgs of the post of thread(e.g.: the :) icon and images of ubbcode [img].....[/img])
before any other imgs of html(bg of TABLE/TD, src of IMG, src of INPUT[type=image]
| 5:32 pm on Dec 4, 2002 (gmt 0)|
As seindal wrote, the rendering order is dependent on the individual browser, with no guarantees. The page layout is an important factor - use of tables, etc. Also there is always the possibility of a hold up on any particular image due to server response or Internet congestion re-routing the packets.
For some browsers, it helps to declare the dimensions in your preload script -- newImage(width,height)
If the visitor is likely to visit another page first, you can try including a preload for the troubelsome image there -- so it's already cached when it comes time for the main show. Nevertheless, the rendering order is not ultimately under your control.
| 6:31 am on Dec 5, 2002 (gmt 0)|
yes, i agree
the rendering order is decide by browser, there's no standard telling what order should be take.
but when 20 un-important images follow by 1 important, browsers often start from the first imgs, it don't know which img should load first.
what i NEED is just make individual browser load important image first then un-important
a workable methos may be:
<img src="important.gif" style="width:1x;height:1px" />
<img src="un-important1.gif" />
<img src="un-important2.gif" />
<img src="un-important20.gif" />
-> <img src="important.gif" />
just wonder if there's any perfect, or more suitable method
well, seems i have explained too much :)
thank u guys who reply this post
| 10:43 am on Dec 5, 2002 (gmt 0)|
Giving this a bit more thought, if someone is very keen on controlling image loading, I suppose they could load a blank image first into every image tag except the one they want to render first.
Then call a function onLoad that would switch out the other images on the page from the blank image to what they 'really' want to display.
| 11:55 am on Dec 5, 2002 (gmt 0)|
In the good old days IMG had a LOWSRC attribute for a low-quality image that would be loaded before the SRC, but it is not in the w3c recommendations. Maybe it was just a Netscape thing, but it did give some limited control over image loading order, as the LOWSRC would load first.
Maybe the best way to ensure that certain images are loaded first is to have them loaded by an previous page, so they are in the browser cache, *and* make sure they have the proper Last-Modified and Expires headers sent, so they are in fact cached efficiently.
| 3:59 am on Dec 6, 2002 (gmt 0)|
both "lowsrc" and preload in previous page is easy to maintain for static page, but not for dynamic
suppose you're writing a forum(bbs), there is thread_list.php and thread.php, it's not possible to pre-load images in thread_list.php and user may not click into one of that thread.
un-important images-->images of user interface
important images-->images post by user
maybe... i should reload those un-important images of thread.php in thread_list.php
then when user click into thread.php, because all un-important images is already loaded, now start download important images
but... when using window.open(), some un-important images seem being reload again even it's loaded in cache. i'm puzzled...
| 10:57 am on Dec 6, 2002 (gmt 0)|
The idea is exactly to have the boring navigational images preloaded, so the page-specific interesting stuff comes first.
|but... when using window.open(), some un-important images seem being reload again even it's loaded in cache. i'm puzzled... |
Check your expiry headers. Maybe things are being cached as efficiently as you think. There is a very good tool at [ircache.net...] "Cachability Checker". It'll run a few checks and tell you whether your files cache well.
| 7:46 pm on Dec 7, 2002 (gmt 0)|
I am getting ready to duck right after I say this but what you could do if and only if S/E returns are not a consideration:
Put the page in question into a frameset and set the frame to be 100% then insert the "important.gif" into the noframes tag.
Far from ideal but it might preloade "important.gif" before your actual containing HTML page is called.
| 8:00 pm on Dec 7, 2002 (gmt 0)|
Interesting thinking, piskie. But if the browser is frames-enabled, wouldn't it just ignore the image in a noframes section?
However, if you stick an image preload script on the frameset document, you just might get the desired result.
| 8:08 pm on Dec 7, 2002 (gmt 0)|
I am going to try this out using my WebSpeed Simulator which I can slow right down to a crawl to watch load order unfold in front of me and drink a cup of coffe between images if I want to.
I will report back what what I see and how much coffe I drank watching.
| 3:45 am on Dec 8, 2002 (gmt 0)|
to seindal: i did override the header to make the page cachable, only some gif/jpg reload in newly open window, some not, it's random
as a mordern browser, it's so smart to load what it think important first itself.
e.g.: display:none imgs will not be load first, new Image().src=.... will be load after all other imgs in HTML tags
anyone study the this "smart" behavior of a specified browser?
to piskie: can u share me your WebSpeed-sim?
| 9:48 am on Dec 8, 2002 (gmt 0)|
|to seindal: i did override the header to make the page cachable, only some gif/jpg reload in newly open window, some not, it's random |
If things are set up correctly you will see the graphics elements being fetched on first request, but they shouldn't even be ask for on subsequest requests. If the browser still asks for them, getting either a 200 or a 304 response, your expiry headers on images are not good enough.
You need an "Expire: xxx" header in the HTTP response for each image sent. The expire information on you main page is of no use for the images.
This is what you server should send for a cachable image:
Expires: Sun, 15 Dec 2002 09:42:08 GMT
Last-Modified: Mon, 18 Feb 2002 13:45:51 GMT
You can check it at:
Just enter the url to your image and you will see all the HTTP headers sent to the browser.
To set the expire headers on images you might need access to the server configuration. If it is Apache, you need something like:
# Expire in one week
ExpiresByType image/gif A604800
ExpiresByType image/jpeg A604800
ExpiresByType image/png A604800
ExpiresByType image/x-icon A604800
Caching is a bit tricky, but it can speed things up quite a bit and also take some workload of the server, if done correctly.
I hope all this helps you a bit.
| 4:50 pm on Dec 8, 2002 (gmt 0)|
One thing that's important to consider when attempting to pre-load images is that a browser typically will open only 4 simultaneous connections at a time. That means that IF the browser was evaluating script code to pre-fetch images that are not currently displayed (the on-load OP has not been executed yet), the display of the visible elements on your page may not be visible or be delayed.
It is my guess that the browser will attempt to fetch images in the HTML source first, then begin to evaluate script elements. This is because visible Image size must be determined for the browser to even begin to render a page (eg: img tags in a table).
That said, I have seen another "trick" to cause images to be loaded early: Use img tags right after (or near) your "BODY" tag and set the image width and height to 1. If the images are small, they will load fast, and the browser will have a copy in its cache. Because the images are small, they will be almost invisible. You can spread the img tags around (like after your main logos load) within the HTML if there are many, so that they will not prevent your page from becoming visible for very long.
| 6:08 pm on Dec 8, 2002 (gmt 0)|
thx seindal, your reply teach me a lot
to spinnercee: hm.... u pointed out the key point why my script
var img = new Image(); img.src = 'a.gif';
won't do as i expect
cos it's invisible.
the only way to make it "visible" is make img tags in <body>..</body>
how about <link rel=stylesheet href=important.gif />?
css should be load at the very first.
any effect/side effect?
will it waste client cpu to parse/skip content of the gif?
| 6:37 pm on Dec 8, 2002 (gmt 0)|
|how about <link rel=stylesheet href=important.gif />? |
I'd say it will confuse the browser, but I'd only be guessing - why not create a test page and let us know what you discover?
| 7:07 pm on Dec 8, 2002 (gmt 0)|
|how about <link rel=stylesheet href=important.gif /> |
It is not defined what the browser shall do when the link doesn't return an object of the type text/css. If it is an image it might go in the cache and it might not.
There are no guarantees when one goes outside the standard.
| 1:52 pm on Dec 9, 2002 (gmt 0)|
spinnercee - take the idea of loading the images near the body tag as the content of an absolutely positioned div which is off the normal page area and set the visibility of the div to hidden. This can then be the first item in the HTML code.
| 2:28 pm on Dec 9, 2002 (gmt 0)|
Ian, I've seen that done before, but I would be cautious to use it myself because "smart browsers" have a tendency to ignore, or delay loading of page elements that would not be visible until all of the "known" visible elements (that would also include loading images in the currently focused scroll pane) have been rendered. Remember, there's still a browser war goin on, and page rendering performance is the primary criterion for browser usability.
Speaking of performance, using a .gif, instead of a .jpg image can help page load time. While a .gif is typically larger bytewise than a .jpg image, even when using only 256 colors, it can be rendered (displayed) faster by the browser because it does not have to be decompressed (as much) like a .jpg does. Especially if you're using "onMouseOver" stuff, the images will pop-in and -out faster, if you use .gif -- the effect is noticeable and persistent even when the images are in the browser cache. The .jpg [and most good] decompression algos are CPU-intense, compared to simply "mapping-out" a bitmapped image -- there's always a trade-off -- where the .gif images are color-limited, and will take longer on initial load.
| 4:40 am on Dec 15, 2002 (gmt 0)|
What server are you on?
You could have the image as an asp file...
| 1:56 pm on Dec 15, 2002 (gmt 0)|
I recently had to deal with this. I was not preloading images at all. The images are very small and the delay onMouseOver was only about two seconds.
Then I did something close to what spinnercee spoke on. Next to the images that get replaced onMouseOver, I added <img src="image1.gif" border="0" height="0" width="0">. It makes it easier to maintain by having the non visibile image next to the visiblie image. The images are then cached.
Concerning the number of connections the browser has open to receive content, Mozilla has an option called 'Enable Pipelining'. If I understand it correctly, all Get requests are sent at one time. As it was once explained, there are limitations to the way a browser requests from a server. Generally, the browser worked like this:
get next...receive next
If it were four it would be:
with pipelining enabled all gets are sent and the queue on the webserver sends them. That being the case, the 0 width-height images would not affect the content load?
This is a great topic!
| 2:08 pm on Dec 15, 2002 (gmt 0)|
Actually it reverses the problem. Is it possible to load some images after others, but the result can be almost the same.