If you've built any reasonably sized website, I can all but guarantee that someone will utter the immortal words "Can this work a bit quicker?". You'll then spend days/weeks/months doing just that so, over the coming weeks I'm going to write a series of blogs to help with this. Each blog will work on a different area and today's area is page size.
From experience, I've found that this is one of the biggest factors (well, at least in terms of client performance). The smaller the page, the faster it is to download, the faster it is to render, it's just plain faster!
So, how do you go about reducing page size? Here's a few options...
UpdatePanels / AJAX / PageMethods
Well, firstly, use AJAX calls or UpdatePanels whenever possible. Both will only cause a small portion of your page to be sent to the client, rather than the whole page. This has a dramatic improvement. If you use UpdatePanels then you'll still have the overhead of the page life cycle but, if you use AJAX calls or PageMethods (which are just ajax calls) then you'll avoid this so it'll be even quicker.
Remove ViewState
If you ever view the HTML that an ASP.NET WebForms page produces, then you'll see a hidden field with the name __VIEWSTATE which will consist of a huge string. This string is how WebForms maintains state but, by passing it to the client each time, the size of the page is a lot bigger than it needs to be. So, we can do two things here, firstly, disable ViewState where ever you can. On every WebControl there's an EnableViewState property, setting that to false will disable ViewState for that control. Secondly, we can store the ViewState on the server rather than sending it to the client. Whenever I do this, I usually store the ViewState on the Session object. There's a few articles that will tell you how to do this, personally, I'd suggest reading this one before you start coding anything though: http://www.hanselman.com/blog/MovingViewStateToTheSessionObjectAndMoreWrongheadedness.aspx
Client IDs
If you're using ASP.NET 4.0 then you have the option of changing the ClientIdMode. This is a new feature and essentially lets you specify the exact ID of server controls when they're rendered on the client. In previous versions, if you had a control with an id of "example", then assuming it was the only control on the page, it'd be rendered with the id of "ctl00_example". If you then start getting nested controls you'll get the id of "ctl00_parentId_childId_example", as you can imagine, in large systems these ids can get pretty large, pretty fast. In .NET 4.0, you can set the ClientIDMode property of the page to be "static". When this is done, all the IDs will be rendered on the client with the id that was actually set on the server. So, if we had a control with an id of "example", then no matter where it was rendered, it'd always have the id of "example". No extra characters to make it unique. Obviously, you have to be a bit more careful when deciding on the IDs of your controls, you don't want any conflicts but just by changing that property, you can save yourself a significant amount of space.
Disable EventValidation
I'm a little reluctant to suggest this one but I'll mention it anyway. Essentially, on the Page object, there's a property called "EnableEventValidation". When set to true (which is the default), it'll validate any postback and callback events for invalid data. So, for example, it'll ensure that the value sent back for a DropDownList is actually present within the list and it'll ensure you're not trying to postback a value for a control that isn't visible. To help it do this, it sends data to the client in the form of a hidden field called "__EVENTVALIDATION". If you check the HTML of your page, you should be able to see it. Obviously, this takes up a few extra bytes that aren't strictly needed so, if you disable it, this hidden field disappears and your page size gets a little smaller but if you do this, I seriously suggest you re-implement the validation on the server. For more information regarding event validation, check out the MSDN article about it.
Minification
External javascript files and CSS files are also sent across the wire and can affect how responsive your site seems. To help with this, most files can benefit from being "minified". By this I mean that you'll give a tool a script, it'll strip out all the white space. It'll rename all the local variables into a one letter equivalent and essentially, it'll get rid of absolutely everything that isn't necessary, leaving you with the smallest possible file. There are plenty of tools out there that'll do this for you, for free. A quick google search revealed a few: Microsoft Minifier, Minify CSS
Image Size
Images are by far and away, the biggest files that'll be requested by a client on any normal web page request and if you don't try and optimize these, it makes all the above points a little pointless. Most images are bloated, they contain a lot of information that simply isn't needed and can be removed with no loss what so ever to quality. Yahoo's Smush It! is an excellent tool for image optimization and I strongly suggest you use it. You simply give it an image, it takes it, strips out all the unnecessary stuff and returns the smaller image, with no loss to quality. It's an excellent tool and should be a bookmark on every web developers computer.
Well, that should get you started. If you follow the above then you should see a dramatic decrease in your page sizes and hopefully, an increase in performance. In my next blog I'm going to talk about implementing loss-less HTTP compression using GZip and Deflate. These will decrease your page size even further!
No comments:
Post a Comment