嵌入式与链接 JS / CSS

Question

我熟悉链接 CSS 与嵌入式和内联在可维护性和模块化方面的优势。 但是，我读到在 web 开发的某些移动应用程序中，嵌入甚至内联 CSS 可能是有益的（更快的性能）。 我会避免使用任何内联 JS，并在较小程度上避免使用 CSS，但我注意到在许多网站上，包括大量谷歌页面，JS 都嵌入在页面的 header 中。

我的一位同事坚持始终链接到外部 js 文件。 如果 function 特定于一页或每页略有不同，我认为嵌入 js 更有意义，以节省链接脚本的处理开销。

Answer 1

其他答案没有涉及的一件事是开发人员的效率。 如果将其内联更容易，并且没有直接的性能要求/关注，那么就这样做。 “简单”具有真正的商业价值，它胜过最终或不存在的性能问题。 不要过早优化。

Answer 2

链接JS文件的优点是可以被浏览器缓存，在后续页面从本地磁盘或memory加载。

内联 JS 的优点是每页的网络请求可能更少。

最好的折衷方案通常是少量链接的 JS 文件（一个或两个），这些文件由所有 JS 的最小组合组成，因此它们被组合成尽可能少的文件，并且尽可能小。

获得本地缓存的好处远远超过了在某些页面上可能不会使用的小 JS 的额外解析。

有意义的嵌入式 JS（即使您的大部分 JS 都在链接文件中）是一些 JS 变量的设置，这些变量包含特定于您的页面的 state。 这通常会嵌入到页面的部分中，因为它是在您的服务器上动态生成的，每个页面都不同，并且通常不可缓存。 但是，这些数据通常应该很小且特定于页面。

Answer 3

链接脚本会以向服务器发出额外请求的形式产生少量损失。 如果您保持它内联，则不会发出此请求，并且根据情况，您可能会获得更快的加载页面。 在以下情况下内联代码是有意义的：

• 它非常小
• 它是动态生成的，从那时起您将无法获得缓存的好处

对于 google 和 facebook，您很可能会看到内联 javascript，因为它是由服务器端代码生成的。

Answer 4

其他答案已经提到了使用外部 JS 文件进行缓存的优点。 对于可能至少有两个页面使用的任何库或框架类型功能，我几乎总是会以这种方式使用 go。 尽可能避免重复。

我想我会评论“内联”与“嵌入式”。

对我来说，“内联”意味着将 JS 与 HTML 混合，可能有几个单独的<script>块可能会或可能不会相互引用，几乎可以肯定的是，许多事件处理程序直接使用 HTML 元素属性设置，例如<div onclick="..."/> 。 在大多数情况下，我会不鼓励这样做，但我不会因为偶尔使用而过于关注它。 有时它只是不那么麻烦，假装否则只会浪费你可以花在更重要问题上的时间。

我将“嵌入”定义为（最好）在头部或正文末尾有一个<script>块，并使用文档就绪或 onload 函数在该块内分配事件处理程序。 对于特定于一页的功能，我认为这没有任何问题，事实上，如果它只是少量脚本并且我不关心在客户端缓存它，我倾向于更喜欢它而不是外部文件。 此外，如果页面是动态生成的，并且需要在服务器上生成 JavaScript 中的某些内容，那么如果脚本在同一页面上，通常会容易得多。

关于外部文件的最后一点注意事项：在开发过程中要注意 IE 的“过度缓存”倾向。 有时在测试时我对一两个外部文件进行了一些小改动，我不禁想知道为什么它不起作用，只是最终意识到 IE 仍在使用旧的缓存版本。 （一方面这当然是我的错，但另一方面我认识很多人不时成为这件事的受害者。）

Answer 5

以上所有答案都是非常好的答案。 但我想根据 15 年的 web 开发经验添加我自己的。

始终为 CSS 和 ECMAScripted 资源使用链接资源，而不是内联代码，因为链接内容在大多数情况下由浏览器缓存，并在用户与给定域在线交互的数小时和数天内用于潜在的数千个页面。 优点如下：

1. 使用链接脚本节省的带宽是巨大的，因为您只需通过网络传输更少的脚本，而用户体验可能会使用数周的缓存。
2. 还有更好的 CSS 级联，作为嵌入式和内联 styles 覆盖，按重量，链接 styles 引起设计师的困惑。
3. 避免了重复脚本，内联脚本经常发生这种情况。
4. 您现在可以使用版本控制和基于日期的查询字符串在客户端上通过缓存控制在许多页面上重用相同的库。
5. 链接资源告诉浏览器在 DOM 中初始化 styles 的脚本之前预加载所有资源。 我已经看到与此相关的问题，即用户在通过脚本对时间表应用程序中的日期时间进行预处理之前按下按钮会导致重大问题。
6. 您可以更好地控制项目中的所有开发人员对脚本和 CSS 库的控制，避免页面中数百个未经审查的自定义脚本污染您的应用程序
7. 为您的用户更新库以及版本链接库非常容易。
8. 现在可以访问来自 Google 或其他人的外部脚本库。 您甚至可以使用链接资源重用您自己的链接库和 CSS。
9. 最重要的是，使用缓存的客户端资源可以提高处理速度。 缓存资源随时执行按需资源！
10. 链接脚本还强制样式和布局一致性，而不是每页的自定义布局变化。 如果您始终使用 HTML 布局，则可以模拟无闪存页面视图，因为 DOM 跨 web 页面使用缓存的 CSS 来更快地呈现页面。

一旦您在第一个域请求/响应中提取链接资源，用户的体验就会很快，服务器端页面交付意味着 DOM 和 HTML 布局不会移动或刷新，尽管有大量页面视图或指向整个站点的页面链接。 然后，我们经常根据需要将有限的自定义页面级嵌入式样式和脚本资源添加到页面级的缓存链接库堆栈中，如果需要进行窄范围的自定义。 全局变量和自定义 CSS 然后可以覆盖链接值。 这使您可以更轻松地维护网站，而无需逐页猜测缺少或已使用的库。 我已经在子部分中添加了自定义链接 JQuery 或其他库，以通过这种方式获得更快的速度，这意味着您也可以使用链接脚本来管理网站部分的自定义子组。

谷歌 ANGULAR

您在 Google 的 web 中看到的通常是 Angular 非常复杂的 ES5 和 ES6 模块化脚本缓存系统的实现，这些系统利用脚本和嵌入式 CSS 页面视图中的单页应用程序的完全 Javascripted DOM 操作（2+） . 他们利用精心设计的模块来加载按需和延迟加载组件以及带有 HTML/CSS 模板的模块，这些模板预加载到 memory 中，并从幕后的服务器中加速传递新闻和他们管理的其他页面。

他们需要浏览器 stream 巨大的 ECMAScript 预加载 HTML 和 CSS 与嵌入到这些缓存网页和模块的幕后交互。 问题是他们有大量相同的 CSS 堆栈和注入多个模块的脚本，然后是 DOM 的一部分，这是草率和浪费的。 他们认为现在不需要服务器端交付或缓存，因为他们可以通过内联样式和通过XMLHTTPRequest下载的隐藏 WebAPI 调用和来自服务器的脚本内容轻松管理所有这些。 当从页面链接的小得多的文件就足够时，为什么要不断下载所有这些并在 memory 中重建和存储内联页面？

Honestly, this is the sloppiest approach to cache management of styles, content, and CSS I have seen yet in web dev frameworks, as it still demands huge megabytes of scripts just to parse a simple news page with a few lines of text. 谷歌的某个人并没有真正通过大声笑来考虑这个框架。 如果您问我，它会浪费浏览器中的带宽和处理，而且过分。 在这些臃肿的供应商中，这是典型的过度设计。

这就是为什么我总是主张链接 CSS 和脚本。 更少的代码和更多的内容是发明这些框架的原因。 链接和缓存代码意味着更简单、更旧的模型可以更好地使用更小的标记页面的快速交付，这些页面缓存微小的千字节链接 ECMAScript 和 CSS 库。 这意味着用于显示内容的代码更少。 与几年前相比，现在浏览器与服务器的关系是如此快速和高效，以至于这些较小的链接文件的初始缓存直接从服务器（而不是通过 Web API 中的 ZC31ZC335EF3732873C1 上的 ZC31ZC335EF3732873C1 ) 意味着与典型的 web 域访问的初始访问相比，链接资源的交付速度要快得多。

直到最近，“脚本小子”才忘记了这一切，因此开始倒退到使用本地嵌入式和内联 styles 以及我们在 20 年前出于某种原因停止使用的脚本的失败方式。 这是一个非常糟糕的选择，并且表明当今许多新开发人员对 web 及其标记和内容 model 缺乏经验。

• 斯托克利