Improving front-end website performance in ASP.NET MVC
Load times, according to people like google, are important. I kinda see it as basic politeness; wasting a user’s (or worse, a customer’s) time making him wait for my site to become active is a bit rude. According to YSlow! (a Firebug plugin within Firefox), one should:
- Reduce the size of external requests (less on-the-wire weight is better; remove comments and white-space).
- Compress external requests where possible (gzip/deflate compression will trade CPU cycles per request to gain better on-the-wire weight).
- Use a far-future cache-header for assets that won’t change often (so that clients don’t need to receive a new copy on each visit).
- Move scripts to the end of the document so the content loads first – the user has stuff to look at while scripts arrive.
Lastly, do this stuff at run-time, because maintaining config or build-automation to do it would save some CPU cycles at the expense of developer time (can you spot someone that’s been burned by that kind of thing…? :-P ).
I’m going to be doing this within the context of ASP.NET MVC (and maybe fiddle with Spark’s modularity feature once it’s done). My list of features:
- Register an include (from both the master-page and the views).
- Write out the include-combination (or, in debug mode, write out each include separately, raw and untouched).
- Combine the includes within the set that is registered (glue the files together – and, necessarily, read the files from where-ever they live!).
- Make it possible to link to the combination (a controller with actions to respond with the combination when tickled via an appropriate GET)
- Minify the combination.
- Compress the combination (gzip/deflate – and detect which browsers we shouldn’t do this for – I’m looking at you, IE<=6, you lying so-and-so…).
- Cache the combination with a far-future expiry (and therefore also use a URL amenable to browsers caching it).
- Generate an ETag.
- Support a debug-mode where the includes are written out one-by-one and raw.
- Be trivial to understand and add to your own application :-)
I’ll host the source in github, and blog as I go.
Some more references for front-end performance:
- CSS @import considered harmful: http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
- Hammerhead (another Firefox extension): http://www.stevesouders.com/blog/2008/09/30/hammerhead-moving-performance-testing-upstream/