Are browsers in a hurry to show us the web?

How do modern browsers cope with their primary responsibility of displaying sites without making users wait unnecessarily?

I noticed that very often the pages are displayed for an unreasonably long time - it seems that the window title has appeared, and the page is all white. I look in the source code, it’s loaded, even there is an HTML closing tag.

I remember, once, apologists for partisan browsers blamed IE for waiting for a page to load (with tables) before starting to display it. But years passed, and browsers forgot their revolutionary ideals. And were they? It seems all the same. Or "just" sites have become more complicated ...

In principle, I don’t really need to confirm this experience - for me it’s obvious on a good connection at work, and especially on a 33.6 modem at home. But I wanted to see:
- how much browsers are dragging with rendering,
- does everyone do this
- and on all pages.

In addition, formal experience is also useful to overcome the features of browsers that even read the source code (Ctrl + U) from the site again - even if they are right to some extent, but this makes it difficult to assess the reality of the problem.

Das experiment

And I conducted such an experiment: I processed a simple local proxy with a file , which, beeping, tells me when the output of the main document (index.html) ends - this is the first mark on the stopwatch. Then, when the page starts to display, I mark the second time.

At first, I took the time to load bare HTML as 100%. The start time of the drawing, which interests me, counted relative to these 100%.

I used three sites from different categories:
- based on WordPress (38 subdocuments: 6 css + 15 img + 8 JS),
- old article on Habré (83 subdocs: 4 css + 59 img + 15 js),
- Wikipedia article ( 30 subdocs: 8 css + 16 img + 6 js).

Result:


       O pera, S afari, ie, K- meleon, Ch rome and Fx (Firefox).

conclusions

- all the experimental subjects rendered the pages much later than the source code became available to them;

- no one thought to start rendering without waiting for the full HTML download (after all, 20-30-40 seconds is a serious period) - in this context, the gap between “as is” and “as convenient” becomes even more significant;

- everyone rendered the basic HTML pages in a single salvo, including CSS already (all without pictures, of course) - were they waiting for CSS, scripts? in any case, I don’t like it;

- there are no exceptions among the main studied bro;

- Among the web pages of exceptions, according to my estimates, there are also few.

 
Of course, browsers cope with long texts on lib.ru as I need, but still, most next door sites are not so simple, they are not at all. I, as it happened, visit mostly “non-quick” sites; it would be nice, of course, to find out exactly how many of those and others on the Internet.

Technical details

Browser versions, all under Windows XP:
- Opera 9.6
- Safari 3.2.1
- IE6
- K-Meleon 1.1.5 Gecko / 20080406
- Chrome 1.0.154.36
- Firefox / 3.0.5 Gecko / 2008120122
- call me , other names

Before each download cleaned the cache. I ran each site once - I think this is enough and it is tiring. Proksya multithreaded.

The experiments were carried out on an extremely low-speed Internet connection, without artificial restrictions :-). But, I think, this does not negatively affect the experiment - I don’t even give absolute numbers - if the agent’s user didn’t complete the task in 30 seconds, then he won’t cope in 3 (even vice versa, it helped to control the stopwatch with minimal error). The error, according to my calculations, is less than 2% (0.5 s / 20 s).

UPD: Still, I will give the absolute data for the second experiment. Without this, the results are not so apocalyptic (-:

opera 23 88
safari 33 100
ie 27 102
kmeleon 19 72
chrome 46 142
firefox 24 123

In the first line, HTML sucked in at the 23rd second, and began to render at 88th.