All posts

Optimizing the load size of Telerik Silverlight controls

Monday, July 07, 2008

Following the expansion of our Silverlight suite (more than 15 controls coming out next week) and the feedback we’ve got from the community, we are now in a process of optimizing the size of the assemblies.

Instead of including all our controls into one big assembly, we decided to group them into several smaller ones. This will reduce the size of the XAP file when you are not using all the controls in the suite. We came up with the following list of assemblies:
  • Telerik.Windows.UI.dll
  • Telerik.Windows.Controls.Navigation.dll
  • Telerik.Windows.Controls.Input.dll
  • Telerik.Windows.Controls.Web.dll
Apart from this list there will be assemblies that hold the themes of the controls - e.g. separate assemblies for the Telerik, Vista and Default themes.

 Telerik Silverlight Controls size optimization

I want to emphasize, that the separation of the assemblies will neither lead to more requests to the server,nor it will affect the deployment of your application. This is due to the fact that Silverlight apps are deployed as a single XAP file that contains all the needed assembly references and resources. 

We would greatly appreciate your feedback about this change.  Drop us a line and let us know what you prefer - one monolithic assembly, or separate assemblies for every control. We will implement the above mentioned change in the next couple of days. Any suggestions and comments are welcome.

 

posted by: Valentin Stoychev

Facebook DZone It! Digg It! StumbleUpon Technorati Del.icio.us NewsVine Reddit Blinklist Furl it!

Tags Silverlight Optimization

Comments  3

  • 7 Jul, 01:47 PM

    I think it would be important to know just exactly how much savings are being realized by separating out the assemblies. Although there are times when even the smallest savings are worth making a fundamental change, I'm not sure this is one of them. I've really enjoyed the change in the ASP.NET suite to a single assembly from a development time savings point of view and based on that experience, I've grown to appreciate the simplicity of single assemblies. All that said, if we're talking big-time reductions that would typically be achieved then perhaps it would make sense to do it that way.

    comment by: Shaun Peet
  • 8 Jul, 06:59 AM

    Shaun, are you a Silverlight programmer? You can not compare the concept of "ASP assemblies sizes" versus Silverlight assemblies. Those are two different technologies with totally different usages at runtime. Secondly, the objective isn't size reduction, is merely loading what you need to client, which is an important issue in real life when users perceive your application is taking too long to load.

    comment by: Ben
  • 8 Jul, 10:22 AM

    If you are not using one or more of the control assemblies, you could save up to several hundred kilobytes. It will be also possible to replace the default skin in the assemblies with a skin of your choice (if you own the source code :)) and save another 30-100kB. However, for large applications, the biggest optimization (up to 30%) most probably will come from splitting or recompressing the XAP files
    http://blogs.telerik.com/ValeriHristov/Posts/08-05-13/Increasing_the_compression_ratio_of_the_XAP_files.aspx

    comment by: Val
Post a comment!

  5. Security image