Wix如何通过改进基础架构提升网站性能？-InfoQ



 写点什么

性能的世界是美好而复杂的，充满各种变量和细节。研究表明，网站速度会直接影响企业的转化率和收入。近年来，行业更加注重性能可视性和 Web 速度的提升。从 2021 年 5 月开始，页面体验信号将被包含在谷歌搜索排行中。Wix 面临的独特挑战是要支持数百万个站点，其中一些站点是多年以前构建的，自诞生后就没有更新过。我们有各种工具和文章]可以帮助用户分析和改善他们站点 Web 服务的性能。

Wix 是一个受管理的环境，并非一切都掌握在用户手中。共享通用基础设施给所有这些站点带来了许多挑战，但也为大范围的重大改进（也就是利用规模经济）铺平了道路。

找到共同语言

性能领域的一大核心问题是找到一种通用的术语来讨论各个方面的用户体验，同时考虑技术层面和感知层面的性能表现。在组织内使用定义明确的通用语言使我们能够轻松讨论和分类各种技术部分和权衡取舍、理解我们的性能报告，尤其重要的是帮助我们了解首先应该关注的改进领域。

我们调整了所有监视指标和内部讨论，加入了很多行业标准指标，如 Web Vitals，包括：

Core Web Vitals

网站的复杂性和性能得分

创建一个可以立即加载的网站很容易，只要你把它做的很简单，只使用 HTML 并通过 CDN 发布即可。

PageSpeed 洞察示例

但现实情况是，站点变得越来越复杂和精细，其运行方式越来越像应用程序而不是文档，并且支持诸如博客、电子商务解决方案和自定义代码等功能。

Wix 提供了种类繁多的模板，使用户可以轻松地构建具有许多业务功能的站点，而这些附加特性通常会带来一些性能成本。

旅程

一开始是 HTML

每次加载一个网页时，它总是以对一个 URL 的一个初始请求开始，用来检索 HTML 文档。这个 HTML 响应会触发所有其他客户端请求和浏览器逻辑来运行和渲染你的网站。这是最重要的页面加载步骤，因为在响应到达前什么都不会发生（称为 TTFB——第一个字节到达的时间）。

WebPageTest First View

过去：客户端渲染（CSR）

在运营大规模系统时总是需要权衡取舍各种因素，例如性能、可靠性和成本。直到几年前，Wix 都在使用客户端渲染（CSR），通过客户端（即浏览器）中的 JavaScript 来生成实际的 HTML 内容。这使我们能支持大量站点，而无需承担庞大的后端运营成本。

CSR 使我们能够使用一个通用的 HTML 文档，该文档实际上是空的。它所做的只是触发所需代码和数据的下载过程，然后用它们在客户端设备上生成完整的 HTML。

现在：服务端渲染（SSR）

几年前，我们过渡到服务端呈现（SSR），因为这对 SEO 和性能均颇有益处，缩短了初始页面可见时间，并能对不完全支持运行 JavaScript 的搜索引擎获得更好的索引结果。

这种方法改善了可见性体验，尤其是在速度较慢的设备/连接上，为进一步的性能优化打开了方便之门。但这也意味着对于每个网页请求，需要动态生成唯一的 HTML 响应，这远非理想之举，尤其是对具有大量视图的网站来说压力更为沉重。

在多个位置引入缓存

各个站点的 HTML 大部分都是静态的，但有一些需要注意：

它经常更改。每次用户编辑他们的站点或更改站点数据时，例如更改商店库存，HTML 都会变化。
它具有某些特定于访问者的数据和 cookie。这意味着访问同一站点的两个人会看到有些不同的 HTML。这种特性可以支持一些产品功能，例如记住访问者将哪些物品放入了购物车，或记住访问者之前同商家开始的聊天对话，等等。
并非所有页面都是可缓存的。例如，带有自定义用户代码的页面可能将当前时间显示为文档的一部分，因此无法缓存。

一开始，我们采用了一种相对安全的方法，即缓存没有访问者数据的 HTML，然后针对每个访问者为每个缓存命中动态修改 HTML 响应的特定部分。

内部 CDN 解决方案

为此我们部署了一个内部解决方案：使用Varnish HTTP Cache进行代理和缓存，使用 Kafka 来对消息无效化，还有一个基于 Scala/Netty 的服务，负责代理这些 HTML 响应，但会对 HTML 进行修改并向缓存的响应添加特定于访问者的数据和 cookie。

这个解决方案让我们能将这些轻巧的组件部署在遍布全球的更多地理位置和多个云提供商区域。2019 年，我们引入了超过 15 个新区域，并逐渐为 90％以上适合缓存的页面访问启用了缓存。从更多位置提供站点可以减少客户端和提供 HTML 响应的服务器之间的网络延迟，因为内容离网站访问者的距离更近了。

我们还开始使用相同的解决方案来缓存某些只读 API 响应，并在对网站内容进行任何更改时使缓存无效。例如，网站上的博客文章列表会被缓存，而有文章发布/修改时缓存会被无效化）。

降低复杂度

实现缓存可以显著提高性能（主要是在 TTFB 和 FCP 阶段），它让我们可以在更接近最终用户的位置提供内容，从而提高了可靠性。

但是，为每个响应修改 HTML 的做法引入了不必要的复杂性。如果能消除这种复杂性，就能为进一步提高性能创造条件。

浏览器缓存（以及为 CDN 做的准备）

HTML 请求直接从浏览器缓存中提供，从而节省了大量带宽并减少了重复视图的加载时间（～13%）

下一步是从 HTML 完全删除这部分特定于访问者的数据，并在 HTML 到达后从客户端为此目的调用的一个独立端点中检索这部分数据。

我们将这些数据和 cookie 小心地迁移到一个新端点，该端点在每次页面加载时都会被调用，但是返回一个轻巧的 JSON（只有水合流程才需要它），以实现完整的页面交互。

这样，我们就能启用浏览器对这个 HTML 的缓存，也就是说浏览器现在会为重复访问的站点存储 HTML 响应，并且只调用服务器来验证内容是否更改。这是使用HTTP ETag完成的，它基本上是一个识别器，被分配给 HTML 源的特定版本。如果内容没有变化，我们的服务器会向客户端发送一个 304 Not Modified 响应，其中没有正文。