Has anyone noticed how clumpy and verbose the source code is of some .NET generated .aspx pages are? I mean this can’t be good food for the stomaches of the major search engines, nor can it be good for download times. There is no point is creating a feature rich .aspx website in comparatively double quick time with an advanced IDE like visual studio 2005 which runs on an equally advanced framework like .NET 2.0 when that very same IDE and framework is causing so much code blote and badly placed code (much of it probably unnecessary) that it is likely hampering your positions in the search engines and/or causing people to leave your site before it is even fully loaded.
Of course the amount of bloat created depends on what type of pages your programming but often the end produced source code can be ‘cleaned up’ regardless of what controls, interfaces etc. you are using. It’s just a matter of knowing what to look out for really. One of the main culprits are as far as I can see is ASP.NET’s ViewState mechanism.
ASP.NETs ViewState is the built in mechanism which enables controls such as textboxes, labels, datasets etc. to maintain their states (data) between postback requests for the same page. It does this by hashing the current state of the page and controls into a string and saves this into a hidden field called __VIEWSTATE. At the server, ViewState is used to recontruct the web page and its server controls. This is fine and prevents an ASP.NET developer having to manually repopulate form controls using POST values like is the case with something like PHP, however it is not without a cost. Have a look below at the value of a hidden __VIEWSTATE textfield which was produced from a .aspx page with only a menu and treeview control on it.
‘/wEPDwUJMzg4NTE1Mzc4D2QWAgIDD2QWBAIDDzwrAAkCAA8WCB4NTmV2ZXJF
eHBhbmRlZGQeC18hRGF0YUJvdW5kZx4MU2VsZWN0ZWROb2RlZB4JTGFzdEluZ
GV4AgFkCBQrAAIFAzA6MBQrAAIWCB4EVGV4dAUJQ3VzdG9tZXJzHghEYXRhUG
F0aAUQLypbcG9zaXRpb24oKT0xXR4JRGF0YUJvdW5kZx4QUG9wdWxhdGVPbkR
lbWFuZGdkZAIJDzwrAA0CAA8WAh8BZ2QMFCsABQUPMDowLDA6MSwwOjIsMDoz
FCsAAhYKHwQFBEhvbWUeB0VuYWJsZWRnHgpTZWxlY3RhYmxlZx8FBSAvKltwb
3NpdGlvbigpPTFdLypbcG9zaXRpb24oKT0xXR8GZ2QUKwACFgofBAUIUHJvZH
VjdHMfCGcfCWcfBQUgLypbcG9zaXRpb24oKT0xXS8qW3Bvc2l0aW9uKCk9Ml0
fBmcUKwAEBQswOjAsMDoxLDA6MhQrAAIWCh8EBQxTbWFsbFdpZGdldHMfCGcf
CWcfBQUwLypbcG9zaXRpb24oKT0xXS8qW3Bvc2l0aW9uKCk9Ml0vKltwb3Npd
GlvbigpPTFdHwZnZBQrAAIWCh8EBQ1NZWRpdW1XaWRnZXRzHwhnHwlnHwUFMC
8qW3Bvc2l0aW9uKCk9MV0vKltwb3NpdGlvbigpPTJdLypbcG9zaXRpb24oKT0
yXR8GZ2QUKwACFgofBAUKQmlnV2lkZ2V0cx8IZx8JZx8FBTAvKltwb3NpdGlv
bigpPTFdLypbcG9zaXRpb24oKT0yXS8qW3Bvc2l0aW9uKCk9M10fBmdkFCsAA
hYKHwQFB1N1cHBvcnQfCGcfCWcfBQUgLypbcG9zaXRpb24oKT0xXS8qW3Bvc2
l0aW9uKCk9M10fBmcUKwADBQcwOjAsMDoxFCsAAhYKHwQFCURvd25sb2Fkcx8
IZx8JZx8FBTAvKltwb3NpdGlvbigpPTFdLypbcG9zaXRpb24oKT0zXS8qW3Bv
c2l0aW9uKCk9MV0fBmdkFCsAAhYKHwQFBEZBUXMfCGcfCWcfBQUwLypbcG9za
XRpb24oKT0xXS8qW3Bvc2l0aW9uKCk9M10vKltwb3NpdGlvbigpPTJdHwZnZB
QrAAIWCh8EBQdBYm91dFVzHwhnHwlnHwUFIC8qW3Bvc2l0aW9uKCk9MV0vKlt
wb3NpdGlvbigpPTRdHwZnFCsAAwUHMDowLDA6MRQrAAIWCh8EBQdDb21wYW55
HwhnHwlnHwUFMC8qW3Bvc2l0aW9uKCk9MV0vKltwb3NpdGlvbigpPTRdLypbc
G9zaXRpb24oKT0xXR8GZ2QUKwACFgofBAUJTG9jYXRpb25zHwhnHwlnHwUFMC
8qW3Bvc2l0aW9uKCk9MV0vKltwb3NpdGlvbigpPTRdLypbcG9zaXRpb24oKT0
yXR8GZ2RkGAEFHl9fQ29udHJvbHNSZXF1aXJlUG9zdEJhY2tLZXlfXxYBBQlU
cmVlVmlldzGl0+HS1X8B5jfomTSld5U3ULhXjg== ‘
Obviously if I was to add more controls this value would grow accordingly. ViewState is enabled for all controls by default, luckily though ASP.NET has made the EnableViewState property available for setting true or false on a control by control basis and thus you can disable it for certain controls which you might never change like a label or a readonly datatable which might be populated from an external source such as a database or an XML file. For example below is the value of the same __VIEWSTATE hidden field (from above) with EnableViewState set to false for the menu control which gets populated from an XML file when the page loads and thus its state will not change between requests/postbacks.
‘/wEPDwUJMzg4NTE1Mzc4D2QWAgIDD2QWAgIDDzwrAAkCAA8WCB4NTmV2ZXJ
FeHBhbmRlZGQeC18hRGF0YUJvdW5kZx4MU2VsZWN0ZWROb2RlZB4JTGFzdEl
uZGV4AgFkCBQrAAIFAzA6MBQrAAIWCB4EVGV4dAUJQ3VzdG9tZXJzHghEYXR
hUGF0aAUQLypbcG9zaXRpb24oKT0xXR4JRGF0YUJvdW5kZx4QUG9wdWxhdGV
PbkRlbWFuZGdkZBgBBR5fX0NvbnRyb2xzUmVxdWlyZVBvc3RCYWNrS2V5X18
WAQUJVHJlZVZpZXcxU1/1MUWW6NZaM/KXGnbkTXRYJ3w=’
That’s quite a difference right? And because the control does not change between requests/postbacks the page works exactly as before. Disabling the ViewState for the treeview control would further reduce the contents of the __VIEWSTATE hidden field, it too is populated from an external data source and thus does not require ViewState enabled. Therefore to reduce filesize and keywords to source ratio for SEO purposes turn off viewstate for each control which will not change between multiple requests for the same .aspx page. You can find the biggest ViewState contributors by examing the ‘Control Tree’ section of the trace.axd file. You need to have first enabled tracing of course.
Additionally the usual good practice of using external .js files rather than in-source embedded code will further reduce unneeded bloat and allow your .js file to be cached which should enhance download times.
Aside from generally cleaning your code up there are some other steps of optimisation which can be taken too. Specifically in terms of search engine optimisation an interesting feature of ASP.NET 2.0 is URL mapping. This allows a defined friendly URL such as akamarketing.com/televisions.aspx to be mapped to a complex SEO unfriendly URL such as akamarketing.com/store.aspx?productid=202030&basket=303303&name=television. This means that the actual URL which is the long complex one can be accessed from the shorter SEO friendly one. The original URL will of course still work too. From a programming point of view everything is exactly the same which means all the GET query parameters in the URL are still available. From an end user and search engine perspective the URL is much more friendly and spiderable. Additionally the improved keyword density in the shorter nicer URL versus the longer complex one should facilitate ranking boosts on MSN which deems keywords in URLs to quite significant and it should certainly help on the other major search engines such as Google and Yahoo too.
URL mappings must be manually defined in the web.config file, so if your adding dynamic content including new products, categories, articles etc. to your website/database a lot you will have to manually add a new mapping entry into the web.config file for each item you wish to be accessible via an SEO friendly URL. The entries follow a standard layout though so I’m sure a script could be written which examines your database and outputs the relevant mapping XML code which you could then simply copy and paste into the web.config file, infact I may write one myself over the next week or so if I get the chance. The format itself is shown below.
As you can see the individual mappings must come between opening and closing tags of the urlMappings element and this element in turn must be included within the system.web element of the configuration file.
Moving on then let’s mention page titles. Not suprisingly ASP.NET provides you with the ability to dynamically change the content of a webpages HTML title tag - you know the one at the top of the browser which Google, Yahoo and MSN love to see your keywords in. It is very important that what’s included in this tag reflects your page content specifically, having something generic just won’t do. When your content is being read from a database (ie - it’s dynamic) the title tag will need to be set dynamically at runtime based on the current content item. There are a number of ways to do this, however the most simple is to access the title property of the HTML header and update it as needed. Before you can access a pages header programatically you have to set it to run on the server side by including the runat=”server” directive in the pages opening HTML head tag. To then access the title tag it is a simple as Header.Title = “new title value”; Of course in a live website you would set Header.Title to some database derived value.
In addition to the pointers above the usual common sense SEO techniques such as good content, good structure and good navigation of course still apply just as they would for any webpage or website, so try not to get completely caught up in the ‘power’ of ASP.NET while at the same time disregarding the cornerstones of SEO as you’ll most likely find yourself stuck in a bit of pickle.
