I don't know how many of you had the misfortune to do SEO work on web sites built with ASP.NET WebForms. I did.
WebForms based web sites tend to grow a huge hidden field called ViewState. It's meant to serve a purpose, but most of the time is useless or much, much bigger than needed, even Megabytes (I'll digress more at the end for those interested).
ViewState Viewer, details tree view
When auditing an ASP.NET WebForms based site, one of the first things I do is checking the ViewState size all over its pages.
There are several browser plugins to read its size and inspect it, but I missed a tool to give me an overall view. “Wait a minute, I'm a software producer of a popular SEO spider, and I can code...” That's how the feature was born.
ViewState size and page percentage are useful indications
First thing to watch is the page ViewState size. Rule of thumb is: the smaller, the better. For a content-only page, ViewState is normally useless and should be reduced to a bunch of bytes (you can also disable it completely for the whole page, but there normally are a few elements in the boilerplate which might need it).
Example of a site with a huge ViewState (~400KB), impairing its performances.
For pages with forms – that's the scenario for which ViewState and Postback have been conceived – it's normal for the ViewState to be bigger, but its size has to be kept to a functional minimum. This is especially true when dealing with interactive tables, where – mostly unknown to the programmer – the ViewState keeps a version of all cell values, and can become huge.
“ViewState viewer” makes not only easy to understand the ViewState absolute and relative size, but also to locate which part of the page content is duplicated within the hidden field without a need.
Custom Filters: query ViewState size over the entire site
So, we now have a great tool to quickly inspect each page ViewState over the entire site, but how to know which pages exceed a certain size, and have better be inspected first?
Here a “Custom Filters” comes to rescue, with a brand new property “ViewState size” to be queried. It just takes a single line to find all pages exceeding a threshold.
The new queryable property let you find all pages whose ViewState exceeds a certain size
Once all suspect pages are listed in Tabular View, it's easy to go through them all with the “ViewState viewer” tool open.
To the best of my knowledge, there's no other tool to permit having a holistic view of ViewState size over an entire site. The viewer itself is a fine piece of software.
Tools are meant to save people time, and we believe this release will be greatly welcomed by those working with ASP.NET WebForms websites.
For a full and boring list, please consult the official Release Notes.
So, if you are hitching to see where your WebForms site is paying an excessive load, don't waste time: launch Visual SEO Studio 'IcePatrol' now!
Digression for web programmers
ASP.NET is not a CMS, it's a development environment to build web applications.
When ASP.NET WebForms was introduced, it brought many good things to replace the old ASP (a modern programming language, a solid class library, more modern tools...), but also a stupid programming model.
Back at the end of the last millennium, MS had a wide base of VB programmers whose main programming language was going to be dismissed, and a gap to fill in the market of web development. ASP.NET WebForms programming model was conceived to mask the stateless nature of web development to those VB programmers, giving them the impression to work on a stateful environment like the Visual Basic apps they were used to. So the primary goal was not producing nice and light HTML code, easy to maintain, and efficient web applications. It was to recycle millions of VB developer who had little knowledge of how web development works, and have them build web applications with a visual IDE.
How did they do? To make a stateless environment like HTTP look stateful, they invented “postback” and “ViewState”. A postback is simply a HTTP POST method of a web form pointing with the action attribute to itself; previous fields state is stored in a hidden field named “__VIEWSTATE” as a Base64 encoded string describing all field names and previous values. Once on the server side, the state ViewState is decoded to understand what actually changed, programmer's functions are executed, and the web page is build again with a new ViewState. The process could re-iterate several times, as potentially any change to a form fields could cause a postback.
Can you see the design flaws here?
The proposed programming model encourages an increased number of HTTP POST requests back and forth (keep in mind a modern best practice in web programming would be having a redirect straight after a POST to avoid repeated accidental requests), and makes really hard to keep the page size under control. The generated HTML could have made hair raise to a bald man, all absolute positioned inline to let programmers use drag'n'drop placement with their IDE as they were used to, and – mostly – the ViewState field (unknown to the unaware programmers) could easily become Megabytes huge.
I well remember in 2000 (.net technology was still in Beta, but ASP.NET was marketed as production-ready) when at a Microsoft event a MS employee - a VB developer - illustrated how he had been able to produce a simple web applications which looked like the VB desktop apps he was used to build. He had the web server on the same local machine and the response was with no latency (no scrollbars were needed for the tiny example he gave); to me was clear the poor guy had no idea what he was doing, where things were taking place. People kept clapping hands, pointing out the flaws would have meant being publicly flogged as “against progress”. It took years before MS corrected the trend with a nice “rails” web development environment, “ASP.NET MVC”, working with which is a pleasure.