>> > > We are prefetching them already. And we have a config option for that. > It's just too slow.
I know I'm being terrible dense, but I don't see how this makes sense. Matthew had mentioned that the concern stemmed from the fact that the browser had a lmited number of connections to each host, in this case, to fproxy. This causes the browser to request two images, say A.jpg and B.jpg, and wait for them to download from the network before it requests C.jpg and D.jpg This problem is exacerbated with a great many pictures. If there are 27 pictures on a page, and the node requests them 2 at a time, it will take a very long time for the entire site to load. (Assuming it is larger than allowed in one container) If instead, fproxy were to parse the html, and start downloading every image file as soon as the html is finished, the browser-connection limit becomes almost irrelevant to the discussion; The node isn't downloading the pictures 2 at a time anymore, it's downloading as as it can, and then sending them to the browser (quickly/locally) 2 at a time, which takes immeasurably short time, compared to the pull from the network. Where I get confused is trying to reconcile your statement that you are prefetching, with Matthew's argument that a custom XUL runner is needed because of the connection limits. -CPD
