该案例研究介绍了 Wix 做出的一些重大变更，这些变更有助于提升数百万个网站的网站加载性能，为这些网站获得良好的 PageSpeed Insights 和 Core Web Vitals 分数扫清了障碍。
根据 CrUX 和 HTTPArchive 中的数据，得益于利用业界标准、云服务提供商和 CDN 功能，以及对网站运行时进行重大重写，在所有 Core Web Vitals 指标中，达到良好 75 分位数的 Wix 网站的比例比去年增加了三倍以上。
Wix 采用了以成效为导向的文化，并将继续为用户推出进一步的改进。随着我们专注于性能 KPI，我们预计符合核心网页指标阈值的网站数量将会增加。
概览
性能世界错综复杂，包含许多变量和复杂性。研究表明，网站速度对企业的转化率和收入有直接影响。近年来，业界越来越注重性能可见性和提高 Web 速度。从 2021 年 5 月开始，网页体验信号将纳入 Google 搜索排名的考量范围。
Wix 面临的独特挑战是支持数百万个网站，其中有些网站是很多年前构建的，从未更新过。我们提供了各种工具和文章，帮助用户了解如何分析和提升网站的性能。
Wix 是一个受管理的环境，并非所有事项都由用户掌控。共享常见基础架构给所有这些网站带来了许多挑战，但也为全面进行重大改进（即利用规模经济）提供了机会。
使用通用语言
性能方面的核心难题之一是，在考虑技术性能和用户感知性能的同时，找到一个常用的术语来讨论用户体验的不同方面。在组织内使用明确的通用语言，让我们能够轻松讨论和分类不同的技术部分和权衡，阐明了我们的效果报告，并极大地帮助我们了解应优先改进哪些方面。
我们调整了所有监控和内部讨论，纳入了 Web Vitals 等行业标准指标，其中包括：
网站复杂性和性能得分
只要尽量简化网站（仅使用 HTML），并通过 CDN 提供服务，您就可以轻松创建可立即加载的网站。
但现实情况是，网站越来越复杂和精细，其运作方式更像应用而非文档，并支持博客、电子商务解决方案、自定义代码等功能。
Wix 提供非常丰富的模板，让用户能够轻松构建具有多种商家功能的网站。这些额外功能通常会带来一些性能开销。
历程
起初，HTML
每次加载网页时，系统都会先向网址发出初始请求，以检索 HTML 文档。此 HTML 响应会触发所有其他客户端请求和浏览器逻辑，以运行和呈现您的网站。这是网页加载过程中最重要的部分，因为在响应开始传送之前，系统不会执行任何操作（称为 TTFB，即第一字节时间）。
过去：客户端呈现 (CSR)
在运营大型系统时，您始终需要权衡考虑性能、可靠性和费用等因素。在几年前，Wix 使用的是客户端呈现 (CSR)，其中实际 HTML 内容是通过客户端（即浏览器）上的 JavaScript 生成的，这让我们能够支持大规模网站，而无需承担巨大的后端运营开销。
借助 CSR，我们可以使用一个基本为空的常规 HTML 文档。它只会触发所需代码和数据的下载，然后这些代码和数据会用于在客户端设备上生成完整的 HTML。
今天：服务器端渲染 (SSR)
几年前，我们改用服务器端渲染 (SSR)，因为这对 SEO 和性能都有益，可以缩短网页的初始可见时间，并确保为不完全支持运行 JavaScript 的搜索引擎提供更好的索引。
这种方法改善了可见度体验，尤其是在速度较慢的设备/连接上，并为进一步优化性能打开了大门。不过，这也意味着，对于每个网页请求，系统都会动态生成一个唯一的 HTML 响应，这远远不利于优化，尤其是对于浏览量巨大的网站。
推出多位置缓存
每个网站的 HTML 内容大多是静态的，但存在以下几点注意事项：
- 它会经常变化。每次用户修改其网站或更改网站数据（例如网站商店目录）时。
- 其中包含一些特定于访问者的数据和 Cookie，这意味着，访问同一网站的两位用户看到的 HTML 代码会略有不同。例如，支持产品功能，例如记住访问者放入购物车的商品，或访问者先前与商家发起的聊天等。
- 并非所有网页都可以缓存。例如，如果网页中包含自定义用户代码，并且在文档中显示当前时间，则不符合缓存条件。
最初，我们采用了相对安全的方法，即不缓存访问者数据，然后仅在每次缓存命中时，针对每个访问者动态修改 HTML 响应的特定部分。
内部 CDN 解决方案
为此，我们部署了一项内部解决方案：使用 Varnish HTTP 缓存进行代理和缓存，使用 Kafka 传送失效消息，以及基于 Scala/Netty 的服务来代理这些 HTML 响应，但会对 HTML 进行更改，并向缓存的响应添加访问者专用数据和 Cookie。
借助此解决方案，我们能够在更多地理位置和多个遍布全球的云服务提供商区域部署这些精简组件。2019 年，我们在 15 多个新地区推出了缓存功能，并逐步为超过 90% 符合缓存条件的网页浏览启用了缓存功能。通过从更多位置提供网站，可以将内容更靠近网站访问者，从而缩短客户端与提供 HTML 响应的服务器之间的网络延迟时间。
我们还开始使用相同的解决方案缓存某些只读 API 响应，并在网站内容发生任何更改时使缓存失效。例如，网站上的博文列表会被缓存，并在有博文发布/修改时失效。
降低复杂性
实现缓存后，性能大幅提升，尤其是 TTFB 和 FCP 阶段，并且通过从更靠近最终用户的位置提供内容，提高了可靠性。
不过，由于需要修改每个响应的 HTML，因此引入了不必要的复杂性。如果能够消除这种复杂性，就可以进一步提升性能。
浏览器缓存（以及为 CDN 做准备）
约 13%
HTML 请求直接从浏览器缓存中提供，从而节省大量带宽并缩短重复查看内容的加载时间
下一步是从 HTML 中彻底移除这些特定于访问者的数据，并在 HTML 到达后从客户端为此目的调用的单独端点检索这些数据。
我们已将这些数据和 Cookie 小心迁移到一个新的端点，系统会在每次加载网页时调用该端点，但它会返回一个精简的 JSON，该 JSON 仅供注水流程使用，以实现全页互动。
这让我们能够支持浏览器缓存 HTML，这意味着浏览器现在会保存 HTML 响应以供重复访问，并且只会调用服务器来验证内容是否未发生更改。这可以使用 HTTP ETag 来实现，它本质上是分配给特定 HTML 资源版本的标识符。如果内容保持不变，我们的服务器会向客户端发送 304 Not Modified 响应，但不包含正文。
此外，这项变更意味着，我们的 HTML 不再因访问者而异，也不含 Cookie。换句话说，它基本上可以在任何地方缓存，从而为使用在全球数百个地理位置拥有更广泛覆盖面的 CDN 提供商打开大门。
DNS、SSL 和 HTTP/2
启用缓存后，等待时间缩短了，初始连接的其他重要部分也变得更为可靠。通过改进网络基础架构和监控，我们缩短了 DNS 连接和 SSL 时间。
为所有用户网域启用了 HTTP/2，从而减少了所需的连接数量以及每次新连接带来的开销。这项变更相对容易部署，同时还能利用 HTTP/2 带来的性能和弹性优势。
Brotli 压缩（与 gzip 相比）
21 - 25%
缩减了文件传输中位数大小
传统上，我们会使用 gzip 压缩来压缩所有文件，这是网络上最常见的 HTML 压缩选项。这种压缩协议最初是在近 30 年前实现的！
较新的 Brotli 压缩引入了压缩改进，几乎没有任何权衡，并且正在逐渐流行起来，如年度 Web 年鉴的压缩章节中所述。所有主流浏览器已支持该功能一段时间了。
我们为支持 Brotli 的所有客户端在边缘的 nginx 代理上启用了 Brotli 支持。
改用 Brotli 压缩后，文件传输中位数大小缩减了 21% 到 25%，从而降低了带宽用量并缩短了加载时间。
内容分发网络 (CDN)
动态 CDN 选择
Wix 一直使用 CDN 在用户网站上分发所有 JavaScript 代码和图片。
我们最近与 DNS 提供商的解决方案进行了集成，以便根据客户的网络和来源自动选择效果最佳的 CDN。这样，我们就可以从最合适的位置向每位访问者提供静态文件，并避免某个 CDN 上出现可用性问题。
即将推出…由 CDN 提供服务的用户网域
最后一个环节是通过 CDN 提供最后一部分（也是最重要的部分）：来自用户网域的 HTML。
如上所述，我们创建了自己的内部解决方案，用于缓存和提供特定于网站的 HTML 和 API 结果。在这么多新区域维护此解决方案也需要运营费用，而且添加新位置成为我们需要管理和持续优化的一个流程。
我们目前正在与各种 CDN 提供商集成，以支持直接从 CDN 位置提供整个 Wix 网站，从而改善我们在全球范围内的服务器分布，进而进一步缩短响应时间。这是一个挑战，因为我们提供的网域数量众多，需要在边缘终止 SSL。
与 CDN 集成后，Wix 网站与客户的距离比以往更近，并且加载体验得到了进一步改进，包括 HTTP/3 等新技术，而我们无需额外付出努力。
关于性能监控的简要说明
如果您使用的是 Wix 网站，可能想知道这对 Wix 网站的效果有何影响，以及我们与其他网站平台相比如何。
上述大部分工作已在过去一年内完成，部分工作仍在逐步推出。
HTTPArchive 的《Web Almanac》最近发布了 2020 版，其中包含一个关于 CMS 用户体验的出色章节。请注意，本文中介绍的许多数据都是 2020 年年中的数据。
我们期待在 2021 年看到更新后的报告，并正在积极监控我们网站的 CrUX 报告以及内部效果指标。
我们致力于不断缩短加载时间，并为用户提供一个平台，让他们能够按照自己的想法构建网站，而不会影响性能。
DebugBear 最近发布了一篇非常有趣的网站构建工具性能评测，其中涉及我上面提到的一些方面，并对每个平台上构建的非常简单的网站的性能进行了检查。此网站建于将近两年前，自此就再未修改过，但该平台一直在不断改进，网站性能也随之提升，您可以通过查看其数据来了解过去一年半的情况。
总结
我们希望我们的经验能激励您在组织中采用以绩效为导向的文化，并希望上述详细信息对您的平台或网站有所帮助。
总而言之：
- 选择一组您可以使用业界认可的工具持续跟踪的指标。我们建议使用 Core Web Vitals。
- 利用浏览器缓存和 CDN。
- 迁移到 HTTP/2（或可能的话迁移到 HTTP/3）。
- 使用 Brotli 压缩。
感谢您了解我们的故事。欢迎您在 Twitter 和 GitHub 上提问和分享想法，并在您喜爱的渠道上加入 Web 性能对话。