Jim Zimmerman - ASP.NET, MVC, Ajax and ORM

Recently we noticed that our site was a little sluggish.  Now of course when we started to look at why it was slow sometimes and not others, we opened up a huge can of worms.  Was it our code?  Was it our server?  Was it our proxy server?  Was it our database?  Was it our graphics?  Was it the JavaScript?  Or was it just that the end user had a slow connection?  Well it was all of them. 

Sometimes we forget that not everyone has FIOS.  We are very lucky to have a 20 Mbps / 20 Mbps connection at work.  So first thing we did was to look at the size of our pages when downloading the html, CSS, images and JavaScript.  We were shocked at the size of the files.  The first eye opening fact was that our home page was 1.5 MB.  Whoa.  The best tool that we found to figure the details out was YSlow.  Here is a snippet from their site about what the tool does:

YSlow analyzes web pages and tells you why they're slow based on the rules for high performance web sites. YSlow is a Firefox add-on integrated with the popular Firebug web development tool

This tool saved us so much time figuring out what our issues were.  I highly suggest reading the rules.  Also you can listen to a recent podcast from DotNetRocks: YSlow! Steve Souders finds Website Bottlenecks

So we began the process of optimizing the client.  The first thing you can do is to compress the JavaScript, CSS and html files on the server to reduce the file download size up to 75% on the client.  The way to do this in IIS6 is to enable GZip compression.  This is turned off by default which I think should actually be turned on by default.  Here is some info on how to enable it for specific file types.  Don't forget the .axd files if you use and Ajax in webforms.

So next on our list was minimizing the size of the images that we were using as backgrounds in CSS.  They are the first calls from the browser when loaded from CSS.  Also moving JavaScript references to the bottom of the page helps.  The browser using a blocking request when loading JavaScript files, so if you have them at the top of the page, you will get a perceived load issue since the browser waits for that first.  The best thing to get out of optimizing for the client is the perceived load to the user which really makes the most difference.

So after removing the client side issues we realized we had a database load issue on certain pages with many records.  Well we found out we ran into the famous ORM gotcha of way too many queries when using strictly the data objects with related foreign key objects.  For instance, by relating a member record to the aspnet user table and doing a foreach on the member and then checking to see their username on the aspnet user table, it will cause another db query to get that info for each user.  Sometimes when using the orm objects that are generated instead of writing a custom query to populate your own domain object, you can get into a lot of trouble.

Our website has many applications to it, some mvc and some using webforms.  We have noticed a significant speed increase on the mvc sites.  There is less code to render and there is no Viewstate so right away there is some performance increases. 

I hope that this helps some other people figure out why their site is slow for some people some of the time.