案例研究，了解 GoDaddy 为了提高数百万个网站的网站性能而实施的更改，以帮助他们获得良好的 PageSpeed Insights 和核心网页指标得分。
GoDaddy 是全球最大的面向企业家的服务平台。我们的使命是为全球超过 2000 万客户以及世界各地的企业家提供所需的全部帮助和工具，帮助他们实现在线发展。
GoDaddy 于 2019 年推出了“网站 + 营销”计划，承诺提供易于使用的工具和服务来帮助企业主实现目标。“网站 + 营销”将网站构建与营销和电子商务工具相结合，并为它们提供一流的指导，帮助客户通过新创业取得成功。
自从推出“网站 + 营销”计划以来，效果一直是该产品的重要组成部分，一直受到监控和积极的关注。在本文中，我们将回顾 GoDaddy 从使用实验室性能测试到将真实数据与 Core Web Vitals 结合使用的经历，以及为使客户网站达到非常高的通过率而对产品做出的一系列改进。
使用 Lighthouse 跟踪性能
我们依靠 Lighthouse 数据进行性能跟踪。每次网站在平台上发布时，我们都会使用名为“Lighthouse4u”的内部工具衡量网站的性能，该工具以服务的形式提供 Google Lighthouse 即 https://github.com/godaddy/lighthouse4u。这让我们能够清楚地了解网站在实验设置中的总体效果。
由于我们平台上托管的数百万个网站都具有丰富多样的功能和内容，因此请务必将性能数据与每个受测网站的元数据（例如使用的模板、呈现的微件类型等）结合起来。这样一来，我们就可以确定哪些网站功能的效果较差，同时深入了解哪些方面需要改进。
例如，这帮助我们确定了“弹出式模式”对网页速度产生了负面影响；使用该功能的网站比不使用该功能的网站低 12 分。在更新代码以延迟加载 JavaScript 后，我们的 Lighthouse 得分提高了 2 分。因此，我们将所学的知识运用到其他功能中，例如在网页加载完毕后很快显示的“Cookie 横幅”。
除了根据功能分析有问题的网站外，我们还对 JavaScript 软件包进行了分析，发现它很大一部分大小都来自外部依赖项（immutable.js 和 draft.js）。我们通过重构使用方来按需延迟加载依赖项，从而缩减了 bundle 大小。这导致通用 JavaScript 软件包的大小缩减了 50% 以上，从 200 KB 减少到 90 KB 左右（已缩减）。由于软件包较小，浏览器可以在初始网站加载生命周期中尽早加载外部资源并执行关键脚本，从而提升了 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%。不过，Cumulative Layout Shift (CLS) 中的数据看起来与过去使用 Lighthouse 时的数据有很大不同。我们的第 75 百分位的 CLS 为 0.17，高于“通过”的 0.1 阈值，因此通过率在所有网站上仅为 47%。
该指标将我们的总体通过率降至 40%，因此我们决定设定一个雄心勃勃的目标，在 2021 年 8 月底之前将该比例提高到 60% 以上。为此，我们必须专注于 CLS。
在现实生活中，用户与网页互动并滚动越过“首屏”内容，核心网页指标可以更好地反映这一点。由于网站最初加载时用户与网站互动的方式不尽相同，因此 CLS 与实验室和现场数据不同。
顺利通过所有核心网页指标的途径
提升效果需要不断尝试和犯错，而且每次尝试有时都达不到预期的效果。但是，以下几项改进帮助我们实现了目标。
预留用于加载图片的空间可显著提高我们的 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 效果后，核心网页指标的通过率从约 40% 提高到了近 70%：提高了 75%！
随着用户经常回到我们的平台进行更新并重新发布网站，他们获得了最新的性能改进，因此“通过核心网页指标”的网站数量一直在稳步增长，如下图所示：
总结
能否找到有待改进的方面并成功跟踪进度，很大程度上取决于用于衡量的工具。虽然 Lighthouse 可用于衡量“实验室设置”中的首屏性能，但它并不能准确捕获仅在用户互动（例如滚动浏览网页）时才出现的性能问题。
通过利用元数据跟踪实际的核心网页指标，我们得以直观呈现、定位和衡量相关改进的效果。得益于提高 Core Web Vitals 得分的历程，该团队能够发现并替换在整个代码库中发现的性能不佳的模式。有时，具有前景的改变并没有达到我们预期的影响，有时则相反。这里不是一个原始的世界，因此你必须继续努力。