Published: 21 Mar 2011
By: Xianzhong Zhu
Download Sample Code

This article will bring you several SEO policies in terms of ViewState in ASP.NET.

Contents [hide]


According to Wikipedia, search engine optimization (SEO) is the process of improving the visibility of a website or a web page in search engines via the "natural" or un-paid ("organic" or "algorithmic") search results. SEO can be divided into two categories, in-site SEO and out-site SEO. Our main interest, in this article, lies in the former. The so-called in-site SEO is to use a normal, reasonable and adaptive approach to search engine to optimize the website. As far as the ASP.NET Webform based websites are concerned, one of the difficulties to tackle is around ViewState. This article will bring you several SEO policies in terms of ViewState.


The sample test environment in this article:

1. Windows 7;

2. .NET 4.0;

3. Visual Studio 2010;

4. Microsoft sample database Northwind.

What's ViewState

ViewState is a special structure closely relevant to ASP.NET Web Forms pages. With this structure, ASP.NET Web Forms are capable of maintaining their own state across multiple client roundtrips. The page-level state is known as the view state of the page. In Web Forms pages, their view state is sent by the server as a hidden variable in a form, as part of every response to the client, and is returned to the server by the client as part of a postback.

Figure 1: Roundtrips between the client side and server side around ViewState

Roundtrips between the client side and server side around ViewState

Listing 1 indicates the initial client-side state (we've added nothing on the page) for the file Default.aspx under the ASP.NET 4.0 case.

A well-known fact is many search engines have a clear limit crawled pages - only the first thousands of text content will be snapped, and when the first 2KB of your page's ViewState is mainly garbage your page is likely to be subjected to punishment. Under most real scenarios, the ASP.NET generated ViewState spam often exceeds more than 20KB, which will seriously affect the search engine including your Web pages. Hence, ViewState is peculiar thing that makes people happy and, at the same time, makes them worry.

To make clearer the ViewState concept, there is a good helper class in here helping you to find what is actually encoded in the __VIEWSTATE hidden variable on your ASP.NET Web Forms.

Till now, some new ASP.NET developers may come to an idea that since ViewState can seriously slow down the band traffic and are so SEO unfriendly, why cannot we easily disable passing ViewState related data to and from from the three following levels?

1. In the machine level through the file machine.config, set:

2. Or in the application level, set, in the file Web.config:

3. Or in the single-page level, set in the current page:

Or through the code way:

Apparently, the above actions are all too arbitrary. If we disable the ViewState data transfer so as to get rid of the related side effect, it may cause some excellent ASP.NET features unavailable on the page. Then, are there any compromising or better ways to deal with ViewState? The answer is YES.

Policy 1 – Not Generating ViewState

The first available way is to prohibit from generating the cumbrous string type=hidden name ="__VIEWSTATE" on the target page. However, this method can be used only when the page does not use ViewState. The following gives the typical steps.

First, create a custom HttpModule:

Although lengthy, the idea is apparent: when the target page is loaded we, with the help of the custom HttpModule, check the generated HTML code to filter the __VIEWSTATE stuff and get rid of it, and finally render the filtered HTML markups.

To use the above approach is simple. First, compile the above module into a .dll assemble. Then, reference this assembly in the target Web project. To do this, we need to modify the file Web.config, adding the following content in the System.Web configuration section.

Note to directly put the preceding HttpModule filer into use will result in all ASP.NET pages generating no __VIEWSTATE. Such a result is contrary to our initial wish. To leverage this approach in real cases you'd better research deeper into how to use multiple web.config files in ASP.NET environments.

Policy 2 - Persist ViewState on the Server Side

If you have a cool ASP.NET page, with a lot of gadgets on it showing a wealth of changes in response to user actions, then your ViewState size may come to or exceed 200KB. One of the approaches to defeat ViewState is to persist ViewState on the server side. In this way, the ViewState will not consume network bandwidth, so that the related access only occupies the server-side disk read time. To decrease the disk reading time associated with ViewState, we can also fall back upon the cache technique.

To achieve the above target, we can override the two methods of the class Page, as follows:

First, this code can be placed towards the specified page, or in the parent class of the page. Second, the above policy has no relation with Session. Because ViewState is saved on the disk on the server side, so even if the server is restarted, the client-side page state will not lose.

BTW, to leverage the above solution, you should first generate the path "/App_Data/ViewState". A recommendable place to do this is the Application_Start method of the file Global.asax.cs.

This ensures the system absolutely stable and reliable.

Let's look at the running-time snapshots. Figure 2 illustrates the initial screenshot.

Figure 2: The initial screenshot showing data in the table authors (using the sample database Northwind)

The initial screenshot showing data in the table authors (using the sample database Northwind)

The related markups in the file ViewStateOnServer.aspx looks like the following:

Since the above code is only the elementary GridView + SqlDataSource related implementation, it is no use making more explanation any more. The following shows the initial HTML source code rendered on the client side.

Figure 3: The initial HTML source code with ViewState enabled

The initial HTML source code with ViewState enabled

Next, let's continue to look at the screenshot with the ViewState removed, with the help of the above two overridden methods –LoadPageStateFromPersistenceMedium and SavePageStateToPersistenceMedium.

Figure 4: The overstaffed ViewState disappears in the client-side HTML code (not all removed)

The overstaffed ViewState disappears in the client-side HTML code (not all removed)

How do you think of the above solution? On the surface, the policy in this section is pretty good; in fact, there are many controversial aspects in this solution. But the deeper researching is also beyond the range of this article; cute readers can continue with the exploration.

In the next section, we'll examine another possible way to lessen the side effect of ViewState upon the system performance.

Policy 3 - Load ViewState as Late as Possible

This idea is easy to follow. Since the ViewState commonly leads to a large size of HTML stuff, we can load it as late as possible while don't let it blight upon the system performance. So we can place it close to the generated </form> tag. To do this, first try to locate the __VIEWSTATE and then move it. According to ASP.NET Web form lifecycle, the appropriate time to accomplish this is in the method Render.

The above idea is also easy to understand. First, define the regular expression corresponding to the ViewState related HTML tags. Next, override the method Render of the current Web page. In detail, first call the method Render of the base class to render normal HTML tags, and then locate the ViewState related HTML tags string and change its position to the bottom.

The following gives an example of moving ViewState at the end of the client-side HTML stuff.

Figure 5: ViewState moved to the end of the HTML content (Default.aspx)

ViewState moved to the end of the HTML content (Default.aspx)

A last word is, till now many famous websites have taken the above approach as one of the policies against ViewState.

Better Control over ViewState in ASP.NET 4.0

ASP.NET 4 introduces a bunch of new runtime features, such as the new MetaKeywords and MetaDescription properties of the class Page, improved URL routing support, and new Response.RedirectPermanent() method, with which your website will get optimized for SEO. However, all these new features will be delved into in another article – our main interest herein will only dwell upon the bettered ViewState related stuff in ASP.NET 4.0.

Although ASP.NET 2.0/3.5 provides support for the EnableViewState property, we cannot disable ViewState at a Page level and, at the same time, enable it for individual controls on that page that require it. By introducing a new ViewStateMode property, ASP.NET 4.0 gives more flexible control over that.

Let's next construct related examples and observe the differences.

ViewState in ASP.NET 2.0/3.5

Use Visual Studio 2010 to open the sample website AspNetSeoViewState, and then add an ASP.NET Web Form page named AspNet35ViewStatePage.aspx. Now, drag two Label controls and one Button control onto the page. Finally, disable view state on the Page level by setting the EnableViewState property to false.

For the second Label control, set its EnableViewState property to false (the default value associated with all related controls is true).

In the behind-code file, fill in the following code:

Now, let's look at the running-time snapshots. Right click the file AspNet35ViewStatePage.aspx and hit the item "View in Browser". Figure 6 shows the initial screenshot.

Figure 6: The initial screenshot

The initial screenshot

Apparently, the Page_Load event handler gets triggered and the preceding two statements are executed only one time.

Next, click the button "Start PostBack", and the subsequent screenshot appears, as shown in Figure 7.

Figure 7: The screenshot after clicking the button “Start PostBack”

The screenshot after clicking the button “Start PostBack”

As shown in the above figure, although ViewState is disabled for the entire page and Label2 should save ViewState and retain its new value 'Label2 Changed' after postback since ViewState is explicitly enabled on it. The fact is although hitting the button causes a postback, Label2 does not retain the value ('Label2 Changed') explicitly set on it. This is not as we expected!

New support towards ViewState in ASP.NET 4.0

Now, add another new Web Form page named AspNe4ViewStatePage.aspx. The only difference is that here we will use the new ViewStateMode property. According to MSDN, the value of the ViewStateMode property may be assigned with the three values: Enabled, Disabled, and Inherit.

  • Enabled - enables view state for that control and any child controls that are set to 'Inherit' or that have nothing set.
  • Disabled - disables view state.
  • Inherit - specifies that the control uses the ViewStateMode setting from the parent control.

Now, let's look at the related markup in the new file AspNe4ViewStatePage.aspx:

Note that ViewStateMode on the Page is set to Disabled. Since the child Label2 control has ViewStateMode set to Enabled, Label2 should save view state. On the other hand, since the ViewStateMode property is not set on Label1, it will inherit this property value from its parent (Page) and therefore will persist no view state.

Now, let's look at the running-time snapshots. Right click the file AspNe4ViewStatePage.aspx and hit the item "View in Browser". You will find the initial screenshot looks quite like the previous Figure 6. Next, click the button "Start PostBack", and you will find the subsequent screenshot appear, as shown in Figure 8.

Figure 8: The screenshot after clicking the button “Start PostBack”

The screenshot after clicking the button “Start PostBack”

You will note that when the page first loads, both the Label controls display the text as set in the code-behind file. However, after hitting the button and causing a postback, the control Label2 does retain its value as we expect.

On the whole, in ASP.NET 4.0 we can disable ViewState on a parent level while enable it only for those child controls that require it. Obviously, this will help to improve performance with lesser efforts and gives us more control.


For any public websites, search engine optimization (SEO) is drastically important. Because most of the network traffic comes from the website search engine, improving your website ranking in search engines can not only increase your site's traffic but also increase your revenue directly or indirectly through your website. In this article, we've only examined parts of the ViewState related SEO techniques in the ASP.NET Webforms environment. As for which one is better, different people have different views. All waits to be tested in practice.

<<  Previous Article Continue reading and see our next or previous articles Next Article >>

About Xianzhong Zhu

I'm a college teacher and also a freelance developer and writer from WeiFang China, with more than fourteen years of experience in design, and development of various kinds of products and applications on Windows platform. My expertise is in Visual C++/Basic/C#, SQL Server 2000/2005/2008, PHP+MyS...

This author has published 81 articles on DotNetSlackers. View other articles or the complete profile here.

Other articles in this category

Code First Approach using Entity Framework 4.1, Inversion of Control, Unity Framework, Repository and Unit of Work Patterns, and MVC3 Razor View
A detailed introduction about the code first approach using Entity Framework 4.1, Inversion of Contr...
Exception Handling and .Net (A practical approach)
Error Handling has always been crucial for an application in a number of ways. It may affect the exe...
jQuery Mobile ListView
In this article, we're going to look at what JQuery Mobile uses to represent lists, and how capable ...
Book Review: SignalR: Real-time Application Development
A book review of SignalR by Simone.
JQuery Mobile Widgets Overview
An overview of widgets in jQuery Mobile.

You might also be interested in the following related blog posts

SEO starting guide for ASP.NET read more
Digging into ASP.NET MVC - Part 2 read more
altnetconf - Scott Guthrie announces ASP.NET MVC framework at Alt.Net Conf read more
Entity Framework object graphs and viewstate read more
Entities, Viewstate and postback read more
Login control and ViewState on successful logon read more
Move the ViewState off the client and cache it on the server read more
ViewState Chunking in ASP.NET 2.0 (maxPageStateFieldLength) read more
Search Engine Optimization for .NET read more
Why does Forms Authentication Fail When Migrating from ASP.NET 1.1 To 2.0? read more


Subject Author Date
placeholder You may also check the WAO ViewState optimization Kristijan Horvat 3/21/2011 9:48 AM
Thanks Xianzhong Zhu 3/21/2011 6:36 PM

Please login to rate or to leave a comment.