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

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

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

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

如果您使用开发人员教程中的样板开始项目，则在100处的PageSpeed Insight for Mobile and Desktop上可获得非常稳定的Lighthouse分数。 在Lighthouse分数的每个组件上，都存在一些可供项目代码使用的缓冲区，并且仍处在完美100 Lighthouse分数的范围内。

测试拉取请求

结果发现，在灯塔分数较低时，很难提高其水平，但如果您持续测试，则不太难将其保持在100。

在项目上打开拉取请求(PR)时，将使用项目描述中的测试URL来运行PageSpeed Insights服务。 如果得分低于100，AEM GitHub机器人将自动导致PR失败，并且由于结果的不稳定而产生一些缓冲区。

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

为什么选择Google PageSpeed Insights？

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

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

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

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

不过，请务必记住，您从PageSpeed Insights获得的推荐不一定带来更好的结果，尤其是您越接近100的Lighthouse分数。

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

三相加载(E-L-D)

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

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

阶段E：热切的

在出现任何情况之前，请务必注意，正文必须隐藏（具有display:none）以确保没有图像开始下载并避免初始CLS。

在​ eager ​阶段中，第一个操作是“装饰”DOM：加载顺序很少调整，主要是将CSS类添加到图标、按钮、块和部分并创建自动块。 有关生成的标记的更多详细信息，请参阅标记、分区、块和自动阻止页面。

考虑到部分尚未加载且保持隐藏状态，则主体可以已经显示。

然后，完整的第一部分 ​加载时具有为该部分的第一个图像“LCP候选项”指定的优先级。 理论上，第一个部分具有的块数越少，可以加载的速度就越快LCP。

加载了LCP候选字体和该部分的所有块后，可以显示第一个部分，并可以异步开始加载字体。

这将结束​ eager ​阶段。

LCP

通常，LCP是显示在页面顶部的“主页”图像。 务必确保在加载序列中尽快加载和显示此图像（请参阅​ Eager ​阶段）。

必须加载所有需要加载才能显示真LCP的内容。 在项目中，这通常包括标记、CSS样式和JavaScript文件。

在许多情况下，LCP元素包含在块中，其中还必须加载块.js和.css。

在LCP显示之前将聚合有效负载保持在100kb以下是一个很好的经验规则，这通常会导致LCP事件比1560毫秒更快（在PSI中得分为100的LCP秒）。 特别是在移动设备，网络往往带宽受限，因此更改LCP之前的加载顺序几乎不会产生任何影响。

强烈建议不要在LCP发生之前从第二个源加载或连接到另一个源，因为建立第二个连接（TLS、DNS等）会给LCP增加显着的延迟。

在某些情况下，传输到客户端的标记中不包含实际的LCP元素。 当对LCP元素进行间接或查找（例如，调用的服务、加载的片段或需要在.json中进行的查找）时，会发生这种情况。
在这些情况下，重要的是页面加载需要猜测LCP候选（当前是页面上的第一个图像）才能等待，直到第一个块对DOM进行了必要的更改。

在其他一些情况下，内容包含2个主页图像，一个用于桌面，一个用于移动设备。 与上述相同，确保将正确的图像视为LCP候选图像非常重要，并且可能需要调整“主页”块以从DOM中删除不必要的图像（删除移动设备上的桌面图像，反之亦然）以便不加载占用带宽的图像，甚至更糟，先加载不必要的图像作为LCP候选图像。

最后，LCP可以是图像、视频或长文本之外的其他内容……对于所有这些情况，都需要深入了解加载顺序以及如何计算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之前加载字体，这就是它们之后加载的原因。

默认情况下，AEM样板实施字体回退技术以在加载字体时避免CLS。 预先加载字体（通过早期提示、h2-push或标记）会适得其反，并会极大地影响性能。

额外练习：速度为绿色

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

性能问题的常见来源

随着时间的推移，我们收集了会对性能产生负面影响的反模式集合，需要避免遵守本文档中的最佳实践。

早期提示/H2推送/预连接是网络预算的一部分

本能地，最好告诉浏览器在标记处理甚至开始之前尽可能早地下载。 但请记住，最终目标是尽快向访客显示稳定的页面。 LCP计时是此功能的良好代理。

根据经验，要在带有PageSpeed Insight的移动设备上获取LCP到100，应设置网络约束，使网络有效负载不超过100kb的主机只能有一个，因为设置过程在很大程度上受带宽限制。 早期提示，h2推送和预连接通过下载LCP不需要的资源来消耗该带宽，因此会对性能产生负面影响，因此必须删除。

路径解析的重定向

如果访客请求www.domain.com并且被重定向到www.domain.com/en，然后又被重定向到www.domain.com/en/home,，则他们将获得每个重定向的处罚，即性能受到负面影响。 这通常显示在通过RUM或CrUX测量的核心Web动态中，因为默认情况下，PageSpeed Insights中的实验室结果会从实验室测试中排除重定向开销。

CDN客户端脚本注入

我们的标记以及我们的.aem.page和.aem.live源针对性能进行了优化，我们对有效负载的任何部分以及资源的加载顺序都极其谨慎。

某些CDN供应商和配置插入的脚本占用带宽并造成阻塞时间，这些脚本早于LCP且对性能产生负面影响。 应禁用这些脚本，或在LCP之后在加载序列中适当加载这些脚本。

PageSpeed Insight报表的.aem.live源与客户CDN前面的相应站点（例如生产站点）的比较将显示非AEM控制的CDN产生的负面影响。

CDN TTFB和协议实施影响

根据CDN供应商的不同，协议实施和HTTP有效负载的纯交付的性能特征有所不同。 WAF和AEM上游的其他网络基础架构等附加工具也可能对性能产生负面影响。
PageSpeed Insight报表的.aem.live源与客户CDN前面的相应站点（例如生产站点）的比较将显示非AEM控制的CDN产生的负面影响。