YSlow's rule "JavaScript at the bottom" w/Prototype

[skaiuoquer]

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

[Alex McAuley]

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 Mcauley
http://www.thevacancymarket.com

[david]

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

[Marko]

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

[Richard Quadling]

2009/9/16 Marko <gm.m...@gmail.com>:

The standard is to only allow 2 requests per server, so I would
question the strength of the reasoning.



--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

[skaiuoquer]

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

[disccomp]

.."move scripts to the bottom of the page if they are deferrable."

I think you should read more into the last word of this quote. If your
application is dependent on the javascript for basic functionality
then those scripts are not deferrable. If the scripts just added eye
candy or some other non-essential function, then they could safely be
deferred.

Why not create one concatenated, minified, and versioned javascript
file which can be served just once per session.

[Richard Quadling]

2009/9/16 disccomp <disc...@gmail.com>:

As I use PHP, I use a derivative of
http://rakaz.nl/2006/12/make-your-pages-load-faster-by-combining-and-compressing-javascript-and-css-files.html

[Alex McAuley]

Well....

The page downloads in linear (line by line) so it depends...

If you reference your JS via src="/path/to.file.js" ... and have many of
these files then you will be stunted by the paralell download stopping.

However.... If you do some smart js thinking (like i did!!!!!!!!) you can
make thigs very fast indeed...

Basically what i done was..

Created a file that minifies my js files on the fly and outputs one long
minified whitespace stripped string back to the browser which includes all
of the javascript needed to run on any page ..

For example if page 1 needs prototype and scripty and effects.js i would
load all three, but if page 2 only needed prototype then i would only load
that (hence concating them and minifying on the fly)...

This speeded up page loading from around 6 seconds (with nearly 1.5 meg of
javascript/images/css) to about 2.8 seconds - then it went on further using
apache's deflate (which i had to remove due to a bug for now))...

As i stated earlier what works for one may not work for others - i came up
with my way because i wanted to be able to read and edit my javascript
without having to re-minify every time i changed something... - also please
note for debugging applications it is a nightmare because you have one long
line of JS and firebug reports incorrect line numbers !!!! - but you can get
the rough area of what's causing the error and open the original javascript
file to fix...

I am more than happy to let people have my source code and the concept
should they want it.

I was going to package it all up and put it on googlecode but i havn't got
round to it yet

Alex Mcauley

[Alex McAuley]

What server side code does your application use - i can give you some stuff
for >= php5.1 that will decrease your load times by about 70% if you like
...



Alex Mcauley

[Jarkko Laine]

On 16.9.2009, at 20.20, Alex McAuley wrote:

>
> Well....
>
> The page downloads in linear (line by line) so it depends...
>
> If you reference your JS via src="/path/to.file.js" ... and have
> many of
> these files then you will be stunted by the paralell download
> stopping.
>
> However.... If you do some smart js thinking (like i did!!!!!!!!)
> you can
> make thigs very fast indeed...
>
> Basically what i done was..
>
> Created a file that minifies my js files on the fly and outputs one
> long
> minified whitespace stripped string back to the browser which
> includes all
> of the javascript needed to run on any page ..

Like http://getsprockets.com/ ?

//jarkko

--
Jarkko Laine
http://jlaine.net
http://dotherightthing.com
http://www.railsecommerce.com
http://odesign.fi

[Alex McAuley]

I wouldnt know, i done this about 6 months ago and have never heard of
sprockets

Alex Mcauley
http://www.thevacancymarket.com
----- Original Message -----
From: "Jarkko Laine" <jark...@gmail.com>
To: <prototype-s...@googlegroups.com>
Sent: Wednesday, September 16, 2009 6:24 PM
Subject: [Proto-Scripty] Re: YSlow's rule "JavaScript at the bottom"
w/Prototype


>

[skaiuoquer]

disccomp, Richard, Alex; thanks for your replies.

The problem with minified compressed versions is that they will never
get cached on the client side.

I mean, they will, but you will still be sending them each one of the
different "combinations"--so instead of loading prototype.js once, the
user will be loading it -albeit compressed- once on every different
combination.

This is a problem, since, like I said, this is a web application that
is meant to be used several times throughout the day, and taking
advantage of browser-caching is quite important for us.

Those ideas are part of the advices that YSlow proposes--and they are
quite good, thanks =)

I will look into those solutions, but, I'm not fully convinced yet
that they are entirely adequate for this particular problem.

(Once again, thanks for your responses, guys.)

On Sep 16, 2:31 pm, "Alex McAuley" <webmas...@thecarmarketplace.com>
wrote:

> I wouldnt know, i done this about 6 months ago and have never heard of
> sprockets
>

> Alex Mcauleyhttp://www.thevacancymarket.com

[Jim Higson]

On Wednesday 16 September 2009 14:43:32 skaiuoquer wrote:
> 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.

Concatenate all files into one in the order that you are loading them, use yui
compressor, gzip. You'll see at least an 80% decrease in load time.

Still, I'd question the sanity of any system that takes 30 seconds to serve a
web page.

Jim

[skaiuoquer]

Hey, you and me both, brother.

We are building the new framework, starting from scratch, so maybe you
are right and I am just troubled by the ghosts of the past and this
will not happen this time around when we'll be using sane logic to
build our code.

I hope you are right.

*suspense*

[Alex McAuley]

The compressed versions i speak of do get cached....


Alex Mcauley

http://www.thevacancymarket.com
----- Original Message -----
From: "skaiuoquer" <skaiu...@gmail.com>
To: "Prototype & script.aculo.us" <prototype-s...@googlegroups.com>
Sent: Wednesday, September 16, 2009 7:51 PM
Subject: [Proto-Scripty] Re: YSlow's rule "JavaScript at the bottom"
w/Prototype

[DJ Mangus]

They do but you'd need to cache each combination of scripts once each.  That's a great way to go about it if you require the same scripts on each page, or the landing page requires all of them (and then it'd cache the concat'd and minified version) and you include the lot on each other page no matter if that page needs all or just some of the scripts.

[Alex McAuley]

Thats not how the script i wrote works sorry.

 

Each page tells the script what to serve, if the page requires no JS whatsoever then the script block isnt even executed.

[Szymon Wilkołazki]

skaiuoquer pisze:

> disccomp, Richard, Alex; thanks for your replies.
>
> The problem with minified compressed versions is that they will never
> get cached on the client side.
>
> I mean, they will, but you will still be sending them each one of the
> different "combinations"--so instead of loading prototype.js once, the
> user will be loading it -albeit compressed- once on every different
> combination.
>
> This is a problem, since, like I said, this is a web application that
> is meant to be used several times throughout the day, and taking
> advantage of browser-caching is quite important for us.
>
> Those ideas are part of the advices that YSlow proposes--and they are
> quite good, thanks =)
>
> I will look into those solutions, but, I'm not fully convinced yet
> that they are entirely adequate for this particular problem.
>

Remember that you decide what you want and what you do not want to
concatenate.

At our company we have two "types" of scripts:
1) Framework scripts, such as prototype, scripty, and our own
framework additions, widgets (calendars, table filters, etc).
Those are common through all the system. It might be, that some parts
are not necessary everywhere, but generally they are used across most
of the pages.

2) Page logic, which are distinct per module, or even per specific
page. This is the place where we initialize all the event handlers,
and here we put the scripts specific for the module, and configuration
for the widgets and so on. Each script used once should be in this
category.

So, each page grabs a concatenated, minified, compressed, versioned!
and cacheble! set of ALL files from category 1.

Then the page requests the creation of the concatenated, minified,
compressed, versioned and cacheble the scripts IT NEEDS from category
2. This is saved serverside, so it is done once after any change to
any of used scripts. The framework puts a second <script> tag to
include page specific concatenated scripts.

So, we end up in two script tags per page load, which both are small
in size, and are cached client-side after first load of the page.

No need to create one huge file for the whole application. Common part
are cached separately, and specific parts are also cached, as the user
of an Application usually uses a number of modules in his/her work
many times a day.

Best regards,
SWilk

[Jim Higson]

On Thursday 17 September 2009 08:48:53 Alex McAuley wrote:
> Thats not how the script i wrote works sorry.
>
> Each page tells the script what to serve, if the page requires no JS
> whatsoever then the script block isnt even executed.

If you want an example of the speedup, compare loading times of minnified:

http://wikizzle.org/wikiz/?action=edit

with not:

http://wikizzle.org/wikiz/?action=edit&compress=no

Jim

--
Jim
my wiki ajaxification thing: http://wikizzle.org
my blog: http://jimhigson.blogspot.com/

[Richard Quadling]

2009/9/16 skaiuoquer <skaiu...@gmail.com>:

If I only need to download the entire set of JS once, then EVERY
single page will benefit.

No matter how much of the library I use.

Even if I don't use any.

But, assuming that I do have different sets (and with a large amount
of redundancy), I would only need to download the set once.

Caching would look after that for me.

The PHP based combinator I use works very well for me.

Each new visitor will get a handful of pre-gzipped CSS and JS files as
they move around the various sites on our intranet.

Once they've visited a page, they never download the CSS or JS again.
That's the point.

You can't magically provide the data without them actually downloading it.

But cache what you can and make the rest serve as fast as you can.