Community & Support
Skip Navigation LinksHome / Community & Support / Developer Productivity Tools Forums / ASP.NET > General Discussions > Keeping a telerik-heavy page light on kilobytes
RadControls for ASP.NET are no longer supported (see this page for reference). In case you have inquiries about the Telerik ASP.NET AJAX controls, post them in the pertinent ASP.NET AJAX forums.

Not answered Keeping a telerik-heavy page light on kilobytes

Feed from this thread
  • Thomas Booysen avatar

    Posted on Mar 19, 2007 (permalink)

    We have a few pages that contain 4 or more different RadControls.
    These pages typically size 400KB and up.
    Looking at the overhead for these pages, it is clear the bulk of the overhead come from Telerik dlls for the controls on these pages.
    Wouldn't it be nice if Telerik can provide stepped dll for each control:
    I have Calender, but only use functionality a,b and c of a-z functions available.
    Telerik can provide a dll for functions a-e, f-m, m-z and of course the full a-z. You use the correct one and cut down on overhead.
    This approach could put Telerik in direct competition with the lightweight AJAX control suites out there, without much development input.

  • Posted on Mar 19, 2007 (permalink)

    Indeed, light versions are often needed, if it is possible to provide less markup if we use less features, it will be swell. So I do support this idea as well.

    Thomas, how much of these 400KB is ViewState? If it is a lot, you can probably spare it by overriding the default ViewState storage media from client-side HTML (actually a hidden in the HTML) to Session. You can achieve that by overriding Page.LoadPageStateFromPersistenceMedium() and Page.SavePageStateToPersistenceMedium(viewState).

    This is described well here:
    http://www.codeproject.com/aspnet/PersistentStatePage.asp

  • Poul Henningsen Master avatar

    Posted on Mar 19, 2007 (permalink)

    Thomas, sorry about the question, but have you ever used any controls that use that "stepped dll" approach? Or is it just your idea of how to speed up your site?

    I agree that telerik controls are heavily bumped with client-side functions that need a lot of JS to be loaded on the client. Still, have in mind that once loaded on the client, the JS will be cached by the browser and won't be served by the server next time it is requested. Of course, this will happen only if cache is enabled on the client browser.

  • Posted on Mar 19, 2007 (permalink)

    Have a read through this forum entry it discusses setting up and using HTTP Compression to reduce your page sizes significantly.

    On average the AXD (telerik) files are reduced to a quarter of their current size went using http compression. 




  • Posted on Mar 19, 2007 (permalink)

    Yep, the HTTP thread is pretty interesting. Just a side note - perfomance should be measured with some HTTP monitoring tool like Fiddler.

    Also, Telerik provides additional perfomarmance optimization information in this KB article:

    Optimizing the RadControls folder for publishing, deploying and performance
    http://www.telerik.com/support/kb/article/b454K-tgb-b454T-bah.aspx

  • Posted on Mar 21, 2007 (permalink)

    By the way, if you have multiple rad Calendar instances on the same page.  there is a neat trick - sharing calendars - you can share the same calendar instance with multiple RadDatePickers controls:

    The online example is here:
    http://www.telerik.com/demos/aspnet/Calendar/Examples/Design/Sunny/DefaultCS.aspx

    ...
    Having many date pickers on a page might render too much HTML and impact performance.  RadDatePicker instances can share a RadCalendar control and use it to pick dates. 

    There are two ways to configure the calendar control:
    • by setting its ID to the RadDatePicker.SharedCalendarID property.  That can be done in the VS.NET designer.
    • by passing a reference to the control to the RadDatePicker.SharedCalendar property.  Available to the code-behind logic only.

    This example page has four date pickers.  The "static" ones have their SharedCalendarID property pointed at the "sharedCalendar" RadCalendar instance.  The "dynamic" pickers are configured in the code-behind.  The Page_Load event handler creates a new RadCalendar control and sets a reference to it to the pickers' SharedCalendar properties.


    ...

  • MB Master avatar

    Posted on Mar 21, 2007 (permalink)

    Http compression is useful, but I feel that careful configuration of client cache control, to ensure clients don't reload anything they don't need to, can provide a much better bang for the buck.

    www.Httpwatch.com have a nice & free protocol traffic viewer for IE which you can use to analyse the traffic and see what is being re-loaded by the client and what you should be caching.

    -- MB.

  • Posted on Mar 21, 2007 (permalink)

    Indeed, one of the resources that never get cached in IE browsers are background images in Css files - they are reloaded upon each request (for example, mouse overs). This can be verified using a tool like HttpWatch or Fiddler. Telerik uses a lot of background images in their skins (which is not a bad thing, since otherwise the visual appearance would not be so good and professional looking), but a "hack" is needed to make IE remember the images and not request them on each mouseover. The hack is described here:

    http://www.telerik.com/community/forums/thread/b311D-teckk.aspx

  • MB Master avatar

    Posted on Mar 21, 2007 (permalink)

    Personally, I rely on on a 3rd party tool to control the client cache of all pages and components.

    I use the port80 cacheright tool (no, I don't work for port80, I just like their stuff) and find it does a good job of "encouraging" browsers to cache what I want them to. I find that can totally eliminate all 2nd requests this way.

    Of course, no header-level cache control can "force" a browser to cache if the user doesn't want it to... and hard-coding has it's place in those cases... but I don't find it necessary to resort to such steps.

  • Posted on Mar 21, 2007 (permalink)

    This, by the way, is turning into a pretty good general thread on how to optimize the footprint and general performance of telerik controls. Maybe it should be pinned somewhere so everybody can see it and add additional suggestions?

    Here is what we have so far:

    1) Make sure you tell your clients (if possible of course) to enable browser caching - this will load the javascript files needed by the control only once

    2) You can store ViewState in Session instead of a hidden inside the HTML (which bloats HTML). This is described here:
    http://www.codeproject.com/aspnet/PersistentStatePage.asp

    3) You can set EnableViewState for the controls to False and rebind upon each postback to the server - this way, there will be no ViewState

    4) You can use HTTP compression modules for your IIS server - this may compress the external telerik files up to 1/4 of their original size! This is described in this forum thread:

    http://www.telerik.com/community/forums/thread/b311D-tdkga.aspx

    5) You can force IE to cache background images in Css as described in this forum thread:

    http://www.telerik.com/community/forums/thread/b311D-teckk.aspx

    6) You should check the online documentation for each control - typically, there is a "Speed Optimization" topic specific for each control. For example, if you choose a very short ID for your navigational control, this may spare up to 10KB for a control with 100 items, as described here:

    http://www.telerik.com/community/forums/thread/b311D-tkchk.aspx

    For Rad Calendar for example, you can share one instance of the Calendar with many RadDatePicker instances (only HTML for one calendar will be rendered as described here):

    http://www.telerik.com/community/forums/thread/b311D-tkbtm.aspx

    In general, each control has some tricks - just read the docs.

    7) You can play with Http monitoring tools like Fiddler and HttpWatch to figure out where is the bottleneck when it comes to page speed.

    8)  Use 3rd part optimization tools, like   the port80 tool cacheright tool which does a good job of "encouraging" browsers to cache external resources. You can totally eliminate all 2nd requests this way.

  • Posted on Mar 21, 2007 (permalink)

    Top score Johan.  thanks for compiling that.

    The only other thing I can add is to use a Ram Drive/Disk in a couple of places in the infrastrucutre....  see this link http://www.superspeed.com/ramdisk.php
    - the location that all deflated files are kept when using HTTP compression
    - the tempdb of the SQL backend. 

  • Martin Master avatar

    Posted on Mar 29, 2007 (permalink)

    Here's another thing to consider when trying to reduce the size of pages containing telerik controls:

    9) Do not use the embedded web resources (e.g. skins, scripts). Instead, deploy the default skin (which is the same as the embedded one) with your application.

    I had a page with a fairly big treeview and was initially using the embedded skin. The result was, that the page was full of URLs such as this:

    '/MyApp/WebResource.axd?d=HR9MTtL71J8NbvgBhmkjj1DSBKOPw
    WrwO98PR-pvJHrBBRAOpeRk_gG_yNp2WBkFIdGln8qhn6b1XNPf-obzk
    FH0pISEnb_JEseWe2v5UDKlg3Deuq3MQTUcPga3gJVk0&
    t=633083579580000000'

    After deploying the treeview's default skin (to the folder ~/RadControls/TreeView/Skins/Default), and changing the treeview to use that skin, the resulting URLs were considerably shorter, e.g:

    '/MyApp/RadControls/TreeView/Skins/Default/BottomLine.gif'

    Overall, this reduced the page-size from ~80 kB to ~50 kB.
    Maybe this effect will not be as noticable for other controls, but it's surely something to check.

    Best regards,
    Martin

  • Martin Master avatar

    Posted on Mar 29, 2007 (permalink)

    And yet another tip (which is valid whether telerik controls are used or not):

    10) When having pages with deeply nested controls (e.g. a treeview inside a splitter, inside an asp:content control), make sure that the IDs of these controls are short.

    For example, if you put a rad.splitter and a rad.treeview on a page using a master page, and you do not change the default IDs of these controls, you will find that the resulting HTML code contains a lot of very long IDs which are build based on the IDs of the server-side controls, e.g:
    • <div id="ctl00_ContentPlaceHolder1_RadTree1_t0">
    • <input type="hidden" name="ctl00$ContentPlaceHolder1$RadTree1_selected" id="ctl00_ContentPlaceHolder1_RadTree1_selected" value="000" />
    • <img id="RAD_SPLITBAR_SPACER_ctl00_ContentPlaceHolder1_RadSplitBar1"
    By shortening the IDs of the server-side controls, the IDs of the client-side HTML elements will also be much shorter, which may reduce the overall size of the page.

    Best regards,
    Martin

  • Posted on Mar 29, 2007 (permalink)

    Great suggestions Martin and thanks for contributing to this thread - this is turning into a great speed optimization telerik related resource.

    #10 - Indeed, whenever a control is nested inside another INamingContainer, the ID of the parent control is prepended to the ID of the child controls. So if you have treeview inside splitter inside grid for example, you will have all the IDs for parent controls prepended for each individual rad TreeView node - so the HTML gets huge, so it's a great advice in general for all ASP.NET controls (not only telerik).

  • Posted on Apr 2, 2007 (permalink)

    11. The built-in VS 2005 Web Service (Cassini) does not use cache and sites are always slower (external resources not cached, etc, etc). Developing always in IIS mode will make the site faster and closer to look and feel to the actual site when placed on the production server.


  • Posted on Apr 3, 2007 (permalink)

    #12 If you are nesting complex forms in rad TabStrip with a lot of controls, always make sure that you have set the RenderSelectedPageOnly property of the multipage serving the tabstrip to True. This way, only the Html / ViewState for the currently selected tab will be shown, sparing a lot of bandwidth and gaining a lot of speed. Just make sure to also set the AutoPostBack property of the tabstrip to True.

    If the postback is not desirable, wrap the tabstrip instance inside rad AjaxPanel (or ajaxify it using rad AjaxManager)

  • Posted on Apr 4, 2007 (permalink)

    13. You can use Incremental Page Fetch using rad Ajax. One possible technique is described in this forum thread:

    http://www.telerik.com/community/forums/thread/b311D-tkkce.aspx

  • Posted on May 10, 2007 (permalink)

    #13 Turn on HTTP module in web.config and remove white space.

    Simple 90k download, install and change web.config and the system will automaically remove whitespace from the ASPX pages. 

    aspnet-whitespace-removal-http-module plus review (now with working download)

    Discussion about it's and the way it works. . . .

    andyk

  • Posted on May 10, 2007 (permalink)

    I've seen a somewhat similar approach By Jason Maronge in the forums as well - looks like an great idea. The idea is to hook the page Render and remove all whitespaces and formatting chars. Looks like a good trick

      protected override void Render(HtmlTextWriter writer)   
            {   
                StringWriter stringWriter = new StringWriter();   
                HtmlTextWriter htmlWriter = new HtmlTextWriter(stringWriter);   
                base.Render(htmlWriter);   
                string html = stringWriter.ToString();   
                html = html.Replace("\t"""); // tabs   
                html = html.Replace("  "" "); // double spaces   
                html = html.Replace(" />""/>"); // space before end of tags   
                html = html.Replace(">\r"">"); // space before end of tags   
                html = html.Replace(">\n"">"); // space before end of tags   
                writer.Write(html);   
            }  


    Credit for the great idea by Jason and original post is available here
    http://www.telerik.com/community/forums/thread/b311D-thhcc.aspx

    Just note that there might be problems with this approach and the new rad Ajax Prometheus.

  • MB Master avatar

    Posted on May 10, 2007 (permalink)

    Slightly more challenging... would be to come up with the required regular expressions to strip out comments.

  • Posted on May 10, 2007 (permalink)

    A good idea, will be very challenging :) This is one good place to start though...

    http://haacked.com/archive/2004/10/25/usingregularexpressionstomatchhtml.aspx

    But I believe compression modules compress trailing / often repeated sequences well engouh, so I am not sure if the RegExp is worth if compression modules are available for IIS. Not to mention the RegExping a whole Html page might be really slow.

  • MB Master avatar

    Posted on May 10, 2007 (permalink)

    Cool...!  I'll have to play with those two, and see how much junk I can rip out of my rendered pages.

  • MB Master avatar

    Posted on May 10, 2007 (permalink)

    Actually, that appears to strip HTML comments, but won't strip /* */ type comments from embedded SCRIPT tags etc.

    I've actually been recently struggling with this one, in Visual Studio, when trying to create regex to find & replace specific multi-line comments in my C# code (using VStudio's Search & Replace).

    I'm yet to think up a single-line regex that will do this successfully in VS (where you don't have the full .Net regex support) but I'm sure someone smarter than me has a solution somewhere.

    I know that Port80 strip comments and whitespace from all files managed by their httpzip module... which includes rendered html (from html or asp files), js-files, css-files, etc... but I found it to be a bit too quirky and unpredictable for my own application, to use it on my production sites.

  • Posted on May 11, 2007 (permalink)

    #14 (or is it #15?) Good Programming technique with ASP controls.

    Don't use <asp:label> when <asp:literal> does the job and conforms to xhtml standards.  And possibly replace <asp:hyperlinks> with <a> plus <asp:literal> when the link is static.
    i.e. 

    <li><asp:label text="some text" runat="server"></asp:label></li>
    will create
    <li><span id="some_long_id_name">some text</span></li>

    where as

    <li><asp:literal text="some text"  runat="server"></asp:literal></li>
    will create
    <li>some text</li>

    this can also be applied to other xhtml tags when doing localization.
    <li><a href="http://www.telerik.com/"><asp:literal text="<%$ resources: get_telerik %>"></asp:literal></a></li>
    will produce
    <li><a href="http://www.telerik.com/">get telerik rad controls</a></li>

    this saves having to have the long id of the asp:hyperlink.

    Not really about telerik controls this tip but general space saving stuff.

  • Posted on May 15, 2007 (permalink)

    All-

    This is an EXCELLENT collection of ideas that deserves some publicity. I will assemble the 15 (or so) ideas that have been submitted so far and put them in a blog on Telerik.com today. I'll give credit to everyone that contributed.

    Thanks for being active members of the Telerik community. Keep up the great work!

    Thanks~
    Todd

  • ewart Master avatar

    Posted on Jul 26, 2007 (permalink)

    #16.   If you have a RadWindow on the page it will render an additional ~7 kilobytes of standard templates for radalert, radconfirm, radprompt.   Set EnableStandardPopups to false for your RadWindow and this code disapears and the browsers popups will be used instead.

    This is particullary useful if you are not using the templates - for example, I am just using the RawWindow like a iframe to dynamically load my user controls and other content into as part of the site layout.  So every page on my website had this overhead.

    Reference here 

  • ewart Master avatar

    Posted on Jul 31, 2007 (permalink)

    #17  Using skin in your RadGrid forces it to generate an extra ~6 kilobytes of unused code in the page.  Before you say, but hey, I need my skin!! You can still consider setting Skin="none" in situations when you have no records output.  (an empty grid still generates ~6 kb of code in the page, plus other library downloads).  It looks like this will be rectified in version 5 of the grid.

    Reference here

  • Phil avatar

    Posted on Aug 12, 2007 (permalink)

    This is a cool thread!!

    I'm taking a two phase approach to optimising viewstate on my pages that are "busy". Well three really, the first is to check out http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx and make sure all that viewstate is necessary!

    I'm both compressing my viewstate AND storing it in session. That way I reduce the memory overhead of holding viewstate in session (at the expense obviously of extra processing on every callback - best to be aware of that.

    Code for compressing viewstate is easily found, and overloading SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium to divert the viewstate to session variables is also well documented. What tends not to get addressed is the "hidden" consequence of doing this - especially with IE7. Multiple tabs (or windows) share the same session, so you risk breaking your app by storing viewstate in session - effectively you are making the page viewstate a shared resource across all windows open in the same session.

    Fortunately this is easily resolved (though surprisingly I've never seen this documented). Simply create a unique page id on page load (I use pid=datetimenow.ticks.tostring), inject that as a hidden variable in your page, and key your session viewstate object using that value. Getting your viewstate back means pulling that unique page id from the form and reading the session object. Simple.

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load  
     
    If not Page.IsPostBack Then pid = DateTime.Now.Ticks.ToString ' unique page id, this is required to ensure multiple tabs in a session do not collide  
      ...  
    End Sub  
     
    Protected Overloads Overrides Sub SavePageStateToPersistenceMedium(ByVal state As Object)  
     
    ' compress and save viewstate in session  
     
    Dim formatter As New LosFormatter()  
    Dim writer As New StringWriter()  
    formatter.Serialize(writer, state)  
    Dim viewState As String = writer.ToString()  
    Dim data As Byte() = Convert.FromBase64String(viewState)  
    Dim compressedData As Byte() = ViewStateHelper.Compress(data)  
    Dim str As String = Convert.ToBase64String(compressedData)  
    Session.Item("_vs|" & pid) = str  
    ClientScript.RegisterHiddenField("_pid", pid)  
    End Sub  
     
    Protected Overloads Overrides Function LoadPageStateFromPersistenceMedium() As Object  
     
    ' return viewstate from session and decompress  
     
    dim pid as string = Request.Form("_pid")  
    dim viewstate as String = session.Item("_vs|" & pid)  
    Dim data As Byte() = Convert.FromBase64String(viewstate)  
    Dim uncompressedData As Byte() = ViewStateHelper.Decompress(data)  
    Dim str As String = Convert.ToBase64String(uncompressedData)  
    Dim formatter As New LosFormatter()  
    Return formatter.Deserialize(str)  
    End Function  
     
     


  • gerard avatar

    Posted on Sep 5, 2007 (permalink)

    Hi,

    I would like to know more about this forum, how do I get involved in working on net during my spare time and how I can earn please guide me.

    Thanks and regads
    A.C. GERARD

  • Sebastian Sebastian admin's avatar

    Posted on Sep 5, 2007 (permalink)

    Hi gerard,

    You will probably be interested in reviewing this section from our public forums:

    http://www.telerik.com/community/forums/allthreads/b312H-beg.aspx

    All the best,
    Stephen
    the Telerik team

    Instantly find answers to your questions at the new Telerik Support Center

  • Posted on Oct 19, 2007 (permalink)

    All,

    Found this ultra cheap Ram Drive product.  Says it's based on the MS drivers which are flakey to say the least when running native ram drive.  Does anybody have any experience with this one?

    ramdisk page

    I'm gona test it on XP to see what it's like, and maybe 2003 if no one else has.

    Also found these nice pages about setting your .NET production server to be in "Retail" deployment configuration so that NOTHING on the server runs as debug, no matter what the web.config says.  Will save sizes on AXD files and reduce server overheads.   Is really cool to use this as you don't have to worry about a developers code being in debug, as on the production server will not be.


    MSDN reference

    a blog item about it
    <deployment retail="true" />

    blog item about debug=true and what it does
    Happy space saving...
    Regards
    Andyk

  • Mike Perry avatar

    Posted on Nov 29, 2007 (permalink)

    Hello

    Great thread.  I just wanted to throw out one comment on client side caching that a developer should be at least aware of so that they can handle a possible situation.

    You need to intelligently manage your caching schemes because when you update your app, and say maybe include a new version of some RadControls, if the javascript changed and you told the browser to cache the previous file indefinately, then your page might error without the client doing the old Ctrl + F5 and refreshing the cache.  This also goes for any changes to your own CSS files, images, javascript files.

    There are a few ways around this, but they have caveats as well that may or may not work for you.  My team solved the problem for our app by rather than depending on the time based mechanism IIS provides, our continuos build server renames all the javascript files by appending the build version to the file name and updating all the links to the file.  This ensures that every new build will force the client cache to get the lates file (we really only care about the javascript files, all the other files we put a time based chaching rule like 6 months for CSS files and 1 year for images, etc.)

    The previously mentioned tools can also help mitigate some of the pitfalls with client side caching as well.

  • dmccormack avatar

    Posted on Jan 22, 2008 (permalink)

    Hello, not sure if this is still relevant in this thread but what we've done to avoid the whole viewstate size issue is to just store the information in a separate SQL database instead of memory.  What we do instead is just use a field __VIEWSTATEGUID which is a unique identifier that points to a record with an image datatype.  We chunk the data into manageble parts, with the option of compressing the data, and then push it to the db.  This way we can offload the storage to a separate db server if we need too. 

    This also resolves any issues with memory overhead and session timeouts as the data is never 'lost' or cleared from IIS. 

  • dmccormack avatar

    Posted on Feb 1, 2008 (permalink)

    Post your email address, or if there's another way to send it through the forums.

    I can send you much of the code. 

  • ewart Master avatar

    Posted on Feb 1, 2008 (permalink)

    Hi dmccormack, I'd be grateful of getting a fwd of that too.. 

    ewart at ihug.co.nz

    you might be able to post it as a open source summary for some telerik points too, just a thought.

    cheers
    ewart

  • dmccormack avatar

    Posted on Feb 1, 2008 (permalink)

    How do you post it?  Haven't seen where to upload files in these forums, or am I missing something?

  • Posted on Feb 1, 2008 (permalink)

    McCormack-

    Try posting your code sample in the Telerik Code Library:

    http://www.telerik.com/support/code-library.aspx

    That's the best place to put a full sample that everyone can download.

    -Todd

  • Patrick Stovall avatar

    Posted on Aug 26, 2008 (permalink)

    Does anyone know if code got posted?  I wasn't able to find a reference for it.

    Thanks!

Back to Top

Skip Navigation LinksHome / Community & Support / Developer Productivity Tools Forums / ASP.NET > General Discussions > Keeping a telerik-heavy page light on kilobytes