10 November, 2006 / ASP.NET Performance: Reducing Size of Web Page


We are working on performance improvement and one task is to reduce size of generated HTML pages. For example, user stories list with 20 user stories weight was about 380K, which is too heavy. We've optimized it to 150K using several techniques listed below:

  1. Don't use ID in controls in GridView and Repeater if possible. Each ID (especially in named containers) adds several bytes to each row.
  2. Use shortest possible names in IDs. For example, "wpm" instead "WebPartsManager1". Here is the difference: before
    ctl00_wpm_gwpUserStoryList1_UserStoryList1_userStoryGrid_ ctl06_actors_lstActors_ctl02_assignedUsersList_pnlReassignments
    In fact this is one of the most important thing for reducing HTML size
  3. Don't use spaces in ASPX/ASCX code. Use tabs instead (in Visual Studio click Options->Text Editor->HTML->Tabs->Keep Tabs option, then reformat all documents by Ctrl+K Ctrl+D). In fact it is better to remove all tabs in final release at all. Tabs saved us 40K!
  4. Don't use Labels in TemplateField if possible, use just plain Eval or Literal. Each label adds <span></span> around value.
    <asp:templatefield headertext="ID"
     sortexpression="UserStoryID" accessibleheadertext="UserStoryID">
    <%# Eval("UserStoryID") %>
  5. Use IMG instead Image. Image adds often unnecessary style="border-width:0px;" to generated img tag
  6. Do not use inline styles, use classes instead. For example, class="topMenu" smaller than style="padding: 10px; font: 12px Arial; margin-bottom: 10px"
  7. Do not use base.Render() in custom controls that affects states of other controls only. For example, we've used so called Extenders to show/hide other controls based on some input parameters and these extenders rendered as <span></span>, which is just not required.
  8. Use WebParts with care. We've added WebPartsManager into master page and it affected all pages in application. We've moved it into customized pages only.


At November 13, 2006 5:07 PM, Blogger DamienG said...

I would imagine you are looking at the uncompressed page sizes in your estimations.

Bearing in mind most modern browsers support gzip compression as does IIS6 the savings you quote are not truely representative of the bandwidth savings.

For example saving 40K on a big page by using spaces instead of tabs is unlikely to make more than about 0.5K-1K of difference after the inbuilt compression between server and browser.


At November 13, 2006 5:11 PM, Blogger TargetProcess said...

Yes, but
1. It will take a lot of CPU resource to compress 400K page. We've checked that.
2. Not all servers use CPU compression and we just can't be sure that our customers will enable this feature

At November 13, 2006 6:03 PM, Blogger TweeZz said...

Have a look at this: http://www.madskristensen.dk/blog/A+Whitespace+Removal+HTTP+Module+For+ASPNET+20.aspx

At November 13, 2006 8:19 PM, Anonymous Anonymous said...

Yeah, thats pretty stupid advice. Refactor all your server controls to shorter names for space? Maintainability doesnt matter?

I second the gzip recommendation. If you are concerned about over the wire page sizes (for bandwidth purposes), this would be the best (and most encapsulated) solution.

At November 22, 2006 9:16 PM, Anonymous don hamm said...

Another option is when using viewstate is to use viewstate compression. We've found that many pages that use viewstate can save between 30 to 50% of the view state size -- also allowing for faster page loading

At November 22, 2006 9:17 PM, Anonymous Anonymous said...

You could also use viewstate compression if you use the viewstate. This can save 30 to 50% of a pages viewstate size -- thus loading the page quicker. I've used GZip to do that in 2.0.



Post a Comment

Links to this post:

Create a Link

<< Home


We are developing TargetProcess agile project management software and blogging about our progress.

Subscribe to the RSS feed
Stay tuned by having the latest updates via RSS
Follow TargetProcess on Twitter
Get in touch with our team

Try TargetProcess
TargetProcess quick tour