在Web开发中一起缩小JavaScripts时,从用户加载时间的角度来看,它是否更好:
我对一些数据感兴趣,以决定采用哪种策略。我可以像其他人一样轻松地根据轶事得出结论: - )
答案 0 :(得分:16)
这实际上取决于脚本的大小和功能。对于您的所有页面都有一个 master.js 是很常见的,其中包含站点每个页面所需的所有功能,同时还有其他js文件用于某些页面上可能只需要的功能。
例如,采用Stack Overflow。他们在网站的每个页面上都包含 master.js 文件,但是当您访问问题页面或“询问问题”页面时,您会注意到 wmd.js 。该脚本包含编辑器的所有功能,这些功能在较少的页面上是必需的。
答案 1 :(得分:5)
我宁愿为整个网站提供1个缩小的js文件。在一段时间内,这总是比拥有多个js文件更好。
查看此link了解详情
答案 2 :(得分:2)
完全取决于脚本中的内容。如果您有大量小功能,这些功能被广泛的页面选择使用,那么单个文件将是最佳选择。如果您有一个仅由一个页面使用的大型脚本,您通常不希望通过将其包含在共享脚本中来减慢初始首页加载时间。
因此,您最终会得到的是折衷方案,在一个脚本中的所有页面之间共享基本功能,以及每页或每页组脚本中更复杂和特定的功能。进入整个选项2并且每页都有一个完全独立的脚本很少有益。
在一个文件中共享功能和单独的特定于页面的复杂脚本通常也更易于维护。
答案 3 :(得分:0)
如果您在ASP.NET MVC中实现网站,那么您可能会发现以下方法是最明智的,我一直在使用它。
列出项目中使用的所有JavaScript文件 - 在任何地方使用的文件以及许多或大多数页面使用的文件。这定义了您应该从母版页中包含的公共包。 MVC4的Bundle&缩小功能在那里具有魔力,你只需要列出它们。
JavaScript的其余部分通常用于本地使用,即仅在一个视图内,有效地实现视图。因此,它应该位于视图中,完全未压缩。
例如,我在视图中广泛使用AngularJS,因此每个这样的视图都包含自己的角度控制器和其他所需的本地元素。根据视图的复杂程度,它甚至可以拥有自己的一组指令,服务和工厂,尽管这些指令通常会进入一到两级的部分视图。
最重要的是,不要试图通过捆绑本地使用的JavaScript来增加自己的负担。捆绑最通用的东西,只在一个地方 - 产品的母版页。将本地JavaScript解压缩到使用它的本地文件中。这对性能没有实际影响,同时使代码更容易理解和维护。