减少 ScriptResource.axd 的激进技术？ （以及可选的 WebResource.axd）
场景：我有一个复杂的 Asp.net 应用程序，通过 HttpModule 中以编程方式构造的控件集合为各个单元提供服务。其中一些控件使用 Asp.NET Ajax。
在许多不同的单元中，ScriptResource.axd 的平均传输大小约为 27k。
我的上限只允许~3k。
绝对没有时间用 jQuery 或手动 js 函数或诸如此类的东西来改造所有 Ajax 功能。我们已经有了 gzip 编码的 .axd（未压缩的它更像是 97k）。它经常被缓存，但这并不重要：我必须对首次请求总传输大小达到严格的、低的、外部施加的限制......标记、脚本、图像和数据。所有这些都总结为a-la firebug。我一直在避免使用 .axds，但确实没有其他地方可以削减字节，而且我还有 24k 空间。
有什么想法吗？我沉了吗？
可能的方法：我还没有使用 Asp.NET 3.5 SP1 的 compositescript 功能，但我认为这只会节省请求/响应标头，而且我什至没有使用某些标题对我不利。
除了一些激进的想法之外，我没有任何其他想法，比如创建一个使用反射和过滤的响应过滤器。一些字典来找出实际上需要的js函数，并且只发出这些函数。我可以缓存每个单元的结果列表，因为我的响应时间上限也很低，而且我不认为 .axds 从一个请求更改为另一个请求。这可行吗？还有其他想法吗？ ...如果我用解决方案给英雄买啤酒怎么办？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
反思可能是个好主意。另外，寻找很少使用的部件，并找到其他方法来解决它或在没有该功能的情况下进行操作。另外，尽可能压缩 Ajax 脚本（YUI Compressor 对于 JavaScript 效果很好）。
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).
我完全赞同安德鲁的评论。不过，从配置的角度来看，您应该做两件事。
Gzip（你已经完成了）
脚本模式=释放（这将消除空格）。
除此之外，还有一个选择...那就是根本不使用 Microsoft AJAX 库。您可以选择编写自己的 Ajaxification 库并仅使用您想要的内容。仍然存在的问题是……值得痛苦吗？如果是的话，就去吧。但请记住，编写自己的库的很多痛苦并不是因为它很难编写。真正令人头疼的是维护你编写的内容，在所有可用的平台上测试它，并修复错误......重新测试......等等......你明白了！
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!