Yahoo - Move Scripts to the Bottom

[howa]

According to Yahoo's recommendation:

http://developer.yahoo.com/performance/rules.html#js_bottom

Rule 5 described how stylesheets near the bottom of the page prohibit
progressive rendering, and how moving them to the document HEAD
eliminates the problem. Scripts (external JavaScript files) pose a
similar problem, but the solution is just the opposite: it's better to
move scripts from the top to as low in the page as possible. One
reason is to enable progressive rendering, but another is to achieve
greater download parallelization.


Im fact, I wonder if this method is reliable, just like you have a
link to trigger action, e.g.

<a onclick="test()"...

but this test() is at the end of the page, if people click the link
before the script was loaded...not reliabe...isn';t?

 

[dhtmlkitchen]

According to Yahoo's recommendation:

http://developer.yahoo.com/performance/rules.html#js_bottom

Rule 5 described how stylesheets near the bottom of the page prohibit
progressive rendering, and how moving them to the document HEAD
eliminates the problem. Scripts (external JavaScript files) pose a
similar problem, but the solution is just the opposite: it's better to
move scripts from the top to as low in the page as possible. One
reason is to enable progressive rendering, but another is to achieve
greater download parallelization.

Im fact, I wonder if this method is reliable, just like you have a
link to trigger action, e.g.

<a onclick="test()"...

but this test() is at the end of the page, if people click the link
before the script was loaded...not reliabe...isn';t?

I remember a talk on performance at Yahoo. A member of the audience
asked something like "We have four files that we combined by copy
pasting them into one to improve our Y-Slow grade... What do you
recommend?"

Steve Souders replied to the effect that they should continue their
combining files approach/process.

Having worked on a few projects that have various components, I don't
think it's good advice to follow. This copy-and-paste approach can
lead to code that is not cohsesive and, difficult to maintain, and
hard to test. Much better to develop modular code and build it.

However, regarding putting the scripts at the bottom, the Reference
Errors can be prevented from using "unobtrusive javascript;" attaching
the event hooks in javascript.

Garrett

 

[howa]

Having worked on a few projects that have various components, I don't
think it's good advice to follow. This copy-and-paste approach can
lead to code that is not cohsesive and, difficult to maintain, and
hard to test. Much better to develop modular code and build it.

yes, not difficult to build such module using say, php

However, regarding putting the scripts at the bottom, the Reference
Errors can be prevented from using "unobtrusive javascript;" attaching
the event hooks in javascript.

it might help with the javascript's error,
but those functions are not still usable until the scripts are
laoded,
e.g. user clicked somethings but they can't see anything

 

[RobG]

According to Yahoo's recommendation:

http://developer.yahoo.com/performance/rules.html#js_bottom

Rule 5 described how stylesheets near the bottom of the page prohibit
progressive rendering, and how moving them to the document HEAD
eliminates the problem.

You seem to have not read the bit where it says valid HTML *requires*
style elements to be in the head. I have no idea why they suggest
putting them elsewhere.

Scripts (external JavaScript files) pose a
similar problem, but the solution is just the opposite: it's better to
move scripts from the top to as low in the page as possible. One
reason is to enable progressive rendering, but another is to achieve
greater download parallelization.

Im fact, I wonder if this method is reliable, just like you have a
link to trigger action, e.g.

<a onclick="test()"...

but this test() is at the end of the page, if people click the link
before the script was loaded...not reliabe...isn';t?

Read the section again. It says "If a script can be deferred, it can
also be moved to the bottom of the page". Clearly the code that
declares a function should be loaded before (or at latest immediately
after) the HTML element that tries to call it.

There are other performance strategies that can be tried before
shifting script elements on the page becomes useful - e.g. minify
scripts, keeping code bulk to a minimum, put multiple scripts into a
single file, allow caching wherever possible, etc.

 

[ksjeong]

Hello.

you can use YAHOO.util.Event.addListener(); or try {} catch{}.

 

[Peter Michaux]

I remember a talk on performance at Yahoo. A member of the audience
asked something like "We have four files that we combined by copy
pasting them into one to improve our Y-Slow grade... What do you
recommend?"

Steve Souders replied to the effect that they should continue their
combining files approach/process.

Having worked on a few projects that have various components, I don't
think it's good advice to follow. This copy-and-paste approach can
lead to code that is not cohsesive and, difficult to maintain, and
hard to test. Much better to develop modular code and build it.

I'm thinking about a build system for JavaScript now. The site has
many pages and as we refactor the JavaScript I want file dependencies
to be easy to track. Reducing the number of scripts served is a
priority also. Any suggestions from experience on good build process
features?

Thanks,
Peter

 

[dhtmlkitchen]

I'm thinking about a build system for JavaScript now. The site has
many pages and as we refactor the JavaScript I want file dependencies
to be easy to track. Reducing the number of scripts served is a
priority also. Any suggestions from experience on good build process
features?

Thanks,
Peter- Hide quoted text -

- Show quoted text -

It's no simple task! Yahoo does not have an official build process.
Doug mentioned that he is working on it. I probably shouldn't go into
detail anymore than that.

There's an interesting article on ajaxpatterns.org regarding download
on demand javascript. It's definitely not the easiest approach; it's
along the lines of what Dojo recommends.

One idea is to use ANT, if you're a Java shop. You can build a file by
parsing out: an include file, or a page-specific js file that has
require/import function calls (like dojo.require). I was on a project
that did this and it made a huge difference.

Another idea would be to have a custom tag or include. I have never
done this, but doesn't seem any harder than using ANT to do it.

<js:resources>
<js:resource src="com.example.ArrayExtras.js"/>
</js:resources>

would generate:
<script src="everythingCombined.js"></script>

everythingCombined would combine your framework.js file and all the
other js:resources.

Personally, I can't wait 'till ES4 so we can have real imports. It
just makes more sense to bind the behavior in the behavior layer.

Pros, cons? What are your thoughts?

(probably don't even have to ask on here, as everyone seems very
opinionated and vocal anyway!)

Garrett

 

[Peter Michaux]

It's no simple task! Yahoo does not have an official build process.
Doug mentioned that he is working on it. I probably shouldn't go into
detail anymore than that.

I'm guessing you mean Douglas Crockford.

You work at Yahoo! but have a gmail account? I didn't know that
combination was possible.

There's an interesting article on ajaxpatterns.org regarding download
on demand javascript. It's definitely not the easiest approach; it's
along the lines of what Dojo recommends.

I think this on-demand approach encourages a lot of client-server talk
with smaller bits of JavaScript for each request. This means the
fraction of request time dedicated to making the connection is high
compared to the time for actual JavaScript transfer. This also results
in latency when the user clicks something and the JavaScript must
first be downloaded before the action can be performed. If the only
win is faster page loads, it is usually possible to minify, maybe
obfuscate, and gzip code down to the size of a single image file.

There are also implementation issues with on-demand/lazy loading since
either Ajax or script insertion techniques both have reasonably
serious downsides. Code retrieved by Ajax is evaluated with eval()
which will be inside a function (not the global scope) which leads to
code scoping issues. Script insertion works well and is controlled by
headers but it is necessary to monitor the order in which script
elements are added to the page. If two scripts are added at the same
time to the DOM you can't rely on the first script being already
evaluated when the second script is evaluated.

One idea is to use ANT, if you're a Java shop. You can build a file by
parsing out: an include file, or a page-specific js file that has
require/import function calls (like dojo.require). I was on a project
that did this and it made a huge difference.

I'm not exactly sure what you are describing. I think I've been
thinking about something like this as one option. Putting a comment
like this in the actual JavaScript files

/* @require('dependencyOne.js', 'dependencyTwo.js') */

This isn't a freebe either unfortunately. Suppose I have an event and
Ajax libraries used all over my site and then two page specific
JavaScript files foo & bar.

event.js
========
var Event = {...};


ajax.js
=======
var Ajax = {...};


foo.js
======
/* @require('Event') */
var foo = {...};


bar.js
======
/* @require('Event', 'Ajax', 'foo') */
var bar = {...};

What I want when all these files are built is two files. One file
contains all the foundational JavaScript I use on every page of my
site and one file has the page specific code. The foundation file is
cached when the first page of the site is visited. This leads to good
caching.

foundation-20070804085223.js
=============
var Event = {...};
var Ajax = {...};


page-20070804085223.js
======
var foo = {...};
var bar = {...};

Note the dependencies listed in the comments of foo.js and bar.js
don't really help create these compiled files.

The timestamps on the built files are for caching and I threw then in
above for completeness. It's another dimension of the problem.

Another idea would be to have a custom tag or include. I have never
done this, but doesn't seem any harder than using ANT to do it.

<js:resources>
<js:resource src="com.example.ArrayExtras.js"/>
</js:resources>

would generate:
<script src="everythingCombined.js"></script>

everythingCombined would combine your framework.js file and all the
other js:resources.

Personally, I can't wait 'till ES4 so we can have real imports.

It's going to be 8-10 years before we can reasonably rely on ES4 in
the browser. I can't wait either which is why I'm looking for a
solution

It just makes more sense to bind the behavior in the behavior layer.

Pros, cons? What are your thoughts?

I going to think more about how make files work. Yes makefiles take
time to maintain and the dependencies are separate from the source
code but they work well for a very wide set of requirements. This
completely separates the ideas of source and compiled files. This
allows for each source file to have different build rules (something
I'm really interested in lately).

It is important to me that during development that each file request
amounts to running "make" automatically before serving the requested
file. That way I don't have to run make manually after each edit.
During the site's build stage make would run and create the
timestamped files which involves some other less nasty issues then the
file dependency issues.

Definitely (maybe) something along the lines of a makefile. That seems
reasonable and very flexible for so many things.

The sad thing is I have to write this build process in
Perl...Perl...Ugg........ugg.

Peter