[Dojo-interest] Measuring performance
jackett_dad at yahoo.com
Tue Jun 29 14:59:52 EDT 2010
I'm definitely interested. Please pass along what you have.
From: Rob Weiss <j105.rob at gmail.com>
To: dojo-interest at mail.dojotoolkit.org
Sent: Tue, June 29, 2010 11:32:33 AM
Subject: Re: [Dojo-interest] Measuring performance
@Scott - I have a Client Side MVC pattern that does load on demand and it has cut my widget loading time by 2/3. Initially I was loading all of my widgets at startup, which killed my performance. It utilizes pub/sub with target nodes to place widgets. It was intially based on some idea I got from the web, but expanded. I needed a plug and play system for my client and this was the easiest way to do it. Let me know if you are interested in the code. I plan to publish it out to the community once it is more "solid".
On Tue, Jun 29, 2010 at 11:20 AM, Scott <jackett_dad at yahoo.com> wrote:
>Thanks for the suggestions. I'll reply to your points individually:
> 1. I'm already using a dojo build, and I totally agree that for performance this is always the first step.
> 2. I need to layer my application as you suggest to get the initial page showing immediately. Show a loading message in the areas that are not initialized. Some of my widgets are initializing themselves before being displayed, and that needs to be addressed.
> 3. I'll try turning off the parseOnLoad flag, which may take care of the delayed-initialization issue by itself.
> 4. I've done quite a bit of reading after following the trail you started with Steve Souders.
> 5. Fiddler rocks. Thanks for the tip.
> 6. I've tried several different page analysis tools, but my page isn't currently available through a publically available web address, so webpagetest.org won't work for me.
> 1. Delay parsing as you suggested of my widgets
> 2. Reduce the DOM node count. I'll probably put portions of the page into a ContentPane that is destroyed when hidden and created when shown. I'm not sure on the benefit of this, but I suspect I'll get a touch more of a wait time displaying it every time, but a huge pickup in other dom related activity as the hidden portions will not enter into browser calculations of sizing and positioning.
> 3. Create loading panes that get replaced by their functional counterparts once loaded and ready for use.
> 4. Create layers that serve the application in different states of loading.
>I think that is a good start.
>Thanks for your input.
From: grouphoot <druspini at gmail.com>
>To: dojo-interest at mail.dojotoolkit.org
>Sent: Tue, June 22, 2010 5:01:06 PM
>Subject: Re: [Dojo-interest] Measuring performance
>I've done quite a bit of optimization for AOL Webmail, which is also a large
>dojo app. Here are some tips:
>1. You MUST do a custom build. It's fine for local development but for
>production get the build going.
>2. If your app is large you'll want to do JS layers, so that you only d/l
>the JS you need to get the app running, then lazy load (or delay load) other
>3. If you have a lot of widgets that may not be visible at startup set
>parseOnLoad to false, and then manually parse the widgets needed to page
>4. Follow all the other common web performance guidelines (look at all the
>stuff on YUI performance and Steve Souders for guidance)
>5. Use Fiddler for seeing how many and how long your requests are.
>6. Use webpagetest.org to run time to domnode tests on your pages.
>Ping me for more info if any of these steps need more detail.
>View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Measuring-performance-tp915236p915313.html
>Sent from the Dojo Toolkit mailing list archive at Nabble.com.
>Dojo-interest at mail.dojotoolkit.org
>Dojo-interest at mail.dojotoolkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dojo-interest