2013-05-13 31 views

回答

2

的优点和缺点,陷阱是其他脚本捆绑solutions--你会想先减少,要注意脚本的顺序,以启动脚本类似;关闭另一个文件中的任何未关闭的脚本。

一个ASP.NET具体问题是调试/开发经验。如果你把你的脚本,它更难以找到在IE调试你的代码,脚本将有一台机器生成的名称看起来类似于其他框架生成&你的代码将被安葬在一个更大的文件脚本。

因此,我在后面的代码中注册我的引用,并将它们包装在ifdef DEBUG/endif和ifdef中RELEASE/endif(一定要在项目属性中定义一个RELEASE,如果使用这个技巧,它不会默认发生) 。在RELEASE版本中,我捆绑了所有脚本,DEBUG版本将这些文件分开。

而且每微软的建议,脚本捆绑最适合你需要在整个网站文件。如果您有一个带有A,B,C的多页网站,并且您的用户通常只访问其中的一个,那么捆绑A,B,C的文件将为用户提供2个额外的文件。我认为这是一个糟糕的微观优化,因为大多数应用程序都有很小的JavaScript文件,所以一个网站的JS捆绑的价值是没有足够的字节担心,除非你有很多的流量。

最后,服务器端ScriptManager不提供任何推迟脚本或动态触发客户端负载的方法(除了在UI之后加载脚本),我使用LAB.js以后动态加载脚本...这有时可以让你推迟一个脚本,直到你知道你需要它,并可能推迟永久加载该脚本。一旦你捆绑该脚本,它会被加载为每一个用户,如果他们变成需要它或不..

第2部分 另一种疑难杂症,至少对我来说,虽然您可以启用JS的缓存(没时间查看语法!),并且您还可以使用expires头在IIS级别启用缓存,但ScriptManager在新版本发布时不会帮助您“缓冲”缓存。理想情况下,脚本管理工具会诱使浏览器认为脚本位于随上次更新更改而更改的文件夹中,以便脚本可以在客户端缓存一年。

我希望我有信息上,如果脚本是服务器端cached--我猜他们不是。但是因为用户通常每天最多获取一次脚本 - 在我的服务器上它们似乎缓存了24小时,如果每次请求都重新生成脚本,则不会太有趣。最后,如果你正在使用CDN来处理像jquery这样的事情(取决于你是公共还是intranet),它是4.0和4.5版本,它可以更容易地告诉ScriptManager使用CDN和备用时间CDN下跌。

+0

非常感谢!您是否还可以放下一条关于ScriptManager组合脚本无效/何时被浏览器缓存视为有效的行?我的意思是,我可以确定在应用程序重新启动/部署后脚本会再次下载,另一方面,我可以确定这个大的组合脚本不会经常下载吗? – dragonfly 2013-05-13 18:01:39

+0

增加了第2部分,不幸的是,这正在进入我仍在学习的领域。 – MatthewMartin 2013-05-13 18:08:45

0

使用sumfile.js?N = {0}

其中{0}是多少OS建筑物