Re: Dynamic loading of javascript files into web pages

Conrad Lender wrote:
On 25/06/09 21:00, Peter Michaux wrote:
On Jun 25, 11:46 am, Jeremy J Starcher <r3...@xxxxxxxxx> wrote:
Load four scripts, they load one after another while blocking all other
elements on the page from loading at the same time. By making them
dynamically declared script elements (either using document.write or
dynamic SCRIPT elements), it allows concurrent loading with other
elements.
I wish Randy Webb was around right now. I've cc'ed him on this
message. He is/was a fan of dynamic script tag insertion at least for
some purposes.

I suppose that was tongue in cheek, but there are in fact techniques
which can help improve the time it takes to load and render a
script-heavy page. Steve Souders specializes in this area, and his books
about high performance web sites are definitely worth a read. His second
book has only just been released, and I haven't read it yet, but he has
been very generous about publishing pre-release chapters on his blog.

http://www.stevesouders.com/


Steve Souders advocates practices which require good judgment and design to avoid maintenance issues. The performance tips and tricks are great, but can be rather harmful if the implementation of the performance tip is poor. An application that is poorly engineered is likely to have performance problems and the developers who created the poor implementation are likely to have a poor implementation of the tips and tricks, as well.

Performance tends to be a problem when there is a lot of javascript. The situation of too much javascript is often caused by using 1+ libraries that have very general functionality, consisting of largely of abstractions created to solve a myriad of potential problems. This situation is common for teams who try to implement a lot of features, don't know how, and try to "just get it done". I have seen this a lot.

It is easy to do lots of stuff half-assed. In the long run, it will just cost more (time and money). The code matters!

So what should a who gets themselves in this situation do?

There is no "speed" button or magic solution. Hiring a performance expert won't change that; it is a cop out that avoids the blame game.

A more practical and proactive solution is to look again at the problem and look to see if the code effectively and clearly solves the requirement problem. Continual refactoring, buddy checks (code review) and pair can help.

Application design and architecture is where performance affected most and it is most effective when it is simple enough to communicate it. Communicating the design to others prevents the design from becoming so complicated that it cannot be communicated effectively, which can help keep the design simple.

Steve doesn't talk about design or process much From what Steve Sounders has stated, I have not heard good design advice.

For example, Steve advocates combining scripts together. This will make the pages load faster by reducing the number of http requests. The technique works but it has to be done right. Doing it right requires an explanation of how. I attended a presentation a few years back where an audience member said they were combining the files together by hand and wanted to ask for advice on that. Now, copy-pasting is a tedious and error-prone process, which was my knee-jerk response, however I recall Steve suggesting the audience member to continue doing that, which appalled me.

Another example is the advocacy of using fallback content in a script tag by John Resig. Steve Souders ignored valid criticism by TNO, myself, among others.

http://ejohn.org/blog/degrading-script-tags#postcomment

Note: To view the comments on ejohn.org, javascript must be enabled. (grrr).

Steve and John talked about performance in a later presentation where John discussed the DEFER attribute in a way that are incorrect. Nobody corrected him. Not even Steve. In a later presentation, Steve Souders congratulated John Resign on the presentation.

Although the mistake was of John Resig, if Steve Souders is a performance expert, he ought to have made a correction to the explanation of how DEFER works. That was discussed here:

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/df4f80404e12da8f/53a3903684b6f7b9?#53a3903684b6f7b9

information in Souders's books and on his blog; a good starting point
would be

http://www.stevesouders.com/blog/2009/04/23/even-faster-web-sites/


No knowledge is bad, however, architecture is going to affect performance most of all.

You don't have to embrace any of the "script injection" techniques he
offers, make your own judgement instead.

http://code.google.com/speed/page-speed/faq.html#speed

| Some of Page Speed's recommendations seem to go against certain design
| and development practices. Does Google think that only speed is
| important?
|
| Since Page Speed is a performance optimization tool, its
| recommendations are biased in favor of speed. However, we recognize
| that web development is complex, and our suggestions might be
| restrictive for an individual web site. You have to consider the
| tradeoffs for your own application: some of Page Speed's
| recommendations take substantial effort to implement, so you need to
| evaluate the cost of making changes vs. the benefit the rule would
| have on your page. Our goal is simply to point out the issues that you
| should consider fixing.

The analysis about where to put
<style>, <script>, <link> tags, and when different browsers will block
when they encounter such an element is interesting enough by itself.



Splitting the initial payload is something Steve hyped but the solutions he provides miss the point. The problem is that looking at the initial payload should be the first step. AISB, look at the problem, then at the code, and analyze.

It would be like going camping and saying, geez, we have to optimize for space here, because all this crap doesn't fit in my car. Instead, of saying "all this stuff doesn't fit in my car" and then looking at what we need and what "all this stuff" is. Instead of jumping to optimizing how the stuff is packed, it makes sense to see what we need and then organize that in a sensible way (food in the cooler, tent on the bottom) and just leave all that other stuff behind (hair spray, etc). YAGNI!

YAGNI YAGNI YAGNI!

I read Steve's first a few years ago and, at the time, thought it was worth including in the FAQ. If a review of his second book is desired, then they can send me a copy.

He's also the author of YSlow, which Jeremy mentioned before.

Right. And now he works at Google and they have Page Speed, which I have just installed.

I think YSlow and maybe Page Speed ought to be mentioned in the FAQ, but not under "how to get my browser to report errors". That entry needs to be split up a bit, possibly to explain:

* Common errors like "Operation aborted", "x is not a function", etc.
* How to turn on error reporting
* Performance tools
* IDEs



- Conrad
Psst - sent you mail response. LMK :-)

Garrett

[1]http://code.google.com/speed/page-speed/docs/rules_intro.html
[2]http://oreilly.com/catalog/9780596522308/
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
.

Relevant Pages

  • Re: Dynamic loading of javascript files into web pages
    ... It should be recommended against and the section on "John Resig's degrading script tags", which Steve calls "really really awesome", serves as a fine example of why. ... There's no browser that works this way to like ... Utilizing proprietary extensions is one thing, but expecting every browser to go against the spec is a very *unsafe* design decision. ...
    (comp.lang.javascript)
  • Re: Hyperlinks
    ... http://www.snipesfamily.net/index_files/DAVE.htm The issue is that Publisher ... the design checker tool will find some of these issues. ... I am betting that you are using a script on your home page that you are not ... I have seen a lot of Publisher produced sites that load ...
    (microsoft.public.publisher.webdesign)
  • Re: notice and warning
    ... You expect some piece of data from a post in your script, ... prefer $_REQUEST over $_POST. ... the different meanings the input should have based on how it arrives. ... that's bad design. ...
    (comp.lang.php)
  • Re: Holiday Table Design - Stevie is really pimping
    ... "Steve" wrote in message ... I would like to offer to design and populate a holiday table for you. ... Stevie is not one of them, but he is the only one who just does not get the idea of "FREE" support. ... After a landscape version is ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Automate Access table actions based on Filesystem resources? - stevie the pimp is back
    ... "Steve" wrote in message ... It will take a correctly designed set of tables in the database and a fair amount of VBA programming. ... After a landscape version is ... I next need to design a portrait version. ...
    (microsoft.public.access.gettingstarted)