捆绑和缩小ASP.NET

时间:2017-10-13 10:48:48

标签: asp.net asp.net-mvc bundling-and-minification

我有一个庞大的Web应用程序,可以捆绑和缩小大量的javascript和css文件。

当我们发布新版本时,我们注意到在每个页面(控制器+视图)的第一个请求时,软件需要花费大量时间来响应。所以,我开始搜索一下并发现Bundle Caching,当一些.js或 .css 文件发生变化时,该捆绑包将创建一个新令牌。但我对此有些怀疑:

  1. 何时完成文件的连接和缩小?是第一次在视图上调用它时?
  2. 有可能在构建软件时,文件将在该过程中加入和缩小,因此当第一次调用虚拟路径时,此过程已经发生并且缓存?
  3. 如果关于我的应用程序的慢慢问题不是文件的捆绑和缩小,可能是什么?
  4. 谢谢。

      

    注意:我在谈论生产环境中的流程。所以,   想把debug=false放在我已经拥有的web.config中。

2 个答案:

答案 0 :(得分:1)

1)我不打赌这个,但我很确定这需要提前完成,前提是捆绑包的版本作为查询字符串参数附加到路径中。由于此值是bundle结果的哈希值,因此需要在下载任何bundle之前完成此操作,以便ASP.NET在执行以下操作时甚至能够添加此参数:

@Url.Content("~/bundles/yourbundle")

是否第一次将捆绑网址呈现到视图中或在应用启动时计算是我不知道的事情。我仍然发布这个答案,因为我相信我可以为2)和3)点提供有用的信息。

2)可以预先捆绑文件。您可以使用一些Gulp或Grunt任务,使用Bundler & Minifier扩展程序或您喜欢的任何工具。但是,在这种情况下,您不需要(甚至建议 1 )使用虚拟路径,因为这些工具会生成物理文件。但是,您需要确保自己的版本正确,因此无论何时更改某些输入文件,客户端都将被强制下载新文件而不是使用缓存中的文件。

3)请记住,C#未编译为机器代码。最初的缓慢可能并且通常是由称为JITting的东西(更详细地解释here)引起的,即将IL代码转换为机器代码的过程。这是一个相当懒惰的过程,因为它基本上发生在实际执行代码之前。例如,如果您有方法A,则在实际调用之前,它不会转换为机器代码。因此,每个控制器/操作的第一次访问都比后续访问慢(因为在第一次运行后,保留了生成的机器代码)。

您还可以configure your project to compile your views这会使您的应用程序稍微加快,但代价是使构建过程变慢。

1 如果文件实际存在于磁盘上,建议使用物理路径,因为这样,您可以完全跳过虚拟路径解析过程,从而使脚本加载有点更快。

答案 1 :(得分:0)

通过在Web.config文件中的编译元素中设置debug属性的值来启用或禁用捆绑和缩小。在以下XML中,debug设置为true,因此禁用了捆绑和缩小。+ XML

<system.web>
    <compilation debug="true" />
    <!-- Lines removed for clarity. -->
</system.web>

要启用捆绑和缩小,请将调试值设置为&#34; false&#34;。您可以使用BundleTable类上的EnableOptimizations属性覆盖Web.config设置。以下代码启用捆绑和缩小,并覆盖Web.config文件中的任何设置。 C#

public static void RegisterBundles(BundleCollection bundles)
{
    bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
                 "~/Scripts/jquery-{version}.js"));

    // Code removed for clarity.
    BundleTable.EnableOptimizations = true;
}

除非EnableOptimizations为true或者Web.config文件中的编译元素中的debug属性设置为false,否则不会捆绑或缩小文件。此外,将不使用.min版本的文件,将选择完整的调试版本。 EnableOptimizations会覆盖Web.config文件中编译元素中的debug属性