User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 A feature would be nice which tries to load important stuff with a high density of information for humans with a higher priority than low density stuff. Priority can be estimated by multiple things: - Mime type ( Text > Images > Images(animated) > Audio > ...) - Size ( 5 KByte > 100 KByte ) - Data from partially blocked servers ( something between blocking and unblocking) Reproducible: Always Steps to Reproduce: 1. n.a. Actual Results: Often a lot and large (and useless) images avoid a fast load of relevant text, especially on modem connects with typically 20...35 kbps. Expected Results: Fast text load, images only loaded during text loading when there is enough bandwith remaining.

networking.

image priorities are bug 47661

gordon, darin something to think about.

Does necko know the mime type before it starts fetching the document from the server? HTTP sometimes gets the content length, but not until a connection is already established. For REALLY large documents, it might make sense to break the connection and delay loading, as long as we could be reasonably sure that it wasn't the one document the user was most interested in downloading. I'm not sure what 'Data from partially blocked servers' means. This enhancement request might have more to do with layout, rendering the text from the top level document before requesting/rendering images. Is there something we can do in necko, or should we pass this on to parser or layout?

'Data from partially blocked servers' IMHO that means: If you have page from server1 wich contains images from server2 and server2 is overloaded then even small image from server2 took forever to load. And that image is blocking overall loading (especially if there is limit of 8 connections). Example - web-counters, banners

I invisage something like this: 1) Objects that the user's mouse is hovering over (or have focus) should be loaded first. The user can (subconsiously?) hint which images are important on a page, especially as users will tend to hover over things they intend to click immediately. 2) Relative time to download an object within a page can be estimated by the dimentions of the object (from the height=/width= tags). (eg: a 1x1 image will load faster than a 1024x768 image). By loading small images first more of the page will be complete faster than loading the largest images first. Especially since small images are often reused within a page, and are reused between pages and are therefore likely to be cached. 3) Objects that aren't visible (on a non focus'd tab, or scrolled off the current viewport) should be loaded last. 4) prefetchs are loaded when the browser is idle Further optimisations: If the browser keeps track of bandwidth per IP, then when a DNS name resolves to multiple IP's then the browser can choose the one that gives the highest bandwidth (similar how DNS does it with keeping track of RTT per IP), and bandwidth*dimentions would provide an even better estimator of which objects can be loaded faster. MIME type can also be used to estimate how relevant an image is (as mentioned in an earlier comment). The browser has which extension is which mime type in Properties > Helper Applications, and could therefore use this to estimate which mimetypes are important (text/plain, text/html, text/*, image/png, image/gif, image/*, audio/*, application/*, */*), and perhaps estimate the relative size (in bytes) of an object (eg a text/plain of 100x200 px is smaller than a image/jpeg)

This just bug should depend on bug 142255 which just got fixed. It implements the backend stuff for exactly this RFE.

" You tried to change the Keywords field from to perf, but only the owner or submitter of the bug, or a sufficiently empowered user, may change that field."

Now that there is the backend, is there any progress on using it? It would really help with modem connections. A big image in one of the tabs can stop progress in all other tabs even though they may be plain simple text pages.

the backend doesn't currently prioritize one socket over another.. all it does is determine which of the connections _to the same host_ get a socket first.

we already do some of this - css in particular. Will take new bugs on specific new approaches