asp.net website optimization for static resources- development vs production deployment - serving static resources from subdomain

Question

I have been looking into optimizing a website and specifically looking into CSS sprites, and serving static resources from a subdomain (static.mysite.com). Reference: Split Components Across Domains

We are using cassini (which comes with visual studio) for development and it does not support subdomains. My static resources are contained in the folder www.mysite.com/Contents/Static/.. This works for both cassini and IIS7.

If I should move these static assets to static.mysite.com, without making much changes in my codebase (references to js/css/images),what would be the most optimal way to do it ?

My concern is the fact that cassini does not support subdomains makes me think I should have 2 code bases ? Or I should somehow change my references to static assets in code base from mysite.com/contents/static to static.mysite.com during the build? How do you guys go about it ?

PS:On a side note, it would be nice if you guys can point me to good asp.net performance tuning articles (though google search helps)

Answer 1

My first question is... why are you using Cassini at all? Why not develop against the server you're actually using?

Two code bases is a horrible idea...

Unless you're actually serving resources from two different machines, you are not going to see a performance change between www.mysite.com/contents/static and static.mysite.com. Just not going to happen. I've generally found Yahoo's perf advice to be pretty good... but this one is just silly.

Answer 2

This kind of becomes a question about your development environment and developer workflow.

Cassini is fine in your dev-env so long you eventually system/user-acceptance test against the target webserver that is used in the production environment.

If you'd like to stick with Cassini, I'd go for a separate webserver, such as lighthttpd, for serving static content during development. Once you have it serving from the correct document root, you can pretty much forget about it.

Alternatively, if you are open to running IIS then you could quite easily shift off Cassini.

As for static content references in your code, the general approach is to build up the absolute URL for each static resource using a variable from your masterpage (or config). I wouldn't recommend any string substitution at build/deploy time.

Answer 3

What you probably want is a completely different domain name altogether. For example, Google uses "gstatic.com" and Facebook uses "fbcdn.net" to serve static content. Cookies between subdomains may be shared and unnecessarily sent/received to/from the subdomain serving static content thereby adding overhead. You do take a DNS lookup hit at the browser level but it's worth the reduced overhead from serving static content from a cookie-less domain.