I plan to program web applications for small companies. When I read about ASP.NET Web Forms, I liked its way of building dynamic sites.

However, I have heard from a friend that Web Forms could increase the size of the pages because of ViewState output. Will the difference between the size of PHP pages and the generated HTML of ASP.NET pages be dramatic?

  • 7
    I'd love to know why this was closed while I was in the middle of writing an answer, despite only having two close votes. I thought it needed five. And while maybe not worded the best, this is a valid question - there is a page size hit you take for using ASP.NET WebForms, and it is reasonable to ask how big that hit is. – Carson63000 Mar 2 '13 at 9:46
  • 6
    @Carson63000 ^+1, voted to reopen. Far too many questions get closed around here. Usually by the same few people it seems. – MattDavey Mar 2 '13 at 10:40
  • 4
    @Carson63000 "maybe not worded the best" - would you mind editing the question so that is would be clearer for readers? – gnat Mar 2 '13 at 11:02
  • @Carson63000 When a diamond mod(such as Yannis Rizos♦) votes to close a question, it gets closed instantly and doesn't require votes from other users. – CodesInChaos Mar 2 '13 at 11:05
  • 7
    @CodesInChaos oh, I know that: it's just that I was under the impression that moderator powers were only intended to be used when there was a genuine problem that needed to be urgently taken care of, not just when a moderator didn't feel like allowing the community to do their own voting. – Carson63000 Mar 2 '13 at 19:56

If you use ASP.NET WebForms, there are indeed a couple of aspects that will enlarge your HTML. They can be mitigated to an extent, some more easily than others, and improvements have been made particularly in .NET 4.0.

  • As you say, there is the hidden __VIEWSTATE element which WebForms uses to maintain the illusion of statefulness. This is turned on by default, and if don't touch it, it can easily add a lot of unnecessary weight to a page with a lot of controls. If you're not actually using it, though, you can turn it off on a page or a control with EnableViewState="False".
  • If you use the more featureful Web Forms controls, you can do some rather rapid development, but you can also produce a lot of generated HTML which isn't really under your control, and could well be a lot bigger than is necessary for the subset of functionality that you need. In my Web Forms days, I found that a lot of developers (myself included) shied away from the more powerful controls because it always felt like it saved you time in the beginning but ended up costing you more time later on, as you fought with it to get the precise result you needed.
  • If you architect your pages in an easy-to-maintain fashion, with master pages, pages, and various user controls, you'll find that Web Forms' name-mangling of IDs (to guarantee uniqueness) will lead to some rather long IDs on HTML elements, thing like id="ctl00_AGSMasthead_imgSkipContent". This has been improved in .NET 4.0 - you can use the new ClientIDMode="Static" property to tell Web Forms that it does not need to mangle the ID, you'll maintain uniqueness yourself.
  • Because Web Forms uses the ID of a control to refer to that control in server-side code and as the ID of the element in the rendered HTML, it often leads to you having a lot of HTML elements with IDs that are never used client-side by CSS or JavaScript, and are just wasted space. This is one of my main dislikes of Web Forms, by the way. You do something like <asp:Label Id="lblName" Runat="Server"/> so you can populate a label in the code-behind, and it gets served up as <span id="lblName"> - or in the old days, more likely, something like <span id="ctl00_ucHeader_lblName">. So unnecessary, personally I wish that instead of the Runat="Server" attribute, they had designed something along the lines of ServerID="lblName" which both identified a control as being server-side and assigned a server-side ID which was separate to the client-side ID (if any).

Ultimately, you can work around most of this to some extent, but if you use Web Forms in the fashion in which it is designed to be used, you will get some weight added to the HTML you serve which is not strictly necessary.

However, I think that the difference in weight between a Web Forms page and a page produced by some other platform and framework is probably less than the difference between a poorly coded page and a well coded one which makes good use of clean semantic markup, minimizes unnecessary tags and attributes, uses clean unobtrusive JavaScript, etc.


ASP.NET as you have indicated does use the ViewState. First of all I'm going to briefly explain the purpose of the ViewState and why it is there.

What is the ViewState

In a nutshell, the purpose of the ViewState is to preserve the value of form fields between postbacks. From that statement, you can infer then that the more fields you have, the larger your ViewState is going to be.

In addition to preserving the value of form fields between postbacks, you can also store arbitrary data inside of the ViewState, by using ViewState[key] = value.

You can, however, disable the ViewState, either on a page level or element level where it is not appropriate to use. This can also save space in the ViewState.


The ViewState is stored as a hidden form element that is posted to the server when you submit the page. The following diagram demonstrates the key points in ViewState processing:

asp.net viewstate
(source: microsoft.com)

The key points here are LoadViewState and SaveViewState. LoadViewState loads the data posted to the server, where SaveViewState serialises it for storage in the ViewState after page events have been processed.


The primary advantage of using the ViewState is to persist data between page loads. For example, when the page is first loaded fields may be populated with the results of, for example, a long running database query. Subsequent loads can use the values in the ViewState to save re-executing that query.

Relation to ASP.NET MVC

ViewState is not at all relevant to ASP.NET MVC and is a component of ASP.NET Web Forms.

Equivalent in PHP?

There is no equivalent in PHP. You could manually implement the functionality if you so desired by serialising for example your model and reloading it on POST.

Do you have to use the ViewState

No, you don't. If you turn it off, your page output size will decrease but you will also need to factor in the overhead of reloading data.

TL;DR and to the question

Will the difference between the size of PHP pages and the generated HTML of ASP.NET pages be dramatic?. The answer is it depends on what you are outputting. If you are making massive forms and particularly if you're making use of controls such as Asp:DataTable then yes, your output could be significantly larger. I've seen ViewStates grow to over 1mb. You need to bare in mind that on each submit, the entire ViewState has to be uploaded to the web server. If you're producing small and simple forms, the size difference is going to be negligible. YMMV depending on what it is exactly that you're doing.

The other thing to bare in mind is that in PHP you have a lot more control over the generated markup than what you do with WebForms.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.