Web性能，使您的Lighthouse得分保持在100分。

网站体验的质量对于实现网站的业务目标和访客的满意度至关重要。

Adobe Experience Manager (AEM)经过优化，可提供卓越的体验和最佳的Web性能。 使用 实时监控(RUM) 操作数据收集、信息不断从现场使用中收集，并且提供了一种迭代实际使用性能测量的方法，而无需等待CRuX数据显示代码和部署更改的影响。 在RUM中收集的现场数据通常与实验室结果不一致，因为实际设备的网络、地理位置和处理能力比实验室中的模拟条件更加多样化。

此 Google PageSpeed Insight Service 被证明是一个很好的实验室测量工具。 它可用于避免网站性能和体验得分的缓慢下降。

如果您使用样板启动项目，如中的 开发人员教程，您将在移动设备和桌面的PageSpeed Insight上获得非常稳定的Lighthouse得分 100. 在Lighthouse得分的每个组件上，都存在一些可供项目代码使用的缓冲区，并且仍然处于完美的边界内 100 灯塔分数。

测试拉取请求

结果发现，光房子得分很低的时候就很难提高，但要保持在较低水平并不难 100 如果你不断测试。

在项目上打开拉取请求(PR)时，将使用项目描述中的测试URL来运行PageSpeed Insights服务。 如果分数低于，AEM GitHub机器人将自动让您的PR失败 100 略加缓冲，以解释结果的不稳定性。

其结果是针对移动设备灯塔分数的，因为与台式机相比，实现起来往往更困难。

为什么选择Google PageSpeed Insights？

许多团队和个人使用自己的配置来测量Lighthouse分数。 不同的团队开发了自己的测试工具，并将自己的测试工具与作为持续监控和性能报告实践的一部分而设置的配置配合使用。

网站的性能会影响其在搜索结果中的排名，这在crUX报表的核心Web动态中得以反映。 Google能够很好地处理设备信息的相关平均组合（例如屏幕大小）以及这些设备的网络性能。 但最终，SEO是Web性能好坏的最终决定因素。 由于特定配置是移动目标，因此性能实践应与当前的全局平均设备和网络特性保持一致。

因此，我们不再使用特定于项目的配置进行Lighthouse测试，而是使用不断更新的配置，这些配置被视为最新版本的Google中引用的移动和桌面策略的一部分 PageSpeed Insights API.

虽然有些开发人员觉得可以从其他衡量Lighthouse分数的方法中收集到额外的洞察信息，以便能够跨项目进行有意义的可比性能对话，但需要有一种方法能够普遍衡量性能。 在衡量性能方面，默认的PageSpeed Insight Service是最具权威性、最广为接受的实验室测试。

不过，请务必记住，您从PageSpeed Insights获得的建议不一定会带来更好的结果，尤其是您距离灯塔分数越近 100.

由内置RUM数据收集收集的核心Web虚拟(CWV)在验证结果方面发挥着重要作用。 但是，对于细微的变动，结果的差异以及在短时间内缺乏足够的数据点（流量），使得在大多数情况下获得统计上的相关结果变得不切实际。

三相加载(E-L-D)

将网页上的有效负载划分为三个阶段可使其相对直接地获得干净的Lighthouse得分，从而设定良好客户体验的基线。

三阶段加载方法将页面的有效负载和执行分为三个阶段

阶段E：热切的

在 急切的 阶段，需要加载的所有内容以真正实现 LCP 将加载要显示的内容。 在项目中，这通常由标记、CSS样式和JavaScript文件组成。

在许多情况下， LCP 元素包含在块中（通常由自动阻止创建），其中 .js 和 .css 还必须装载。

块加载器逐步取消隐藏部分，这意味着必须为第一部分的所有块加载 LCP 变得可见。 因此，在页面顶部使用较小的部分（包含尽可能少的内容）或许是合理的。

根据经验，将聚合有效负载保留在 LCP 显示在100kb以下，这通常导致 LCP 事件快于1560毫秒(LCP 在PSI中得分100)。 特别是在移动设备，网络往往带宽受限，因此更改加载顺序之前 LCP 影响最小或没有影响。

从以下位置之前的第二个源加载或连接到该位置： LCP 强烈建议不要建立第二个连接（TLS、DNS等） 大大延迟了 LCP.

阶段L：延迟

在 延迟 阶段，加载的有效负载部分不会影响总阻塞时间(TBT)和最终的第一次输入延迟(FID)。

这包括加载块（JavaScript和CSS）以及根据它们加载所有剩余图像等 loading="lazy" 属性和其他不会阻止的JavaScript库。 一般来说，懒惰阶段就是各种变化中发生的一切 blocks 您即将创建以满足项目需求。

在此阶段，仍建议将大部分有效负载来自同一来源并由第一方控制，以便在需要时做出更改以避免对第三方造成负面影响 TBT， TTI 和 FID.

阶段D：延迟

在 延迟 阶段，有效载荷中对体验没有直接影响和/或不受项目控制且来自第三方的部分被加载。 可以考虑使用营销工具、同意管理、扩展分析、聊天/交互模块等。 通常通过标签管理解决方案来部署。

必须了解，要最大限度地减少对整体客户体验的影响，此阶段的开始需要大幅延迟。 延迟阶段应在LCP事件后至少三秒钟，以便为体验的其余部分留出足够的时间进行结算。

延迟阶段通常在中处理 delayed.js 用作初始捕获所有导致此问题的脚本 TBT. 理想情况下， TBT 通过在主线程之外加载问题（在Web工作程序中），或者只是从代码中删除实际阻止时间，可以从相关脚本中删除问题。 修复问题后，可以轻松将这些库添加到延迟阶段并提前加载。

理想情况下，脚本中不会出现阻止时间，由于常用技术（如标签管理器或构建工具）会创建大型JavaScript文件，当浏览器解析这些文件时这些文件会被阻止，因此有时很难实现阻止时间。 从性能的角度来看，建议删除这些技术，确保各个脚本不会阻塞并将它们作为单独的较小文件单独加载。

页眉和页脚

页眉和页脚（尤其是页眉）不在到的关键路径中 LCP，这就是为什么在各自的块中异步加载它们。 通常，不共享相同生命周期的资源（即这些资源在不同时间会随着创作更改而更新）应保存在单独的文档中，以使源服务器和浏览器之间的缓存链更简单、更有效。 将这些资源分开会增加缓存命中率，并降低缓存失效和缓存管理的复杂性。

字体

由于Web字体通常会对带宽造成压力，并且需要通过字体服务(如 https://fonts.adobe.com 或 https://fonts.google.com，则基本上无法在之前加载字体 LCP，因此它们通常会被添加到 lazy-styles.css 并在以下位置后加载： LCP 将显示。

LCP块

在某些情况下，实际 LCP 元素不包含在传输到客户端的标记中。 当存在间接或查找（例如，称为的服务、加载的片段或需要在中进行的查找）时，会发生这种情况 .json) LCP 元素。
在这些情况下，页面加载需要猜测以下事件才能完成 LCP 候选（当前为页面上的第一个图像），直到第一个块对DOM进行了必要的更改为止。
确定在阻塞之前要等待的块 LCP 加载，您可以添加包含 LCP 元素到 LCP_BLOCKS 数组 scripts.js.

额外练习：速度为绿色

构建快速、小而快速的网站不仅是提供转化率更高的卓越体验的好主意，也是降低碳排放的好方法。