Thanks Alex, David; Marko brought up a point that I forgot mentioning--
out application is not particularly stream-lined, and it's a very
heavy, very enterprise-level application.

A non-cached "medium" page on it takes above half a minute to load on
T1...

That's half a minute where the user is pretty much waiting for the JS
files to download one after the other.

Our application does not rely heavily on JS currently, but we are
building a new framework and the idea is to use more and more JS as we
go along.

On top of that, all of the resources are downloaded from a single
server, which includes a lot of images and style sheets, as well as an
unholy number of other HTTP requests.

Here's the extract that Marko was referring to, and that preoccupies
me dearly:

[quote]
The problem caused by scripts is that they block parallel downloads.
The HTTP/1.1 specification suggests that browsers download no more
than two components in parallel per hostname. If you serve your images
from multiple hostnames, you can get more than two downloads to occur
in parallel. While a script is downloading, however, the browser won't
start any other downloads, even on different hostnames.
[/quote]

Also, most of the pages are information-heavy, so it's likely the user
will need a chance to read and evaluate before clicking anywhere--this
is another point in which our opinions (my colleague's and mine)
differ.

Oh, one other thing I didn't mention is that this is an
internationally sold application and it's very likely to be run on
"legacy" hardware with slow connections on some companies.

So,
- Alex pretty much concurs with my co-worker about the observers
needing to be in place,
- David believes the "break-time" disgraceful as it may be could be
useful, although I think he was thinking HTML will load during that
time (it won't, nothing else at all except JS) and he was thinking
along the lines of milliseconds when it's closer to twenty to thirty
seconds,
- Marko points out the issue that YSlow evaluates which is precisely
what concerns me,
Any other takers or opinions after the additional information?

Once again, thank you all and sorry for not painting out the whole
picture in the first place =P


On Sep 16, 9:51 am, Marko <gm.ma...@gmail.com> wrote:
> Hi all,
>
> Here is description from YSlow:
> /JavaScript scripts block parallel downloads; that is, when a script is
> downloading, the browser will not start any other downloads. To help the
> page load faster, move scripts to the bottom of the page if they are
> deferrable.
>
> /Isn't that the point why to put it on the bottom.
>
> - Marko
>
>
>
> david wrote:
> > Hi Javier,
>
> > Alex answer is good, an I will follow his way.
> > But it depend on a few things:
> > - internet / intranet: meaning if response time to load JS files could
> > be long, you should have as your collegue says an amount of time where
> > your application, is not running, but all HTML will be load. A kind of
> > "break time".
> > - The amount of code executed, if it's very important, you'll still
> > have that "break time"
>
> > This break time could be disgracefull. but we are talking generally
> > about hundreds of millisecondes.
> > This is very short time for humans, but of course it make a big
> > difference on charts. :))
> > I personnally put it on top, my users are not terminator !
>
> > --
> > david
>
> > On 16 sep, 12:11, "Alex McAuley" <webmas...@thecarmarketplace.com>
> > wrote:
>
> >> Personaly form my experience putting JS at the top or bottom shaves only a
> >> second or so on page rendering/loading....
>
> >> If you application relies heavily on javascript for its enhanced
> >> functionality and needs the observers in place to function then i would put
> >> it at the top.
>
> >> for example....
>
> >> Load the javascript in the head as normal, then add the event observer for
> >> dom/window load/ready to set the observers up...
>
> >> Yahoo's idea is only one out of many ways of doing things and what may work
> >> for them with their infrastructure and frameworks may not work or benefit
> >> everyone.
>
> >> Alex Mcauleyhttp://www.thevacancymarket.com
>
> >> ----- Original Message -----
> >> From: "skaiuoquer" <skaiuoq...@gmail.com>
> >> To: "Prototype & script.aculo.us" 
> >> <prototype-scriptaculous@googlegroups.com>
> >> Sent: Tuesday, September 15, 2009 10:42 PM
> >> Subject: [Proto-Scripty] YSlow's rule "JavaScript at the bottom" 
> >> w/Prototype
>
> >>> Guys, I wonder if you can help me with this;
>
> >>> I just had a twenty minute-long discussion with a senior co-worker on
> >>> the YSlow rule "put JavaScript at the bottom"--for more information on
> >>> it, please check out [
> >>>http://developer.yahoo.com/performance/rules.html#js_bottom
> >>> ].
>
> >>> Now, I want to adhere to this rule as well as eliminate "onevent"
> >>> attributes on HTML tags on a given product.
>
> >>> My colleague thinks this is going to result in "bugs" when perplexed
> >>> users are confronted with a "fully" rendered page and thus attempt to
> >>> click on links that have no JS behaviour added yet--since I want all
> >>> of the behaviour to be added using the 'observe' method.
>
> >>> Is this so? Can you guys please shed some light on this subject on an
> >>> application basing its JS on Prototype?
>
> >>> Thanks in advance and warm regards,
>
> >>> - Javier
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to