Re: why add script-tag in header section ?

On Nov 17, 4:04 pm, "optimistx" wrote:
Evertjan. wrote:
It is not pedantic, because certain DOM functions are not
available till the DOM is ready, and trhis is very important
to us programmers and gives a sore "does not work" feeling
to the user.

Experimenting with serverside "response.flush" [asp], will
give you a sour awakening from your "just pedantic" dream.

of onload-event might seem a bit theoretical for an average
joe user.

This is not a NG for users, they would not understand the
intricacies and niceties of scripting. Do you?

Of course the event DOM is ready must be considered by the
programmer. Programmers mainly try to serve users.

I moved 12 js external file scripts to the end of an html-page
and left only 1 in the head. The texts appeared much sooner to
the display (in about 0.3 seconds),
although the window.onload was fired at about 6 seconds. The
time saved is well spent for the user: one can start getting
on overview of the page content,

You re describing the situation for a 'first time' user. the regular
user already has that overview, and probably has a pretty good idea of
what they want to do. For example, consider a blog (not an uncommon
thing these days) where the visitor has already read the contents and
is returning with the purpose of seeing if any new/interesting
comments have been added. So, as soon as the contents 'appear' that
user want to scroll down to the bottom of the page to get to the new
comments, but the browsers UI is blocked because it is busy processing
a mass of javascript files that were loaded at the very end of the
mark-up. That arrangement has the potential to be more frustrating for
than seeing a blank page for longer but having the page usable very
shortly after it first appears.

The time until some content is first visible is a very superficial
measure of speed. Likely to impress management and clients, but
probably much less important to actual users.

and when one is ready to click something etc, the page is
probly ready for that too.

For a first-time user, maybe. A regular user probably wanted to get on
with their business as soon as the UI appeared.

So
e.g.
savings of 5 seconds IN PRACTICE for the USER.

Or making them aware of their open-ended frustration waiting for
something that on the surface appears to be 'there' but is not yet
useable.

That practical savings in spite of the pedantic note
'time to dom_is_ ready -event does not essentially change'.

There are three stages, 'not there at all (pervious page/blank page)',
'there but not working' and 'there and working', there is only so much
that fiddling with SCRIPT placement can do towards shortening the
transition through the whole sequence.

It is also worth noting that on the Internet it is common for HTML
mark-up to be between 4 and 40 times the size it could be for the same
effect, for CSS to be 2 to 4 times the size it could be, and for
images to be 5 to 40 times the size they could be (and client side
caching is often compromised where it should be being encouraged).
Thus there is enormous potential for making significant inroads into
download performance long before it is worth anyone's while tinkering
with the placement of SCRIPT elements.

Richard.
.

Relevant Pages

  • Re: JSON without AJAX
    ... > Not testing the return value of the (DOM) method called previously. ... browsers and implementing further features. ... It was not debated that it is possible to append `script' elements ... Syntax nazi, standards nazi, netiquette nazi, but you seem ...
    (comp.lang.javascript)
  • Re: speed issues traversing the DOM.
    ... It seems that in the javascript DOM context all you can do is give it an ... not markup no html. ... var itemRef, itemName, itemDOMElement; ...
    (comp.lang.javascript)
  • Re: Dynamic select lists using optgroups again - without frameworks
    ... in the last script element. ... The DOM will be ready and you don't need to use window.onload (or ... Using onload is also based on the "mere assumption" that the UA ... at the time the feature was introduced, ...
    (comp.lang.javascript)
  • Re: Decoding html pages
    ... from the DOM (as one can see by using the DOM tool ... but it is removed from the HTML. ... the HTML page removes all references from firebug's DOM panel. ... The HTML panel of firebug surely shows the script gone. ...
    (comp.lang.javascript)
  • Re: Aus .aspx.cs auf eigenes DOM zugreifen?
    ... Quelltext der Seite), dass das irgendwas von HTML drinnen steht, welches im Browser in soetwas wie ein "DOM" gerendet wird, entzieht sich seiner Logik. ... Unlogisch finde ich trotzdem, dass ich in .NET jeden Mist als XML laden kann, aber nicht den eigenen OutputStream. ... "modification2", script, true); ...
    (microsoft.public.de.german.entwickler.dotnet.asp)