Re: [S2] Ajax performance optimisation
Maybe too late, but I found that you have to do the following : - create a directory struts under your Webroot directory - copy all contents from the static directory into this struts directory - copy the entire contents of template directory into this same struts directory, without the template directory itself. This means that the Webroot/struts directory contains the following items : -ajax -archive -CommonFunctions.js -css_xhtml -dojo -inputtransferselect.js -niftycorners -optiontransferselect.js -simple -tabs.css -template -tree.css -validationClient.js -xhtml Now you can upgrade dojo to the most recent version in the 0.4 branch (currently 0.4.3). When you upgrade, make sure to copy the dojo/struts directory under the new dojo directory. bartlebooth Jason Wyatt wrote: I've been trying to speed up the Ajax performance of our application, based on the notes at http://cwiki.apache.org/WW/performance-tuning.html I'm a bit unsure where I should extract the static content to, such as the css and javascript files included by the Ajax theme (shown below): link rel=stylesheet href=/iacd/struts/xhtml/styles.css type=text/css/ script type=text/javascript src=/iacd/struts/dojo/dojo.js/script script type=text/javascript src=/iacd/struts/simple/dojoRequire.js/script script type=text/javascript src=/iacd/struts/ajax/dojoRequire.js/script script type=text/javascript src=/iacd/struts/CommonFunctions.js/script For example, the styles.css file above is stored in the struts2-core-2.0.8.jar under the path /template/xhtml. But if I extract this file to the webroot/template/xhtml, it seems that the link in the code above won't work, so I should instead extract it to webroot/struts/xhtml. Is this understanding correct? Basically I'm wondering how the mapping works between the template folder in the jar file and the struts folders mentioned in the Ajax theme's code. Thanks for any help, Regards Jason - Falun Dafa Truth - Compassion - Forbearance A mind body practice under persecution in China http://www.faluninfo.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Ajax performance optimisation
Jason Wyatt on 27/07/07 08:55, wrote: I've been trying to speed up the Ajax performance of our application, based on the notes at http://cwiki.apache.org/WW/performance-tuning.html I'm a bit unsure where I should extract the static content to, such as the css and javascript files included by the Ajax theme (shown below): link rel=stylesheet href=/iacd/struts/xhtml/styles.css type=text/css/ script type=text/javascript src=/iacd/struts/dojo/dojo.js/script script type=text/javascript src=/iacd/struts/simple/dojoRequire.js/script script type=text/javascript src=/iacd/struts/ajax/dojoRequire.js/script script type=text/javascript src=/iacd/struts/CommonFunctions.js/script For example, the styles.css file above is stored in the struts2-core-2.0.8.jar under the path /template/xhtml. But if I extract this file to the webroot/template/xhtml, it seems that the link in the code above won't work, so I should instead extract it to webroot/struts/xhtml. Is this understanding correct? Basically I'm wondering how the mapping works between the template folder in the jar file and the struts folders mentioned in the Ajax theme's code. Looks like a servlet filter declared in the web.xml would pick up anything with /struts/* and handle it from there but I don't see it mentioned in a casual check of the wiki so it could be some other mechanism. I spent about a week trying to get dojo to perform better the way we were using it, and for the performance we required then, we worked out we couldn't afford any more than a dozen dojo widgets on a page, even with all the dojo performance enhancements recommended by dojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Ajax performance optimisation
Hi, we also had the similar problem, we had a s1.x application with dojo and we did all the performance enhancements that was recommended by dojo, but we could not achive what we want and our application was running in https mode. it add more performance problem to the application. Thanks, Nuwan Adam Hardy wrote: Jason Wyatt on 27/07/07 08:55, wrote: I've been trying to speed up the Ajax performance of our application, based on the notes at http://cwiki.apache.org/WW/performance-tuning.html I'm a bit unsure where I should extract the static content to, such as the css and javascript files included by the Ajax theme (shown below): link rel=stylesheet href=/iacd/struts/xhtml/styles.css type=text/css/ script type=text/javascript src=/iacd/struts/dojo/dojo.js/script script type=text/javascript src=/iacd/struts/simple/dojoRequire.js/script script type=text/javascript src=/iacd/struts/ajax/dojoRequire.js/script script type=text/javascript src=/iacd/struts/CommonFunctions.js/script For example, the styles.css file above is stored in the struts2-core-2.0.8.jar under the path /template/xhtml. But if I extract this file to the webroot/template/xhtml, it seems that the link in the code above won't work, so I should instead extract it to webroot/struts/xhtml. Is this understanding correct? Basically I'm wondering how the mapping works between the template folder in the jar file and the struts folders mentioned in the Ajax theme's code. Looks like a servlet filter declared in the web.xml would pick up anything with /struts/* and handle it from there but I don't see it mentioned in a casual check of the wiki so it could be some other mechanism. I spent about a week trying to get dojo to perform better the way we were using it, and for the performance we required then, we worked out we couldn't afford any more than a dozen dojo widgets on a page, even with all the dojo performance enhancements recommended by dojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Ajax performance optimisation
I have a very complex app using Dojo that just went live a few weeks ago (although *not* using S2), and this past week we got a 70+% performance improvement out of it. We did three things Dojo-related. First, we used a custom build (previously we just let Dojo import whatever it needed on the fly). I know this is a primary suggestion the Dojo team makes, so I assume you've done that already. Second, all the Dojo resources, all the .js, .css and image files, were moved onto the web server. Third, we set expires headers for all these resources to one hour on Apache. None of that is rocket science, but it made an absolutely amazing difference. We're under SSL as well, and our performance right now is on par with what a developer sees running it locally without SSL. It's absolutely stunning. We actually moved *all* our static resources out to the web server (we use other libraries like ActiveWidgets, WiseBlocks and have a ton of .js that makes up the app itself). We also made some other architectural changes, so the improvement we saw isn't strictly what we did with Dojo. But, myself and another senior guy spent all week measuring and benchmarking and testing and I can say for sure that the biggest improvement was in fact the Dojo changes. hth, Frank Nuwan Chandrasoma wrote: Hi, we also had the similar problem, we had a s1.x application with dojo and we did all the performance enhancements that was recommended by dojo, but we could not achive what we want and our application was running in https mode. it add more performance problem to the application. Thanks, Nuwan Adam Hardy wrote: Jason Wyatt on 27/07/07 08:55, wrote: I've been trying to speed up the Ajax performance of our application, based on the notes at http://cwiki.apache.org/WW/performance-tuning.html I'm a bit unsure where I should extract the static content to, such as the css and javascript files included by the Ajax theme (shown below): link rel=stylesheet href=/iacd/struts/xhtml/styles.css type=text/css/ script type=text/javascript src=/iacd/struts/dojo/dojo.js/script script type=text/javascript src=/iacd/struts/simple/dojoRequire.js/script script type=text/javascript src=/iacd/struts/ajax/dojoRequire.js/script script type=text/javascript src=/iacd/struts/CommonFunctions.js/script For example, the styles.css file above is stored in the struts2-core-2.0.8.jar under the path /template/xhtml. But if I extract this file to the webroot/template/xhtml, it seems that the link in the code above won't work, so I should instead extract it to webroot/struts/xhtml. Is this understanding correct? Basically I'm wondering how the mapping works between the template folder in the jar file and the struts folders mentioned in the Ajax theme's code. Looks like a servlet filter declared in the web.xml would pick up anything with /struts/* and handle it from there but I don't see it mentioned in a casual check of the wiki so it could be some other mechanism. I spent about a week trying to get dojo to perform better the way we were using it, and for the performance we required then, we worked out we couldn't afford any more than a dozen dojo widgets on a page, even with all the dojo performance enhancements recommended by dojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Ajax performance optimisation
Hi Frank- My apologies for jumping in the middle of a thread -could you elaborate on what you used for a 'custom build'? -which webserver are you implementing? -where you able to collect metrics for scenarios other than expire headers of 1 hour..perhaps 2 hours? Kudos for attaining astounding 70% performance increase!!! Thanks, M-- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: Frank W. Zammetti [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Saturday, July 28, 2007 10:17 AM Subject: Re: [S2] Ajax performance optimisation I have a very complex app using Dojo that just went live a few weeks ago (although *not* using S2), and this past week we got a 70+% performance improvement out of it. We did three things Dojo-related. First, we used a custom build (previously we just let Dojo import whatever it needed on the fly). I know this is a primary suggestion the Dojo team makes, so I assume you've done that already. Second, all the Dojo resources, all the .js, .css and image files, were moved onto the web server. Third, we set expires headers for all these resources to one hour on Apache. None of that is rocket science, but it made an absolutely amazing difference. We're under SSL as well, and our performance right now is on par with what a developer sees running it locally without SSL. It's absolutely stunning. We actually moved *all* our static resources out to the web server (we use other libraries like ActiveWidgets, WiseBlocks and have a ton of .js that makes up the app itself). We also made some other architectural changes, so the improvement we saw isn't strictly what we did with Dojo. But, myself and another senior guy spent all week measuring and benchmarking and testing and I can say for sure that the biggest improvement was in fact the Dojo changes. hth, Frank Nuwan Chandrasoma wrote: Hi, we also had the similar problem, we had a s1.x application with dojo and we did all the performance enhancements that was recommended by dojo, but we could not achive what we want and our application was running in https mode. it add more performance problem to the application. Thanks, Nuwan Adam Hardy wrote: Jason Wyatt on 27/07/07 08:55, wrote: I've been trying to speed up the Ajax performance of our application, based on the notes at http://cwiki.apache.org/WW/performance-tuning.html I'm a bit unsure where I should extract the static content to, such as the css and javascript files included by the Ajax theme (shown below): link rel=stylesheet href=/iacd/struts/xhtml/styles.css type=text/css/ script type=text/javascript src=/iacd/struts/dojo/dojo.js/script script type=text/javascript src=/iacd/struts/simple/dojoRequire.js/script script type=text/javascript src=/iacd/struts/ajax/dojoRequire.js/script script type=text/javascript src=/iacd/struts/CommonFunctions.js/script For example, the styles.css file above is stored in the struts2-core-2.0.8.jar under the path /template/xhtml. But if I extract this file to the webroot/template/xhtml, it seems that the link in the code above won't work, so I should instead extract it to webroot/struts/xhtml. Is this understanding correct? Basically I'm wondering how the mapping works between the template folder in the jar file and the struts folders mentioned in the Ajax theme's code. Looks like a servlet filter declared in the web.xml would pick up anything with /struts/* and handle it from there but I don't see it mentioned in a casual check of the wiki so it could be some other mechanism. I spent about a week trying to get dojo to perform better the way we were using it, and for the performance we required then, we worked out we couldn't afford any more than a dozen dojo widgets on a page, even with all the dojo performance enhancements recommended by dojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent
Re: [S2] Ajax performance optimisation
Hi Frank, First of all thanks for these tips.., we did the custom dojo build and parseWidget tag setting also. but we havent done the 2nd and 3rd tips you have given here., i have a small doubt when it comes to moving static resource to the web server. will there be any problem when it comes to having http and https content together? i don't have much experience when it comes to web servers like apache Thanks, Nuwan Frank W. Zammetti wrote: I have a very complex app using Dojo that just went live a few weeks ago (although *not* using S2), and this past week we got a 70+% performance improvement out of it. We did three things Dojo-related. First, we used a custom build (previously we just let Dojo import whatever it needed on the fly). I know this is a primary suggestion the Dojo team makes, so I assume you've done that already. Second, all the Dojo resources, all the .js, .css and image files, were moved onto the web server. Third, we set expires headers for all these resources to one hour on Apache. None of that is rocket science, but it made an absolutely amazing difference. We're under SSL as well, and our performance right now is on par with what a developer sees running it locally without SSL. It's absolutely stunning. We actually moved *all* our static resources out to the web server (we use other libraries like ActiveWidgets, WiseBlocks and have a ton of .js that makes up the app itself). We also made some other architectural changes, so the improvement we saw isn't strictly what we did with Dojo. But, myself and another senior guy spent all week measuring and benchmarking and testing and I can say for sure that the biggest improvement was in fact the Dojo changes. hth, Frank Nuwan Chandrasoma wrote: Hi, we also had the similar problem, we had a s1.x application with dojo and we did all the performance enhancements that was recommended by dojo, but we could not achive what we want and our application was running in https mode. it add more performance problem to the application. Thanks, Nuwan Adam Hardy wrote: Jason Wyatt on 27/07/07 08:55, wrote: I've been trying to speed up the Ajax performance of our application, based on the notes at http://cwiki.apache.org/WW/performance-tuning.html I'm a bit unsure where I should extract the static content to, such as the css and javascript files included by the Ajax theme (shown below): link rel=stylesheet href=/iacd/struts/xhtml/styles.css type=text/css/ script type=text/javascript src=/iacd/struts/dojo/dojo.js/script script type=text/javascript src=/iacd/struts/simple/dojoRequire.js/script script type=text/javascript src=/iacd/struts/ajax/dojoRequire.js/script script type=text/javascript src=/iacd/struts/CommonFunctions.js/script For example, the styles.css file above is stored in the struts2-core-2.0.8.jar under the path /template/xhtml. But if I extract this file to the webroot/template/xhtml, it seems that the link in the code above won't work, so I should instead extract it to webroot/struts/xhtml. Is this understanding correct? Basically I'm wondering how the mapping works between the template folder in the jar file and the struts folders mentioned in the Ajax theme's code. Looks like a servlet filter declared in the web.xml would pick up anything with /struts/* and handle it from there but I don't see it mentioned in a casual check of the wiki so it could be some other mechanism. I spent about a week trying to get dojo to perform better the way we were using it, and for the performance we required then, we worked out we couldn't afford any more than a dozen dojo widgets on a page, even with all the dojo performance enhancements recommended by dojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Ajax performance optimisation
Nuwan Chandrasoma wrote: Hi Frank, First of all thanks for these tips.., we did the custom dojo build For anyone reading, this is an especially important tip if your app is being access on a WAN or public Internet. Our app is a backoffice app, but we have a lot of people coming in over VPN to use it, and that's where we saw a large hit by not using the custom build option because Dojo is very chatty in terms of loading its resources otherwise. ... and parseWidget tag setting also. Also a big hitter. We had widget parsing turned off already, but before we did some months back you could definitely see the hit you take for that. Remember that Dojo gives you the ability to parse the entire DOM tree, or just specific portions of it, so if your using markup-based creation of widgets, I definitely suggest you look at targeting the widget parsing as much as possible. ...but we havent done the 2nd and 3rd tips you have given here., i have a small doubt when it comes to moving static resource to the web server. will there be any problem when it comes to having http and https content together? i don't have much experience when it comes to web servers like apache Interesting question, and I'm not sure... I'd suspect IE especially might be a problem because it's famous for the do you wish to access this unsecured content from a secure location? dialog, which I think you can't get rid of no matter what you do. I'm not sure here, might be worth some time to experiment and see what happens. Thanks, Nuwan Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Ajax performance optimisation
Martin Gainty wrote: Hi Frank- My apologies for jumping in the middle of a thread No need to apologize, I did the same thing! LOL -could you elaborate on what you used for a 'custom build'? Yes... Dojo supports the ability to create a custom build, where you get a dojo.js file out that contains only the code you need. The Dojo wiki details this, but it's little more than creating a profile.js file, which tells the build process what to include, and then running an Ant script. I have to say that it took me a while to get it to work, I had various problems along the way, but it ultimately works pretty much as described in their documentation. My custom build by the way includes the io functionality, and the menu, button, calendar, tab and floatpane widgets, plus whatever packages (fx, core, etc.) these things require. -which webserver are you implementing? Apache, in front of WebSphere... I'm afraid I can't go into much more detail than that as we're in a hosted environment, so I'm not in charge of the configurations. -where you able to collect metrics for scenarios other than expire headers of 1 hour..perhaps 2 hours? No, we debated various times but settled on one hour because that seemed a reasonable period of time to account for JS changes (our own app JS really)... we figured images weren't terribly important if something changed, we could deal with a bit of ugliness for an hour :) but JS changes would obviously break stuff. Kudos for attaining astounding 70% performance increase!!! Thanks :) The early days of last week were really rough, trying to figure out where we were truly losing time, but the last two days were very rewarding indeed. Thanks, M-- Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Ajax performance optimisation
Frank W. Zammetti on 28/07/07 16:10, wrote: Martin Gainty wrote: -where you able to collect metrics for scenarios other than expire headers of 1 hour..perhaps 2 hours? No, we debated various times but settled on one hour because that seemed a reasonable period of time to account for JS changes (our own app JS really)... we figured images weren't terribly important if something changed, we could deal with a bit of ugliness for an hour :) but JS changes would obviously break stuff. Interesting approach. Is the first-time load actually long enough to consider putting in a message on the browser window saying 'Please wait for a moment while application initialises...' or similar? Or is that initial load time quick enough anyway? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Ajax performance optimisation
In our case, it's not the initial load that was killing us... well, it *was* a little too long (and we have a very nice Please Wait with spinning gears and such during that period)... the problem is the underlying requirements for the application. Let me try and give a brief background (although you've been around here long enough and seen my posts to know I can't say *anything* briefly!) The app is a back-office replacement for a number of different apps... things like CRM, account creation, workflow, imaging system, etc. Each of these is sort of a separate module in the app. Each module further has a left and right-hand sides, the left-hand side has a variable number of tabs on it, each loaded individually, and the right-hand side typically has an image viewing applet in it, although sometimes has other things like search results, more data entry forms, etc. The one requirement that's really been tough is that each of these modules the user needs to be able to flip between at any time with no real delay (at least no delay after the first time they load the module). So, a typical use case might be creating a new account in the new account module, and then being able to flip to the image view module to see the image of the scanned documentation for the new account application. The way we did this, the only way we could to really meet the requirements I think, is that we have a bunch of common JS that loads up-front, which basically represents the overarching client-side framework. Then, each module is in an iFrame, but within each there's a ton of stuff that has to get loaded, some of it duplicate portions of the framework (although that's been minimized of course), and including Dojo in each one. For the most part, once a module is loaded it doesn't fully get loaded again, we just flip one iFrame visible while the others are hidden, that sort of thing. But there *are* a few instances where a module has to get reloaded. Now, here's the part that really spurned the need to improve performance... we have an existing VB-based imaging application that we're not ready to move off of completely... this imaging app has the full suite of hooks into the workflow, the long and short of it is that from the VB app, a user clicks a button when they select a work item from a queue, which launches our web app. So, the initial load of the web app is maybe 5-7 seconds, not a big deal. Then to load the module that automatically gets started in that case takes about 8-10 seconds. Then it has to load an image in an applet, which is another few seconds. All in all it's roughly 20 seconds from fat-client to webapp loaded. But, before the mods this past week, it was more like 45-50 seconds, sometimes more (I think we actually managed to get it closer to 10-15 seconds overall on Friday, getting us to around that 70% improvement I mentioned, give or take a bit). You actually see that please wait display when the module is loading too, and from fat-client to webapp it's actually showing the whole time. Before the mods, you can see why Dojo was a problem: it wasn't just loading once, it was loading multiple times! And because of the fundamental architecture of the app, there wasn't much choice in the matter (I've toyed with just loading it in the parent frame, but that doesn't seem possible since the iFrames need a lot of it, and you start getting into tons of scoping issues). I should also point out that one of the other changes I made that had a big impact was not using Dojo buttons any longer... I basically built a new button widget and wrapped it in a taglib. The problem there was that each of those tabs I mentioned gets loaded via AJAX, and then any script blocks in it is executed. When we disabled the Dojo widget parsing, we lost the ability to use markup to generate Dojo buttons, so I created a very thin taglib wrapper that spit out a script block to programmatically generate the Dojo button. This, it turns out, executes a lot faster than the widget parsing (I should also mention we're using Dojo 0.3.1 because it would be a major hassle to upgrade now)... the problem, which I'd bet you can guess, is that if you have a tab with numerous buttons, which we did in some cases, executing all that Javascript and manipulating the DOM (creating the Dojo buttons) wound up being as slow as using widget parsing, maybe even slower. So now, the button widget and taglib I created doesn't spit out Javascript, the buttons are a lot simpler, and don't need to be created programmatically. This gained us 3-5 seconds alone. Ok, see, I'm genetically incapable of giving a short answer to anything :) To answer your question, the initial load *is* long enough to warrant a please wait message, and we have one, and actually have from the start :) Frank Adam Hardy wrote: Frank W. Zammetti on 28/07/07 16:10, wrote: Martin Gainty wrote: -where you able
Re: [S2] Ajax performance optimisation
Sounds like a whole portal - quite a broad scope for a webapp. I guess you are using iframes so that you can flow each iframe thro further requests without losing the state in the other iframes or the main page. The app that I'm working on has several different tabs, but all within a single page and the load time of the HTML and javascript into the browser was minimal, but it was simply the Dojo processing, the browser dom engine processing and processing, all that js to interpret. That was with all the optimisations too. We made the initial mistake of using the Dojo drop-down title bar/box on rows in a table where typically 100 rows would come back! Frank W. Zammetti on 28/07/07 20:47, wrote: In our case, it's not the initial load that was killing us... well, it *was* a little too long (and we have a very nice Please Wait with spinning gears and such during that period)... the problem is the underlying requirements for the application. Let me try and give a brief background (although you've been around here long enough and seen my posts to know I can't say *anything* briefly!) The app is a back-office replacement for a number of different apps... things like CRM, account creation, workflow, imaging system, etc. Each of these is sort of a separate module in the app. Each module further has a left and right-hand sides, the left-hand side has a variable number of tabs on it, each loaded individually, and the right-hand side typically has an image viewing applet in it, although sometimes has other things like search results, more data entry forms, etc. The one requirement that's really been tough is that each of these modules the user needs to be able to flip between at any time with no real delay (at least no delay after the first time they load the module). So, a typical use case might be creating a new account in the new account module, and then being able to flip to the image view module to see the image of the scanned documentation for the new account application. The way we did this, the only way we could to really meet the requirements I think, is that we have a bunch of common JS that loads up-front, which basically represents the overarching client-side framework. Then, each module is in an iFrame, but within each there's a ton of stuff that has to get loaded, some of it duplicate portions of the framework (although that's been minimized of course), and including Dojo in each one. For the most part, once a module is loaded it doesn't fully get loaded again, we just flip one iFrame visible while the others are hidden, that sort of thing. But there *are* a few instances where a module has to get reloaded. Now, here's the part that really spurned the need to improve performance... we have an existing VB-based imaging application that we're not ready to move off of completely... this imaging app has the full suite of hooks into the workflow, the long and short of it is that from the VB app, a user clicks a button when they select a work item from a queue, which launches our web app. So, the initial load of the web app is maybe 5-7 seconds, not a big deal. Then to load the module that automatically gets started in that case takes about 8-10 seconds. Then it has to load an image in an applet, which is another few seconds. All in all it's roughly 20 seconds from fat-client to webapp loaded. But, before the mods this past week, it was more like 45-50 seconds, sometimes more (I think we actually managed to get it closer to 10-15 seconds overall on Friday, getting us to around that 70% improvement I mentioned, give or take a bit). You actually see that please wait display when the module is loading too, and from fat-client to webapp it's actually showing the whole time. Before the mods, you can see why Dojo was a problem: it wasn't just loading once, it was loading multiple times! And because of the fundamental architecture of the app, there wasn't much choice in the matter (I've toyed with just loading it in the parent frame, but that doesn't seem possible since the iFrames need a lot of it, and you start getting into tons of scoping issues). I should also point out that one of the other changes I made that had a big impact was not using Dojo buttons any longer... I basically built a new button widget and wrapped it in a taglib. The problem there was that each of those tabs I mentioned gets loaded via AJAX, and then any script blocks in it is executed. When we disabled the Dojo widget parsing, we lost the ability to use markup to generate Dojo buttons, so I created a very thin taglib wrapper that spit out a script block to programmatically generate the Dojo button. This, it turns out, executes a lot faster than the widget parsing (I should also mention we're using Dojo 0.3.1 because it would be a major hassle to upgrade now)... the problem, which I'd bet you can guess, is that if you have a tab with numerous
