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