RadHiddenFieldPageStateCompression (!) GZip ?

4 posts, 0 answers
  1. CSurieux
    CSurieux avatar
    465 posts
    Member since:
    Jan 2007

    Posted 30 Mar 2010 Link to this post


    Using Q1 2010.
    I included a browser file on my site but it doesnt seem to work, still very heavy viewstates ?
    My file
      <browser refID="Default">  
          <adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadHiddenFieldPageStateCompression" /> 

    And I read in some threads that using session for viewstate is not perfectly supported when using some modal dialogs, but which ones ? RadWindow, RadUpload ? ???

    last point, I have also seen in Chrome console that telerik scripts come without being zipped where I have the default RadScriptManager which should use GZip ???

  2. BaiH
    BaiH avatar
    83 posts
    Member since:
    Aug 2008

    Posted 01 Apr 2010 Link to this post

    As you are still using the hiddenFieldPersister all your view state will still be serialized to the page's output. So if you have large view state it still be rendered to the page but compressed. You can check the response's size using Fiddler or FireBug if there is any difference with or without compression.
    If you want to remove the viewstate from rendering to the page you should use the SessionPersister instead. You can use HistorySize webconfig setting in order to workaround the issues with multiple RadWindows. Check this out for more details ->


  3. DevCraft R3 2016 release webinar banner
  4. CSurieux
    CSurieux avatar
    465 posts
    Member since:
    Jan 2007

    Posted 01 Apr 2010 Link to this post

    Thank you answering,
    But nothing seems to be compressed in ViewState, page size is identical with or without the .browser file and page rendering are very slow.
    Chrome analyze tools give a very long delay for telerik script loading: the combined and theorically compressed scipts and css arrive a long time after other elements in the page and take long time to load (4,24s)  and even longer to be interpreted by the browser whichever (IE, FF, Chrome).
    When I look at Google anylize for r webresource.axd concerning the combined scripts, I get this:

    Request Method:GET  
    Status Code:200 OK  
    Request Headers  
    User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/ Safari/532.5  
    Query String Parameters  
    _TSM_CombinedScripts_:;;System.Web.Extensions, Version=, Culture=neutralPublicKeyToken=31bf3856ad364e35:fr:0d787d5c-3903-4814-ad72-296cea810318:ea597d4b:b25378d2;Telerik.Web.UI:fr:30afb63f-e6ac-41db-9851-11879733de0a:16e4e7cd:f7645509:ed16cbdc:874f8ea2:24ee1bba:19620875:39040b5c:f85f9819:33108d14:bd8f85e4:1e771326:aa288e2d:e330518b:c8618e41:86526ba7:3f6e8f3f  
    Response Headers  
    Cache-Control:public, max-age=31535983 
    Date:Thu, 01 Apr 2010 11:07:15 GMT  
    Expires:Fri, 01 Apr 2011 11:06:59 GMT  

    and there are no mention of any compression, but the header link is requesting compression:

    But for the webresource.axd concerning the css I get

    Content-Encodeing: Gzip.

    It seems that the scripts are not encoded and loaded each time (no cache)

    It has been getting worse since I used the Q1 2010,

  5. BaiH
    BaiH avatar
    83 posts
    Member since:
    Aug 2008

    Posted 06 Apr 2010 Link to this post

    Is there any chance that you are behind a proxy, which to strip some info from the request's headers?
    Also I have looked at the http://www.addonnice.com/. It seems that you are using other compression modules. Can you provide more information about this? is it IIS6 built-in compression or something different? You may try disable other compression and check if this will make any difference.

Back to Top