Total votes: 0
Print: Print Article
Please login to rate or to leave a comment.
Published: 21 Mar 2011
Download Sample Code
This article will bring you several SEO policies in terms of ViewState in ASP.NET.
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.
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
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 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
Next, let's continue to look at the screenshot with the ViewState removed, with the help of the above two overridden methods –
Figure 4: 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
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)
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
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
For the second Label control, set its
EnableViewState property to
false (the default value associated with all related controls is
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
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”
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 - 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:
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”
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.
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.
Please login to rate or to leave a comment.