这篇案例研究介绍了 GoDaddy 实施的更改，这些更改改善了数百万个网站的网站性能，帮助它们获得良好的 PageSpeed Insights 和 Core Web Vitals 得分。
GoDaddy 是面向全球创业者的全球最大服务平台。我们的使命是为全球超过 2,000 万客户和企业家提供他们在线上取得成功所需的所有帮助和工具，帮助他们实现业务增长。
GoDaddy 于 2019 年推出了 Websites + Marketing，致力于提供简单易用的工具和服务，帮助企业主实现其目标。Websites + Marketing 将网站建设与营销和电子商务工具相集成，并搭配提供卓越的指导，帮助客户通过新事业取得成功。
自“网站 + 营销”推出以来，效果一直是该产品的重要组成部分，我们一直在积极监控和改进效果。在本文中，我们将回顾 GoDaddy 从使用实验室性能测试到结合核心网页指标使用真实数据的历程，以及为客户网站取得非常高的通过率而对该产品做出的一系列改进。
使用 Lighthouse 跟踪性能
我们一直依赖 Lighthouse 数据来跟踪效果。每当有网站在该平台上发布时，我们都会使用名为“Lighthouse4u”的内部工具来衡量其性能。该工具提供 Google Lighthouse 服务 (https://github.com/godaddy/lighthouse4u)。这让我们很好地了解了网站在实验环境中的一般表现。
由于我们平台上托管的数百万个网站具有各种各样的功能和内容，因此请务必将效果数据与每个被测网站的元数据（例如所用模板、呈现的 widget 类型等）结合起来。这样，我们就可以得出哪些网站功能的效果较差的结论，同时还能深入了解哪些方面有待改进。
例如，这有助于我们发现“弹出式模态”对网页速度有负面影响；启用该功能的网站的效果得分比未启用该功能的网站低 12 分。更新代码以延迟加载 JavaScript 后，我们的 Lighthouse 评分提高了 2 分。我们能够将这些学习成果应用于其他功能，例如在页面加载后立即呈现的“Cookie 横幅”。
除了根据功能查看存在问题的网站之外，我们还对 JavaScript 软件包进行了分析，发现其大部分大小来自外部依赖项（immutable.js 和 draft.js）。我们通过重构使用方以按需延迟加载依赖项来减小了软件包大小。这使得常见的 JavaScript 软件包大小缩减了 50% 以上，从 200 KB 以上缩减到了 90 KB 左右（经过缩减）。由于 Bundle 大小较小，浏览器可以在初始网站加载生命周期的更早阶段加载外部资源并执行关键脚本，从而缩短 Largest Contentful Paint (LCP) 和 First Input Delay (FID) 的时间。
在我们持续努力下，客户网站的 Lighthouse 平均得分从 2020 年 11 月的 40 分左右提高到了 2021 年 5 月的 70 分以上。不过，并非所有尝试都奏效了，有时我们会发现，本地测试环境中的测试结果与实际获得的结果并不总是一致，这让我们感到意外。实验室结果非常有用，但现在是时候专注于在现场观察到的真实用户体验了。
使用 Core Web Vitals 跟踪真实用户数据
在向客户的网站添加 web-vitals 库后，我们能够衡量来自真实访问者的实际设备上的数据，这些设备的硬件、网络速度、用户互动（例如滚动或点击）与使用 Lighthouse 的实验室环境中的基准值不一致。这是一个朝着正确方向迈出的一大步，因为我们现在有了代表网站访问者体验的数据。
着重关注最薄弱的环节：Cumulative Layout Shift (CLS)
通过分析新数据，我们从新的角度了解了提高网站速度所需采取的措施。由于我们采取了一些措施来提高 Lighthouse 评分，因此我们的第 75 百分位 LCP 为 860 毫秒，在相同阈值下 FID 低于 10 毫秒，因此我们客户网站上的这些指标的通过率很高，分别为 78% 和 98%。不过，累积布局偏移 (CLS) 数值与我们之前在 Lighthouse 中看到的完全不同。75 百分位数的 CLS 为 0.17，高于“通过”的 0.1 阈值，因此我们所有网站的通过率仅为 47%。
该指标将我们的整体通过率拉低到了 40%，因此我们决定制定一个宏伟的目标，即在 2021 年 8 月底之前将该比例提高到 60% 以上。为此，我们必须着重于 CLS。
在现实生活中，用户会与网页互动并滚动到“可见区域”内容之外，而核心网页指标可以更好地捕获这一点。由于用户在网站初始加载期间与网站互动的方式存在差异，因此 CLS 与实验室数据和现场数据不同。
如何通过所有 Core Web Vitals 评估
提升广告效果需要反复试验，而且每次尝试都未必能取得预期成效。不过，我们还是进行了一些改进，帮助我们实现了目标。
为加载图片预留空间大大提高了我们的 CLS 得分，因为这可以防止图片下方的内容发生偏移。我们使用了 CSS aspect-ratio 属性，在支持该属性的浏览器中解决了这个问题。对于没有缓存的图片，我们会加载一个透明的占位符图片，该图片已缓存且只有几字节大小，因此几乎可以即时加载。
得益于这种通用图片行为，我们可以在服务器端渲染期间根据视口宽度和图片宽高比预计算最终图片高度。这会生成 HTML 标记，其中为最终图片适当地预留了垂直空间。由于图片会渲染到移动设备视口的整个跨度，因此在移动设备上尤其能明显感受到改进。
客户网站上的某些组件包含动态内容（例如外部客户评价列表），无法转换为纯 CSS 以利用服务器端呈现的性能优势。这些区域很难改进布局偏移，因为内容（因此高度）会有所不同。在这些情况下，我们会将组件封装在容器中，并应用 min-height（根据观察每个特定组件的平均高度预先确定）。内部动态组件完成渲染后，系统会移除 min-height。虽然这个解决方案并不完美，但它确实大大减少了布局偏移。
在专注于 CLS 改进的同时，我们也继续改进 LCP。在许多网站上，图片是导致 LCP 延迟的最大元凶，这对我们来说是一个明显的改进方向。我们改进了使用 IntersectionObserver 延迟加载图片的方式，但发现并未以最优方式为每个断点（移动设备、平板电脑、桌面设备、大型桌面设备）设置图片大小，因此更新了图片生成代码，以按断点限制和缩放图片，然后再根据像素密度缩放分辨率。例如，这将一张特定的大型图片的大小从 192 KB 缩减到了 102 KB。
为了在网络连接不佳的设备上快速呈现网站，我们添加了一些代码，以便根据连接速度动态缩减图片质量。为此，您可以使用 navigator.connection 返回的 downlink 属性。我们会根据这些网络条件，通过素材资源 API 应用基于网址的查询参数来降低图片质量。
客户网站的多个部分是动态加载的。由于我们知道在发布时给定网站上将呈现哪些部分，因此我们使用了 rel=preconnect 资源提示来预先初始化连接和必要的握手。我们还使用资源提示快速加载字体和其他重要资源。
在构建网站时，客户会添加各种版块，这些版块可能包含内嵌脚本，以实现不同的功能。将这些脚本内嵌到整个 HTML 网页中并不一定能带来最佳性能。我们决定将这些脚本外部化，以允许浏览器异步加载和解析脚本内容。新外部化的脚本也可以在各个网页之间共享。这使得我们能够通过浏览器和 CDN 缓存进一步提升性能。我们将关键脚本保留在内嵌位置，以便浏览器更快地解析和执行它们。
结果
我们专注于 CLS 的努力取得了成效，Core Web Vitals 通过率从大约 40% 提高到了近 70%，提升了 75%！
随着用户返回我们的平台进行更新和重新发布其网站，他们会获得最新的性能改进，因此“通过 Core Web Vitals 评估”的网站数量一直在稳步增长，如下图所示：
总结
找出有待改进的性能方面并成功跟踪进度在很大程度上取决于所使用的衡量工具。虽然 Lighthouse 非常适合在“实验室设置”中衡量可见区域的性能，但无法准确捕获仅因用户互动（例如滚动网页）而发生的性能问题。
通过使用元数据跟踪真实的 Core Web Vitals，我们能够直观呈现、定位和衡量改进的影响。在提升 Core Web Vitals 评分的过程中，该团队发现了整个代码库中存在的低效模式，并将其替换了。有时，效果出色的更改并没有达到预期的效果，有时则相反。这个世界并不完美，因此您必须不断尝试。