为什么内联 JavaScript 不好?

IT技术 javascript 表现 dom事件 不显眼的javascript
2021-02-23 09:26:14

始终建议通过将所有代码放在一个JS文件中来避免内联 Javascript 代码,该文件包含在所有页面中。我想知道,如果这不会导致重页的性能问题。

例如,假设我们有几十个这样的函数

function function1(element){
var el=document.getElementsByClassName(element);
var size=el.length;
if(size==0) return;
for(i=0;i<size;i++){
// the process
}
}

在每个页面上,我们都需要运行函数来知道 HTML 中是否有相应的元素。

window.onload = function(){
function1('a');
....
function26('z');
};

但是如果将所有函数保存在一个外部JS文件中,并通过 inline 调用函数JavaScript,我们只能调用当前页面中需要的函数:

<script type="text/javascript">
window.onload = function(){
function6('f');
};
</script>

从性能的角度来看,通过内联调用函数Javascript(这当然不是最佳实践)以避免调用页面中不需要的大量函数是否有益

当然,这不仅限于函数,因为我们有很多addEventListener用于整个网站s,它们在不需要它们的每个页面上都被触发。

6个回答

不建议内联静态资源(在您的情况下,内联 javascript),因为您无法缓存它们

缓存静态资源可以减少页面加载的大小——从而提高页面加载速度——供回访者使用。然而,这是以额外的 HTTP 请求为代价的,应该避免

当静态资源太小以至于与 HTTP 请求相比额外的大小可以忽略不计时,实际上建议保持该资源内联。

将 javascript 库保存在外部(可缓存)文档中,同时保持少量脚本内联通常是个好主意。

因此,响应您的标题– 内联 javascript 本身并不坏。是否值得一个 HTTP 请求来缓存资源是一种平衡。

在这种外部文件的情况下,它可以并行下载并通过像 cloudfront 这样的边缘缓存提供服务。因此,不内联的性能影响可以忽略不计,以至于它很少是一个好主意,因为它很混乱。
2021-04-20 09:26:14
这是否意味着如果我将所有 js 代码放入一个函数和一个单独的文件中,并且只是内联调用该函数,那么只会缓存该函数名称,并且与函数大小无关?或者如果函数定义很大就不好?
2021-05-11 09:26:14
这是一个非常好的答案。我刚刚和某人讨论过这个问题,我推断这是关于平衡的。有很多博客都说内联不好,但我不同意他们的推理。我使用了很多只能在一个页面上运行的内联代码段。更可重用的更通用的片段被放入一个单独的 js 文件中,该文件包含在每个页面中。
2021-05-12 09:26:14
虽然还有许多其他有效的问题,但这是问题的正确答案,也是迄今为止选择内联与外部时最具影响力的问题。
2021-05-14 09:26:14
为什么它不能缓存包括内联资源在内的整个文档?您是在谈论缓存以供重用吗?
2021-05-18 09:26:14
  • 避免内联 js 不是基于性能的......但它更多的是关于可维护性和将表示层(html)与控制器层(js)分开。

  • 随着项目规模的增加,在不同页面上使用内联 js 将使您和其他人难以维护。

  • 此外,使用单独的 js 文件可以鼓励可重用性和module化代码设计。

  • 保持您的 html 干净,并且您知道在发生任何 js 错误而不是多个模板时该去哪里查看。

您可以将 JS 嵌入到您的构建过程中,就像将多个 JS 文件合二为一进行部署一样
2021-05-04 09:26:14

您应该阅读有关不引人注目的 javascript, http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

还有其他解决方案可以不为每个网页加载资产目录中的所有 javascript 文件,一个称为 requirejs 的解决方案应该检查http://requirejs.org/

此外,作为一般经验法则,您不应该在页面加载时添加所有事件侦听器,那么不存在的 dom 对象呢?它会抛出 javascript 错误,并且会比平时更多地破坏您的代码。

在页面上运行不必要的 JavaScript 可能会导致该页面加载缓慢。这取决于正在运行的 JavaScript。

您可以通过计时来测试您的示例代码,并查看 JavaScriptgetElementsByClassName重复运行需要多长时间

(我敢打赌它根本不会花很长时间,即使您有 26 个函数寻找具有不同类名的元素,但对于性能,始终首先进行测量。)

如果执行时间是一个问题,您可以编写 JavaScript,使其主要在一个文件中,但在需要它的页面上公开从内联 JavaScript 运行的函数,而不是通过onloadJavaScript 文件中的事件运行它

值得记住的是加载页面时必须发生的一切:

  1. 浏览器从其缓存中获取页面,或发送 HTTP 请求以查看页面自缓存后是否已更改,和/或为页面本身发送 HTTP 请求。
  2. 浏览器解析和呈现页面,暂停以获取和运行任何外部 JavaScript,并在解析和呈现的同时获取样式表和图像。
  3. 浏览器运行任何设置为在文档就绪时运行的 JavaScript。
  4. 浏览器运行任何设置为在页面加载时运行的 JavaScript。

虽然您当然可以编写运行缓慢的 JavaScript,但总体而言,将 JavaScript 放在外部文件中(因此在用户浏览器的缓存中)可能比通过内联方式增加页面大小更好。一般来说,网络往往比 JavaScript 解析/执行慢得多。

但是,我再次这样说是因为这是最重要的一点,这将根据您的代码而有所不同。如果你想保持你的表现良好,你的第一个也是最后一个行为必须是衡量它。

getElementsByClassName 是一个懒惰的枚举......(或他们称之为“实时”)只是调用它没有任何工作。
2021-05-19 09:26:14

在放置 js 代码时需要记住各种情况。

对于内联:

  1. 如果您需要快速更改某些内容,则无需导航到外部文件,因此在本地会更好

  2. 如果您在页面的某些元素中使用 AJAX,您可能会丢失该部分的所有 dom 元素 onclick 等,这显然取决于您如何绑定它们。例如,您可以使用 live 或 delegate 以防您使用 jQuery 来避免上述问题……但我发现如果 js 足够小,最好将其内联。

现在还有其他理论

外化 javascript 是雅虎性能规则之一:

http://developer.yahoo.com/performance/rules.html#external