速度最快且优化最充分的资源是未发送的资源。您应从应用中去除不必要的资源。与团队一起对隐含和明确的假设提出问题并定期重新审视，不失为一种好的做法。以下是几个示例：
- 您始终会在自己的网页上添加资源 X，但下载和显示该资源的费用会抵消它为用户提供的价值吗？您能否衡量并证明其价值？
- 相应资源（尤其是第三方资源）能否提供一致的性能？该资源是否处于或需要处于关键路径中？如果资源位于关键路径中，它是否会成为网站的单点故障？也就是说，如果相应资源不可用，是否会影响网页的性能和用户体验？
- 该资源是否需要或具有服务等级协议 (SLA)？该资源是否遵循性能最佳实践（压缩、缓存等）？
网页包含不必要的资源，或者更糟糕的是，这些资源会阻碍网页性能，却无法给访问者或托管这些网页的网站带来太多价值。这同样适用于第一方和第三方资源和微件：
- 网站 A 决定在其首页上显示一个照片轮播界面，访问者只需快速点击一下，即可预览多张照片。页面加载时，所有照片都会加载，并且用户可依次浏览照片。
- 问题：您是否衡量过有多少用户在轮播界面中查看了多张照片？您可能给大多数访问者造成了巨大开销，导致下载了大多数访问者从未查看的资源。
- 网站 B 决定安装一个第三方微件来显示相关内容、提高社交互动度或提供其他服务。
- 问题：您是否跟踪过有多少访问者使用微件或点击浏览微件提供的内容？这个微件带来的互动度是否足以证明其开销是否合理？此外，您可以采用加载策略来确保脚本在需要时才加载吗？
确定是否去除不必要的下载通常需要进行大量的仔细思考和评估。为了获得最佳效果，请定期清点您网页上的每个资源并再次查看这些问题。
对核心网页指标的影响
Core Web Vitals 计划由 Google 推出，旨在提供一组指标来反映用户使用网页时的体验。虽然核心网页指标有很多优化策略，但询问是否在网页上加载特定资源可能会为您改进网站上的这些指标提供指导。以下是按每项 Core Web Vitals 分组的几个示例，值得您考虑。虽然以上示例并未详尽列出所有示例（而且有很多！），但仔细阅读这些示例或许可以让您有所启发。
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) 用于衡量何时加载最大内容（例如主打图片或标题）。它被认为是一项重要的感知性指标，可向用户表明网站加载速度很快。
一般来说，下载的资源较少意味着用户实际拥有的带宽将在较少的资源之间分配，这可能会带来 LCP 的提升。一个典型的例子就是延迟加载，即在网页加载期间，视口外的图片只有在浏览器确定用户更有可能看到图片后才会下载它们。例如，如果您有一个包含 50 张图片的大型缩略图图库，那么延迟加载除前 10 张图片之外的所有图片，意味着浏览器可以更高效地利用可用的带宽，而且用户看到的前几张图片的加载速度会更快。
但是，这不只是加载更少的图片。浏览器有一个内部优先级方案，用于确定每个资源应接收多少带宽。不过，即便使用这类资源（尤其是以高优先级下载的资源），也有可能剥夺潜在 LCP 元素的依赖资源。网络连接速度较慢时尤其如此。该依存资源可能是代表网页 LCP 元素的图片文件，但也可能是浏览器在渲染可被确定为网页 LCP 元素的文本节点时所需的网页字体资源。
如果您的网站包含大量文字，网页的 LCP 元素可能是文本节点。虽然有许多良好的字体优化和加载策略，但还是有必要考虑系统字体是否足以满足您网站的需求，以使作为文本节点的 LCP 元素能够在不依赖于网页字体资源的情况下加载，并在 CSS 和 HTML 从服务器到达时几乎立即进行绘制。
Cumulative Layout Shift (CLS)
您加载的每项资源都有可能影响网页的 Cumulative Layout Shift (CLS)，尤其是在初始绘制时尚未完成下载的情况。对于图片，请避免使用涉及设置明确尺寸等做法的 CLS。对于字体，管理字体加载和可能的回退字体匹配，可以最大限度地减少网页字体交换期间的偏移。对于 JavaScript 来说，管理脚本对 DOM 的操作方式是可以控制的，以将布局偏移减少到可接受的程度。
构成页面 CLS 的每个资源都需要执行一些工作才能确保页面布局足够稳定。通过质疑您是否需要特定资源，您不仅可以加快页面加载速度，还可以减少为保持布局稳定性所需的认知工作量。这不仅会大大减少令人失望的用户体验，还会减少令人失望的开发者体验，因为您将有更多时间在项目中实现其他目标。
Interaction to Next Paint (INP)
Interaction to Next Paint (INP) 用于衡量在网页的整个生命周期内对用户输入的响应情况。网页的 INP 会受到其所加载的 JavaScript 的极大影响，因为 JavaScript 是推动网页体验的主要互动方式。尤其是在网页加载期间下载的脚本资源量可能会触发脚本评估和编译中涉及到的高昂成本工作。启动期间加载的 JavaScript 越少，浏览器在网页体验的这一关键点（用户可能尝试与之互动）所要做的工作就越少。
尽管有一些策略（例如代码拆分和摇树优化）可以缩减启动期间下载的 JavaScript 资源的大小，但还是有必要对在项目中使用的软件包进行审核，看看是否有必要使用这些资源。例如，lodash 的许多方法目前仍然有用，但附带了浏览器开箱即用的方法，例如特定于 Array 的映射、缩减和过滤函数，以及许多其他方法。
渐进式增强也是 JavaScript 的一种实用方法，因为它可以让您为用户提供基本（但仍然有效）的体验，您可以将这些体验添加到功能更强大、网络连接更快速的用户。无论您是否遵循渐进式增强的原则，重点都在于：您可以避免下载的每项 JavaScript 资源都能带来对用户互动响应更快的体验，而这是网页性能的一个重要方面。
总结
对网站进行不必要的下载可能只是提供快速用户体验的一个方面，但可能会带来深远的影响。总结如下：
- 清点您网页上的自有资源和第三方资源。
- 衡量每项资产的表现：其价值及其技术性能。
- 确定资源是否提供了足够的价值。
- 了解不必要的下载对核心网页指标和支持指标的影响。
以这种方式优化内容效率，您不仅可以提升整体性能，还能避免浪费用户的带宽，还有可能改进以用户为中心的指标并提供更好的用户体验。