Moreover: “Inline scripts block rendering, just like external scripts, but are worse. External scripts only block the rendering of elements below them in the page. Inline scripts block the rendering of everything in the page.” [1]

I also think that browsers don’t appreciate bunch of meaningless code inside the page, for you may not catch errors, but they will still try to parse and execute it over and over again.

You can put your inline scripts into js files, that are included at the end of the page by some server side logic depending on the request url.

Or it is not that hard to write code that deals with HTML elements by checking if they are actually there. So you can make the whole thing external and enjoy the advantages of caching.

Also, during loading of the HTML lot of things can happen. Event listeners can go mad, users can cause problems that you may not be prepared for. Silencing error handler is a very very bad practice.

No offense, using this technique is one thing, but encouraging others to use it as well is just plain awful.

The best tweaking is no tweaking.

[1] http://www.stevesouders.com/blog/2009/05/06/positioning-inline-scripts/

and the problem I tried to solve was having put JS dependancies at the bottom of the page but JS functions still called inline. Ideally, I would have made a big page manager waiting for the body.onload before running the functions, but that’s not the way my site’s framework works

for the new async ga.js the calling of the methods (say _trackPageview and _setAccount) are defered, until the full file is there. Yes it’s loaded in a non-obstrusive way, but the innovation of GA was that you can call all of the GA methods without the JS dependancy being actually here.

FB solves the problem of calling a JS action that is defined in a file that is still not arrived by having a generic listener, that will extract info from the markup to know what to do and get via XHR the JS+HTML (if needed) generated on the server-side.

both solutions were requiring more changes than I wanted to, and the one I finally found is perfectly maintainable

In my technique, the muting of the JS errors just lasts the time of loading the HTML, to prevent inline JS call to warn the user, then I re-enable the default one. The functionality of the error handling is preserved.

Anyaways, errata: “In fact it is supposed to be put in the {head}[1] whereas we were told to place the old one right before the tag {/body}.[2]“

In fact it is supposed to be put in the [1] whereas we were told to place the old one right before the tag.[2]

So it is less deferred now, than it was before. The reason it has changed is that now you can place it in the head without worrying about other elements to be delayed as a consequence. Also, you get more accurate statistics because there are less things that may delay or block your tracking (as this article points out).

Anyway, shutting down error handling is not one of those so-called “best practices”.

If you want to solve it more elegantly you may want to check out Peter Michaux article about after-DOM-load execution. [3]

For basic things, Facebook’s way is enough. But what they do is they use a global event handler for all the events on the page, so there is no need to attach them inline or after the onload. Thus, the functionality of elements are handled in one place instead of tons of small event handlers. It scales nicely if you ask me. :) [4]

There are also some nice techniques about deferred execution on this blog. [5]

Finally, tweaking is always the worst thing to do, rewriting or refactoring code can be costly in a short term, but with some hours of work now you can save weeks of confusion later. Especially if you are working in a team.

[1] http://code.google.com/apis/analytics/docs/tracking/asyncTracking.html

[2] http://code.google.com/apis/analytics/docs/tracking/gaTrackingOverview.html

[3] http://peter.michaux.ca/articles/the-window-onload-problem-really-solved

[4] http://www.slideshare.net/makinde/javascript-primer

[5] http://www.stevesouders.com/blog/2009/12/07/downloading-javascript-as-strings/

- save the onerror then mute the JS errors on the page
- display page, including inline JS calls
- put back the default JS error handler
- include the JS
- list the of the page, eval them

more code and graphics here (post in french, sorry)
http://jpv.typepad.com/blog/2010/05/performances-web-put-scripts-at-the-bottom-oui-mais-comment-.html