@Ian: Thanks a lot for sharing your ideas and code. Have you done any benchmarking for how your Ajax loader performance compares to:
A) loading the scripts normally in the HEAD section; B) loading the scripts 'last' in a 2nd HEAD section at the bottom of the page; C) loading the scripts 'last' AND from a different domain (eg: static.espn.com) so they can download in parallel? I like the concept of Ajax loading, but wonder exactly how much better it is than other, simpler optimization techniques. I also see a potential issue if $(document).ready fires *before* all the JS scripts finish downloading, which seems possible on a small page with many scripts. /Kevin On Feb 9, 10:39 am, IanSym <[email protected]> wrote: > Hi, > > On ESPN.com we load JS in parallel with other page assets (images, > css, etc) by using an Ajax based loader script. This allows us to > load JavaScript in a non-blocking fashion while the rest of the page > loads. This affords us to fire the ready event quicker. We also use > the $.onAvailable/$onContentReady plugin to initialize page components > before the dom finishes loading, giving us even more responsiveness. > > Here's a snippet of the code from our site that pulls in the loader. > (we run a patched jQuery 1.2.6 to fix an IE memory leak with > $.getScript - this is targetted to be fixed in 1.3.2). The loader on > the current site isn't the most optimized as we had to use > document.write for IE until we found the memory leak and we've not > tested a new version as of yet. > > <script src="http://a.espncdn.com/prod/scripts/jquery-1.2.6.1.min.js"; > type="text/javascript" charset="utf-8"></script> > <script src="http://a.espncdn.com/prod/scripts/espn.loader.min. > 200901201835.js" type="text/javascript" charset="utf-8"></script> > <script type="text/javascript" charset="utf-8"> > ESPN.include([ > 'http://a.espncdn.com/prod/scripts/espn.ui.min.200810200925.js', > 'http://a.espncdn.com/prod/scripts/espn.plugins.min.200811131546.js', > 'http://a.espncdn.com/prod/scripts/espn.core.min.200902021843.js', > 'http://a.espncdn.com/prod/scripts/frontpage_scoreboard.min. > 200902011005.js', > 'http://a.espncdn.com/prod/scripts/registration/myEspn.min. > 200902021209.js' > ]); > </script> > > Here's the code from the current loader in development - the usage is > the same as above... > > http://pastie.org/384167 > > Anyway... that was our approach to faster response times. > > --Roger > > On Feb 9, 7:13 am, "[email protected]" <[email protected]> > wrote: > > > > > Good point, Mar. Users will judge a site within a fraction of a > > second. If the page seems unresponsive for that long, it can't fare > > well. > > > Pages can 'seem' to load faster if scripts are put at the bottom due > > to the fact that it prevents progressive rendering (which is a good > > side effect of putting CSS at the top) and parallel downloading. > > Because the http 1.1 spec suggest that a browser will only download 2 > > components at a time, the fewer http request the better. > > > Cheers. > > > On Feb 9, 10:53 am, Már Örlygsson <[email protected]> wrote: > > > > > Putting your js at the bottom of the page is essentially the same as > > > > putting it in jQuery(function() {}), or .ready. The Yslow plugin > > > > doesn't take into account that you are using jQuery and are > > > > implementing the ready event. I have run a couple of tests for the > > > > Actually, YUI has quite an advanced document.ready event model, and > > > YUI developers use it a lot. I'd only assume YSlow not only knows > > > about ready events, but *assumes* you're using them. > > > > As I understand it, "JS at the bottom" is recommended because it > > > allows for faster HTML, CSS and image rendering - making pages *look* > > > faster - which research purports is important for the user experience. > > > > - Combining all javascripts into as few HTTP requests as possible > > > helps. (a lot!) > > > - Employing a lightweight library (yay jQuery!) and slim javascript > > > modules helps. > > > - Using the document.ready event helps. > > > - HTTP caching helps. > > > - Placing javascripts at the bottom helps too. > > > > It's just one of many factors - and probably not the single biggest > > > one - especially if all the others are taken care of. > > > > There are a few tricks available to suppress the "flash of web 1.0 > > > content and ui". > > > One that I perfer, is to load a tiny <script> from the <head> of the > > > page, that injects a <style> tag with CSS rules that hide unwanted > > > elements, and then remove the <style>sheet as soon as all the heavy > > > scripts at the bottom have loaded and executed. > > > > -- > > > Már Örlygsson- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
