Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #37774 > unrolled thread

Embed <script> at end of HTML vs. DOMContentLoaded handler

Back to article view | Back to comp.lang.javascript

Contents

  Embed <script> at end of HTML vs. DOMContentLoaded handler luserdroog <luser.droog@gmail.com> - 2019-11-12 15:52 -0800
    Re: Embed <script> at end of HTML vs. DOMContentLoaded handler Arno Welzel <usenet@arnowelzel.de> - 2019-11-14 16:25 +0100
      Re: Embed <script> at end of HTML vs. DOMContentLoaded handler Julio Di Egidio <julio@diegidio.name> - 2019-11-14 08:34 -0800
        Re: Embed <script> at end of HTML vs. DOMContentLoaded handler Arno Welzel <usenet@arnowelzel.de> - 2019-11-15 17:29 +0100
      Re: Embed <script> at end of HTML vs. DOMContentLoaded handler John G Harris <niam@jghnorth.org.uk.invalid> - 2019-11-14 19:30 +0000
    Re: Embed <script> at end of HTML vs. DOMContentLoaded handler Martin Leese <please@see.Web.for.e-mail.INVALID> - 2019-11-12 21:55 -0700
    Re: Embed <script> at end of HTML vs. DOMContentLoaded handler Julio Di Egidio <julio@diegidio.name> - 2019-11-13 07:18 -0800

#37774 — Embed <script> at end of HTML vs. DOMContentLoaded handler

I've noticed a lot of pages put the <script> tags at the end
of the HTML file. Does this practice avoid the need to put
DOM-manipulating code in a handler for DOMContentLoaded?

A priori, I think the HTML looks much tidier if all the scripts
and links are at the top. But the javascript possibly looks 
tidier if it doesn't need to delay the mainline code by wrapping
it in an event handler.

Are there other considerations I've overlooked or better ways
to make this choice?

[toc] | [next] | [standalone]

#37776

Julio Di Egidio:

> On Wednesday, 13 November 2019 00:52:45 UTC+1, luserdroog  wrote:
>>
>> I've noticed a lot of pages put the <script> tags at the end
>> of the HTML file. Does this practice avoid the need to put
>> DOM-manipulating code in a handler for DOMContentLoaded?
> 
> Loading scripts at the bottom makes the page render faster, because (deferred
> scripts aside) the very parsing of the page is synchronous and will pause in
> order to load and run any scripts it encounters (though the browser starts
> showing things along the way, which is why the perceived responsiveness is
[...]

Some nitpicking here:

The total rendering time itself will not change. So if a page needs 2
seconds to render, this won't change. But the rendering will start with
less delay if there are no scripts at the top or included in the header.

So for example instead of heaving 0.3 seconds script execution followed
by 2 seconds page rendering you will have 2 seconds page rendering and
0.3 seconds script execution when the rendering has finished.

On the other hand even a page which looks to be fully loaded may still
need some time to execute the scripts at the bottom before you can fully
interact with it. However this is not a problem in most cases since
visitors will usually spend at least half a second or more to read the
content of the page before they try to interact with elements.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#37778

On Thursday, 14 November 2019 16:26:03 UTC+1, Arno Welzel  wrote:
> Julio Di Egidio:
> > On Wednesday, 13 November 2019 00:52:45 UTC+1, luserdroog  wrote:
> >>
> >> I've noticed a lot of pages put the <script> tags at the end
> >> of the HTML file. Does this practice avoid the need to put
> >> DOM-manipulating code in a handler for DOMContentLoaded?
> > 
> > Loading scripts at the bottom makes the page render faster, because (deferred
> > scripts aside) the very parsing of the page is synchronous and will pause in
> > order to load and run any scripts it encounters (though the browser starts
> > showing things along the way, which is why the perceived responsiveness is
> [...]
> 
> Some nitpicking here:
> 
> The total rendering time itself will not change. So if a page needs 2
> seconds to render, this won't change. But the rendering will start with
> less delay if there are no scripts at the top or included in the header.
> 
> So for example instead of heaving 0.3 seconds script execution followed
> by 2 seconds page rendering you will have 2 seconds page rendering and
> 0.3 seconds script execution when the rendering has finished.
> 
> On the other hand even a page which looks to be fully loaded may still
> need some time to execute the scripts at the bottom before you can fully
> interact with it. However this is not a problem in most cases since
> visitors will usually spend at least half a second or more to read the
> content of the page before they try to interact with elements.

You are welcome, just quite off-mark:

I have rather tried and made clear that what matters (the "requirement") is how
quickly the page *starts* rendering, i.e. the "perceived responsiveness".  That
said, even if by "total rendering time" you mean dom-ready, it is still the case
that the first rendering of elements will be done before the scripts have their
go, as long as the scripts are at the bottom of the page (or are deferred): and
that is overall "faster" relative to the (first) rendering of all elements.
For example instead of having....

Indeed, the "total time of rendering" strictly speaking is not even meaningful:
you may speak of dom-ready time, which is the end of the parsing and DOM
building and of the first sweep of rendering (and script loading), or you may
speak of page-load, which is when all external resources have finished loading,
and there too things get rendered, and then in fact the rendering just never
ends until page-unload: these are multi-media dynamic pages in general...

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#37788

Julio Di Egidio:

[...]
> Indeed, the "total time of rendering" strictly speaking is not even meaningful:

It is. Because the browser will *always* need this time, regardless if
there are scripts at the beginning or at the end of the page.

The only thing which changes is, how fast the user will see "something".
But this "something" may still not be the final page when scripts will
start working with the DOM when it's ready. I have seen this often on
news websites which start rendering very quickly but even if you think
the page is fully loaded it will take some time before layout stops
"jumping around".

For example:

Go to <https://m.tagesspiegel.de> and scroll down to the end then
refresh the page to see the final layout getting built dynamically.

Then repeat the same with disabled JavaScript - you will notice that
most of the layout is missing.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#37783

On Thu, 14 Nov 2019 16:25:55 +0100, Arno Welzel <usenet@arnowelzel.de>
wrote:

  <snip>
>On the other hand even a page which looks to be fully loaded may still
>need some time to execute the scripts at the bottom before you can fully
>interact with it. 

Back around 2000 AD a web page that jiggles around for a second or
more was said to be made by an incompetant web designer. Nowadays it's
compulsory. Hey ho. JQuery rules OK!


>However this is not a problem in most cases since
>visitors will usually spend at least half a second or more to read the
>content of the page before they try to interact with elements.

It is a problem if it's possible to click on the page and get the
wrong result or the wrong update. The code must ignore clicks until
everything has settled down.

  John

[toc] | [prev] | [next] | [standalone]

#37891

luserdroog wrote:
> I've noticed a lot of pages put the <script> tags at the end
> of the HTML file. Does this practice avoid the need to put
> DOM-manipulating code in a handler for DOMContentLoaded?
> 
> A priori, I think the HTML looks much tidier if all the scripts
> and links are at the top. But the javascript possibly looks 
> tidier if it doesn't need to delay the mainline code by wrapping
> it in an event handler.
> 
> Are there other considerations I've overlooked or better ways
> to make this choice?

You can use include the "defer" attribute,
to defer execution, but only if you use the
"src" attribute.  That is to say, if your
script is not embedded.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[toc] | [prev] | [next] | [standalone]

#37899

On Wednesday, 13 November 2019 00:52:45 UTC+1, luserdroog  wrote:
> 
> I've noticed a lot of pages put the <script> tags at the end
> of the HTML file. Does this practice avoid the need to put
> DOM-manipulating code in a handler for DOMContentLoaded?

Loading scripts at the bottom makes the page render faster, because (deferred
scripts aside) the very parsing of the page is synchronous and will pause in
order to load and run any scripts it encounters (though the browser starts
showing things along the way, which is why the perceived responsiveness is
greater).  This is only really relevant for high-impact web sites such as (the
originally motivating case) search engines, where tenths or even hundreds of a
second differences in *perceived* response time is expected to make a difference
in user satisfaction and retention.  It has since become an industry-wide
practice, indeed why do otherwise.  An exception remain libraries that do need
to load before the bulk of the DOM gets parsed, those that you are mandated to
put at the top.

As for whether to use a dom-ready or even a page-load event to start behaviours
or not, you might even do without in simple scenarios: one thing that is
guaranteed by putting scripts at the very bottom is that the elements you may
need to access have already all been parsed (while, with scripts on top, you do
need to wait until at least after dom-ready time).  OTOH, for one thing, it is
good practice to at least give the browser a chance to finish the DOM parsing,
rendering must start as soon as possible, the rest can take its natural time
and choking the browser is never a good idea.  Besides, there are less simple
scenarios where starting your behaviours immediately is not even possible: e.g.
because you depend on a library that has to be allowed a chance to initialise
and maybe manipulate the DOM itself before you start your own logic (in
particular, any of those libraries that you must load on top and that will not
be done with there initialisation until dom-ready--I won't say until page-load
because it only makes sense to start your own scripts from page-load, indeed
assuming that all external libraries are done by dom-ready time).  And the
bottom line again is, better stay consistent to the common industry practice
and you won't have any surprises with your code, not now nor in the future...

> A priori, I think the HTML looks much tidier if all the scripts
> and links are at the top.

It looks just as tidy if all scripts are at the bottom.

> Are there other considerations I've overlooked or better ways
> to make this choice?

On these things you may be quite confident that industry practices are (at any
given moment) already doing what is best: the web has some 25 years of intense
history now, with a lot of competition on getting the most effective solutions
and the proverbial survival of the fittest...

HTH,

Julio

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web