On Sat, Jun 25, 2011 at 11:58:25PM +0200, Claudio Jeker wrote: > The problem with slow loading pages is more because of all the crap they > load. Like the facebook and twitter iframes that take ages to load. And > prefecthing will make it worse because the servers will all be busy > serving prefetching clients of other users that will most probably never > visit the site.
I haven't really hacked on web servers much (only checked nginx for some other stuff), but I always thought it worked like this: - browsers have priority queues for things they are downloading, and as they see <link> prefetches or the apropriate HTTP headers, they act accordingly (meaning "low prio"); the moment the user wants something, they stop/stall prefetching and go doing useful stuff - servers/balancers have priority queues for new requests vs long active streams for example, and reqs with "X-moz: prefetch" go to the lowest priority; they may return some temporary error if they're too busy - browsers accept that - servers send errors to prefetch requests that would be uncacheable - there's a paper from Mozilla stating they keep two open connections to each site in case one of them dies (maybe because of an aborted prefetch)) which after marco's observations seems not true for webkit. If it's done other way, please tell me, so I'll stop spreading lies. Of course, as we both wrote, the problem starts when a site loads from 10 different domains and browser with white screen waits for "ads.adclickmanager.com". This is what I thought prefetching would solve -> your browser would load all this slow shit and next click would be at some reasonable speed. I don't know what facebook's or twitter's iframes load and, more importantly, where from. Sure, servers _can_ be busy. But browsers have time until the user finishes reading. At both this sides stuff can time out after, say, five seconds for these. In the worst case, who cares? > The problem is that most webdesigners have no clue about how websites are > loaded so they build stuff that takes ages to load. Not because of > bandwidth issues but more because of people not understanding how TCP > works and how to reduce delays. That is definitely a huge problem, not only for web designers but across the current generation of "IT experts". But as long they serve their ads from their servers in one connection using HTTP/1.1, everything is fine. The reality's a bit different though, which is why this all exists. On Sat, Jun 25, 2011 at 10:32:50PM +0000, Stuart Henderson wrote: > It's partly "browser decides", I haven't seen anyone doing that. But yes, it is possible, and then it's also "some-huge-layer-7-filter-in-the-middle-of-the-internet decides". I was considering what is presented as "the correct way". > also "search engine decides" and "some random site linking to some > other site decides". These are sites just like any other. What is wrong about google prefetching the first result? The page will see your referer anyway, most people use first results first, so? If you don't like your search engine to do this, you can use another one :-) > For one side of prefetching (DNS queries), it can be educational > to install dnstop, run 'dnstop -l 3 <interface>' and then press 3, > then move your mouse pointer around the browser window, try it in > various browsers and see how they behave. Some do serious damage > to the crappy caching dns resolver in cheap consumer-grade adsl > routers... Thanks, your posts very often bring up some new interesting tool :-) I'll test when I have some crappy box within reach. > > Of course, the right way to do it is blocking all the ads, flash and > > javascript using a proxy and not really being concerned about idiots > > thinking their website is "cooler". > > Hang on, didn't you just say it's "web creator decides"? :-) I'm sorry. ;-) > > And he will probably eat up more of your resources that way, > > which is basically why you need a quad core for surfing the web > > in Windows these days. > > No way. How can in "any way" be any sophisticated javascript mechanism eating the same amount or even less resources than browser's priority queue filled before the page even loads, is a mystery to me. But maybe I didn't get the irony behind it :-) -- Martin Pelikan
