[thelist] Page Contruction, HTTP Connections and Page Load Time (semi long)

VOLKAN ÖZÇELİK volkan.ozcelik at gmail.com
Mon Nov 21 14:34:09 CST 2005


>So, is there any data other than this guy's statements to back this
up? If this is >true, why
>hasn't the "web development world" been more cognizent of this issue?

I faced with a similar issue and shared my findings with the list 5-6
(or more) months ago.

The case was something like that:

case 1:
my page.html
<html>
<head>
tons of js and css (10-20 inline links or more)
<body>
...
</body>
</html>

case2:
<html>
<head>
the css.
</head>
<body>
...
<div>
tons of inline js.
</div>
</body>
</html>


My finding was: the page loaded faster in the second case. Actually it
"seemed to" load faster (which I'll explain in a second).

In the first scenario, the browser waited to download js files and
only after then downloaded the body content along with images.

In the second case, the images loaded and then the js files loaded in
an async manner.

The overall load times was equal in both cases (of course) but the
latter one had given a better user experience because the user could
view the images before the heavy load of the js files finish.

You may find the discussion with exact timings and other observations
in thelist archives. Though I cannot exactly point a link. It was long
time ago.

What I did was to proxy the load process with fiddler and record the
download order of files and their timing.

If you are interested, you may arrange a similar setup as well.

So the statement

"
A browser holds open one and only one connection while loading the
contents of the HEAD element. It cannot use multiple connections until
these items have fully loaded. Thus, the more you have in the HEAD,
the worse performance you can expect.
"

as far as my studies are concerned is true for the major browsers
(NS,IE,OP,Moz).

So you say, "if that's true, why don't people bother?".

First, you don't generally put that much javascript on the head (if
you use javascript to "enhance" functionality rather than use it to
create fancy rollovers, snowflakes etc);
 so most probably it is hard to observe the impact of js on page load.

Secondly, once a page is first visited the js is cached and it will
come in a gasp when the page loads the second time. And since most of
the pages of a portal shares the same core JS files, the load impact
will only be visible for the entry page and only for the first time
(as long as the user does not clear their TIF).

Well actually entry page is the most important page you should focus
your attention on so my second argument is debatable.

HTH,
--
Volkan Ozcelik
+>Yep! I'm blogging! : http://www.volkanozcelik.com/volkanozcelik/blog/
+> My projects/studies/trials/errors : http://www.sarmal.com/



More information about the thelist mailing list