No announcement yet.
  • Filter
  • Time
Clear All
new posts

    SmartGWT download speed

    I have created a small application, but have now run into a major problem.

    To load the application, the browser needs to download about 3MB of data, which I think is a bit much for the few components I am using.

    Is there a way to decrease the download size?
    Can I have a loading screen (I noticed it is possible in the plain SmartClient library, but how to I do this in the GWT version?)

    btw, the application is at

    Thanks a lot,

    The first thing I would do is make sure the content is getting compressed prior to sending. A basic gzip servlet filter is all you need.


      Nice app.
      Using gzip and expires header should reduce the load on the server. Assuming you are using apache webserver you can configure these directives.

      The loading screen is possible. Have a look at the showcase example.

          <title>SmartGWT Showcase</title>
          <!--CSS for loading message at application Startup-->
          <style type="text/css">
              body { overflow:hidden }
              #loading {
                  border: 1px solid #ccc;
                  position: absolute;
                  left: 45%;
                  top: 40%;
                  padding: 2px;
                  z-index: 20001;
                  height: auto;
              #loading a {
                  color: #225588;
              #loading .loadingIndicator {
                  background: white;
                  font: bold 13px tahoma, arial, helvetica;
                  padding: 10px;
                  margin: 0;
                  height: auto;
                  color: #444;
              #loadingMsg {
                  font: normal 10px arial, tahoma, sans-serif;
          <link rel="stylesheet" href="Showcase.css">
          <link rel="stylesheet" href="css/CssStylesSample.css">
      <iframe id="__gwt_historyFrame" style="width:0;height:0;border:0"></iframe>
      <!--add loading indicator while the app is being loaded-->
      <div id="loadingWrapper">
      <div id="loading">
          <div class="loadingIndicator">
              <!--<img src="images/pieces/48/cube_green.gif" width="32" height="32" style="margin-right:8px;float:left;vertical-align:top;"/>SmartGWT<br/>-->
              <img src="images/loading.gif" width="32" height="32" style="margin-right:8px;float:left;vertical-align:top;"/>SmartGWT<br/>
              <span id="loadingMsg">Loading styles and images...</span></div>
          <script>var isomorphicDir = "js/sc/"</script>
      <script type="text/javascript">document.getElementById('loadingMsg').innerHTML = 'Loading Core API...';</script>
      <!--include the SC Core API-->
      <script src=js/sc/modules/ISC_Core.js?isc_version=7.0beta.js></script>
      <!--include SmartClient -->
      <script type="text/javascript">document.getElementById('loadingMsg').innerHTML = 'Loading UI Components...';</script>
      <script src=js/sc/modules/ISC_Foundation.js?isc_version=7.0beta.js></script>
      <script src=js/sc/modules/ISC_Containers.js?isc_version=7.0beta.js></script>
      <script src=js/sc/modules/ISC_Grids.js?isc_version=7.0beta.js></script>
      <script src=js/sc/modules/ISC_Forms.js?isc_version=7.0beta.js></script>
      <script src=js/sc/modules/ISC_RichTextEditor.js?isc_version=7.0beta.js></script>
      <script src=js/sc/modules/ISC_Calendar.js?isc_version=7.0beta.js></script>
      <script type="text/javascript">document.getElementById('loadingMsg').innerHTML = 'Loading Data API...';</script>
      <script src=js/sc/modules/ISC_DataBinding.js?isc_version=7.0beta.js></script>
      function readCookie(name) {
      	var nameEQ = name + "=";
      	var ca = document.cookie.split(';');
      	for(var i=0;i < ca.length;i++) {
      		var c = ca[i];
      		while (c.charAt(0)==' ') c = c.substring(1,c.length);
      		if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length);
      	return null;
      // Determine what skin file to load
      var currentSkin = readCookie('skin'); 
      if (currentSkin == null) currentSkin = "SilverWave";
      <!--load skin-->
      <script type="text/javascript">document.getElementById('loadingMsg').innerHTML = 'Loading skin...';</script>
      <script type="text/javascript">
      document.write("<"+"script src=js/sc/skins/" + currentSkin + "/load_skin.js?isc_version=7.0beta.js><"+"/script>");
      <!--include the application JS-->
      <script type="text/javascript">document.getElementById('loadingMsg').innerHTML = 'Loading ~250 Samples<br>Please wait...';</script>
      <script type="text/javascript" src="com.smartgwt.sample.showcase.Showcase.nocache.js"></script>


        If you decide to declare the js files in the html make sure you use

        <inherits name="com.smartgwt.SmartGwtNoScript"/>

        in your module and in the html only include the js files you need. For example in your app these are not required.

        <script src=js/sc/modules/ISC_Forms.js?isc_version=7.0beta.js></script>
        <script src=js/sc/modules/ISC_RichTextEditor.js?isc_version=7.0beta.js></script>
        <script src=js/sc/modules/ISC_Calendar.js?isc_version=7.0beta.js></script>

        Also use yslow to find out the other bottle necks. I find that very useful


          The suggestions Mike made should help a lot. Kudos.

          I noticed the servers network connection is slow as molasses.
          It takes me (Germany) more than 23 secs to download 790 kb.
          That is about 35 kb/s !?
          Last edited by nlotz; 16 Dec 2008, 16:02.


   covered it, I think it's the "Slashdot effect" :)


              Thank you all for the suggestions. I have already implemented the gzip suggestion, which has helped a lot.

              I know the server isn't exactly speedy, but that's what I currently can afford :) I do think that 800kb is a bit much for such a small application, but I can understand that for larger applications, this is no longer a problem. Also, this means that, if I expand the application, the total size will remain almost constant from now on, so that's a good thing.

              I will look into the loading screen next, this way the user at least gets a sense of progress. Now you have to look at a blank screen for a while.

              Thanks again!


                Hi pbackx - another quick tip - it looks like your page is definitely not using the Forms, Calendar or RichTextEditor modules, but they are being included. You might also be able to get rid of DataBinding (if you don't use a DataSource) and Containers (which is TabSets, Windows and the like).


                  SmartGWT and EXT-GWT benchmark

                  Please see some benchmark details - comparison with EXT-GWT

                  The SmartGWT showcase size is 3Mb whereas the EXT showcase is 2Mb

                  If you compare the sizes of the core javascript downloaded for each of the libraries (EXT/SMART) the results are as follows:

                  EXT - total core javascript size is about 500KB (ext-all.js) (you can compile a smaller library using only components you choose)
                  Smart - total size is larger:
                  ISC_Core – 455Kb
                  ISC_Foundation – 160Kb
                  ISC_Containers – 70Kb
                  ISC_Grids – 416Kb
                  ISC_Forms – 357Kb
                  ISC_DataBinding – 262Kb
                  ISC_Calander – 50Kb

                  Obviously you can load only those you want but still you will probably at least use grids, containers Core and Foundation which is together 1.1 Mb – this is still very large comparing to Ext.

                  We all use Zip filters obviously which makes actual network size:
                  Smart-All – 467Kb
                  Smart (Core, Foundation, Containers, Grid) – 270Kb
                  EXT-All – 136Kb

                  Assuming we download once and the content is cached, there is still the JS load time (syntactic parsing of javascript) which will happen for every page load, and there is a big noticeable difference.

                  Wrt CSS:
                  Core CSS file size for ext is 112Kb (ext-all.css) – it can be reduced depending on components used.
                  Core CSS size for a SmartClient skin is 50Kb
                  CSS makes much better zipping ratio then JS and much faster syntactic parsing time. So this is a negligible difference
                  Zip size for CSS is:
                  EXT-ALL – 13Kb
                  Smart-All – 8Kb

                  Ext is definitely better from this perspective.

                  One more benchmark:
                  I installed both SmartGWT showcase and EXT-GWT explorer locally and simply opened it (as static HTML) – with no app-server…

                  EXT-GWT explorer loads twice as fast (4 sec) then the SmartGWT showcase (8 sec).

                  Yes, it’s not the same application but it is very similar:
                  Both applications load a static tree structure on the left pane and one initial tab on the right-side tab panel.
                  Everything is static, download times are minimal, most of the time is spent on parsing javascript and CSS (HTML is minimal) and creating the DOM tree.

                  I also compared the initial download times of both DEMO’s from the web. It’s not the same network path so it’s not a very valid comparison,
                  However, EXT-GWT explorer loaded in 15 sec whereas SmartGWT showcase in 27 seconds!

                  In favor of SmartGWT I can say that its internal design is better with the Data-binding and Data-sources. In most cases you will not need to use it but when you do, it’s better.

                  Question: Is there any ongoing effort to improve SmartGWT in this perspective?



                    First understand, when it comes to the real-world performance of enterprise applications, SmartClient has a very dominant lead over Ext-GWT and others. Real users not only load but use applications :) The key factor in performance of enterprise applications - speaking across many industries and applications - is the number of server trips that require dynamic responses, in particular the number and severity of hits on the database. In this area - again real world performance - SmartClient has a dominant lead because of it's advanced data management architecture.

                    SmartClient is larger, and it is larger because an explicit tradeoff is being made to be more dynamic and do more work on the client-side. We are always tuning for size, and we do plan to make it easier to trim off components you aren't using at a finer granularity, but understand that we will never try to match Ext's current size because doing so would necessarily imply taking backward steps in functionality. Both libraries are equally compact and SmartClient simply delivers more. When SmartClient's feature set was more comparable to Ext, it was Ext's size. In a few years if Ext's feature set reaches where SmartClient was in 2008, it will be SmartClient's size from 2008.

                    Also, you somewhat touched on this, but your comparisons of the showcases are quite invalid. There are almost 6 times as many samples in the SmartGWT showcase, as well as several large datasets, and much, much more sophisticated functionality is demonstrated.

                    It is definitely difficult to do direct comparisons, but if you have an enterprise architect who is experienced in evaluating performance, they will quickly spot many features in SmartClient that make the result of the comparison a foregone conclusion for any complex, large data volume application.

                    Also not sure why you think this:

                    "In favor of SmartGWT I can say that its internal design is better with the Data-binding and Data-sources. In most cases you will not need to use it but when you do, it’s better."

                    Substantially all real-world SmartClient applications use SmartClient's data binding architecture, and such applications are deployed pervasively throughout the Fortune 500. If you are trying to do a comparison and have come to the conclusion that SmartClient's databinding doesn't apply in most cases - there's no way around it - you need to pretty much start over :)


                      The size of EXT-GWT explorer code (regardless of the core EXT size) is 770Kb, the size of the SmartGWT code is 736Kb.
                      Since the first page only loads the javascript and builds ONLY the first introduction pane and the tree, there is no relevance to the number samples, since it is not being executed.
                      Also, there is no relevance to the number of datasets or samples since it the first introduction page never loads it. And if it does, then its part of the ~700Kb which is quite the same for both demos.
                      So I do think the comparison is valid from this perspective.

                      I agree (and also mentioned it) that data binding and data handling design are differentiators.
                      However, if we take of the 262Kb of ISC_DataBinding, the rest is still much larger.
                      It may be that more of the advanced code is in part in the other files as well (I assume so) and I can understand that this is what makes SmartClient much larger overall.

                      I am happy that you mentioned that you "do plan to make it easier to trim off components you aren't using at a finer granularity". That is my most impotent point.
                      Let me load, only those parts I use. This way, who cares which library is larger.

                      You keep mentioning real-world. I visited parts of it.
                      NOT all real-world applications are fortune-500, not every application has a large data-volume. Some just want to look and act pretty. For these, loading time that look as if you handle large data volume - is not so good...
                      Most home pages in the world present static data. It could be in grids, tabs etc or other fancy widgets. It almost always use forms (357Kb!).

                      To summarize my one and only point. I agree SmartClient is "smarter".
                      There should definitely be more finer granularity in order to improve load time - "what you see is what you load!!"
                      When it will be like that, there would be less to argue about.


                        @yariv SmartGWT is not for building home pages that present static data. Neither SmartGWT nor ExtGWT is appropriate for that purpose.

                        To say that ExtGWT is more nearly appropriate for a mostly static page is like saying that between a space shuttle and a Boeing airliner, a Boeing airliner is better for commuting down the freeway to work. Technically correct but you wouldn't use either vehicle to drive to work, both are wildly inappropriate :)

                        To us, ExtGWT inhabits an awkward middle ground: it is not nearly as productive for building complex enterprise applications as SmartGWT and the result is not nearly as good. And, despite the focus on being lightweight, it is not nearly lightweight enough for the use cases where SmartGWT is overkill.

                        For use cases like adding a flyout menu system to a homepage or adding some pizazz to an e-commerce site, JQuery or Scriptaculous make much more sense. These systems have extremely tiny widgets which are very easy to set up, are not particularly extensible but don't need to be for their target use case. They will remain tiny over time because they are not being simultaneously subjected to the requirements of an enterprise grade menu system (like, say, binding to a load on demand tree model).

                        Given the ability to use JQuery and SmartClient in tandem, as several of our customers do, and given SmartClient's ability to download in the background while the user is logging in, it's hard to see a case where ExtGWT is the most effective tool. Perhaps an enterprise app that you use only twice a year, only briefly, and that you use over a very slow network, so that load time from clean cache matters..?

                        Bottom line, if you are building an application where it makes sense to consider either ExtGWT or SmartGWT, the vast majority of the time you are in a use case where component-by-component trimming is going to have a negligible impact on actual perceived performance. You would be serving your users much better by analyzing the number of round trips to the server during common interactions, and how to reduce them.

                        PS. on your numbers, I'm not sure what you're measuring, but it absolutely makes an impact in terms of load time and initial render time that the SmartGWT showcase has 6 times the samples and shows far more functionality. I should also mention, if you're measuring all this with Firebug, comparative numbers are bogus because Firebug is known to have a greater performance impact on larger frameworks and applications. And furthermore, Firebug slows down all applications a great deal, so you are not seeing real-world load or response times for either framework. It's easy to get worried about performance while measuring with Firebug and then realize that there isn't a problem as soon as you turn Firebug off! :)


                          Thanks for you responses.
                          Wrt firebug, it was disabled when I tested download time. I only used it to see what files are downloaded and its size - I know better then to look at download time in firebug.

                          I see your point on the Boeing vs. space shuttle. Nice analogy, only please consider that a space-shuttle is the one being used twice a year (at most) where the Boeing is used thousands of time each day :).

                          I think it is a pity that you are giving up on the small-time application world. Going back to the "home pages" or other even semi static sites, they too can use your client (even if its not for the handling of large data-sets) if it was possible to download only what you really need.

                          Maybe to explain where I come from would help:
                          I am considering a new client library for the use of MANY developers. Developing both kinds of applications. Small time as well as enterprise. I would want to be able to use one client library for both cases instead of introducing multiple new libraries.

                          Again, Thanks for your very quick and elaborate answers it definitely helped me


                            Yariv, we've seen many companies try to find a single library for both the "lightweight homepage" use case and the enterprise application use case, and they all eventually come to the conclusion that the use cases are too different and two libraries are required. This is also what Forrester and other analysts will tell you.

                            By recommending JQuery for the lightweight homepage case, we're giving you the actual solution, not "giving up" on this use case. Standardization is important and it's key to use a minimal number of libraries, but not at the expense of using one tool for two different jobs and doing both poorly :) The important thing is to find a single vendor that supports this mixed use, as we do.

                            Importantly, component by component loading does not mean that a library can handle both use cases. The simple, technical reason for this is that any well-factored library that supports the enterprise application use case ends up with a common component framework used by all components. Using any single component pulls in this common code, and even GWT's static analysis will not substantially reduce it.

                            All you need to do to convince yourself of this is build a minimal GWT or ExtGWT application: you'll find yourself 6-8x heavier than JQuery with less functionality. Consider that Google themselves do not use GWT for any of their light to medium weight pages or applications.

                            Or, look at Dojo. It has a widely touted minimum size similar to JQuery, but, like SmartClient's FileLoader, it's primarily capable of loading the rest of the framework and little else :) Dijit (dojo's core widget framework) is far too large for the "lightweight homepage" use case.

                            By contrast, many of the basic widgets available for JQuery and other tiny Ajax libraries are completely purpose-specific: they rely on JQuery only and have no common code with other widgets. This is very inflexible, creates great inconsistency across widgets, and is totally wrong for an enterprise application framework. But it's absolutely the right thing for a page that needs to be super light and has very minimal dynamic functionality.

                            Anyway, you don't need to take our word for it. There are countless companies with a JQuery front page and a different technology in use for enterprise applications. Just look around :)


                              I would like to take up this post again, if it's not a problem. I am also experiencing some high load times with my modules. The problem, when looking at firebug, is that the files are being loaded synchronously. Shouldn't it be possible to merge the libraries included in GWT with the gwt JS code so one big JS file is being sent instead? If this isn't possible, are there any tools available for merging these JS files so I'll get rid of the synchronous loading.