Radical techniques for reducing ScriptResource.axd? (and optionally WebResource.axd)

Question

Scenario: I have a complex Asp.net app serving various units through programmatically constructed control collections in HttpModules. Some of these controls use Asp.NET Ajax.

Across many different units, ScriptResource.axd averages a transfer size of ~27k.

I have a ceiling that only allows ~3k for it.

There definitely isn't time to retrofit all the Ajax functionality with jQuery or hand-rolled js functions or whatnot. We already have the .axd coming over with gzip encoding (uncompressed it's more like 97k). It's often cached, but that doesn't matter: I have to hit a hard, low, externally-imposed limit on first-request total transfer size... markup, scripts, images & all summed up a-la firebug. I've been avoiding the .axds, but there really isn't anywhere else to shave bytes, and I have 24k to go.

Any ideas? Am I sunk?

Possible approaches: I'm not yet using Asp.NET 3.5 SP1's compositescript functionality, but I figure that would only save on request/response headers, and I'm not even sure headers count against me.

I don't have any other ideas other than something radical, like creating a response filter that uses reflection & some dictionaries to figure out what js functions are actually needed, and only emit those. I could cache the resulting list for each unit, since I have a low response time ceiling as well, and I don't think the .axds change from one request to another. Is this feasible? Any other ideas? ...what if I buy beer for the hero with a solution?

Answer 1

Reflection is possibly a good idea. Also, look for parts that are rarely used and find another way around it or operate without that functionality. Also, compress the Ajax scripts as much as you can (YUI Compressor works well for JavaScript).

Answer 2

I totally second Andrew's comment. There are two things that you should do from configuration perspective though.

Gzip (which you have already done) Script Mode = Release (which will get rid of white spaces).

Other than that, there is one more option... and that is to NOT use Microsoft AJAX Library at all. You may choose to write your own library for Ajaxification and use only the things that you want. The question that would still remain is... is it worth the pain? If it is, go for it. keep in mind though, that a lot of pain with writing your own library is not that it is difficult to write. The real headache is to maintain what you write, test it on all the platforms that are available, and fix the bugs... retest...and so on... you get the idea!