Wix 如何通過改進基礎架構提升網站性能？

作者 | Alon Kochba

譯者 | 王強

策劃 | 萬佳

研究表明，網站速度會直接影響企業的轉化率和收入。近年來，行業更加註重性能可視性和 Web 速度的提升。從 2021 年 5 月開始，頁面體驗信號將被包含在谷歌搜索排行中。Wix 面臨的獨特挑戰是要支持數百萬個站點，其中一些站點是多年以前構建的，自誕生後就沒有更新過。

1 背景

Wix 是一個受管理的環境，並非一切都掌握在用戶手中。共享通用基礎設施給所有這些站點帶來了許多挑戰，但也爲大範圍的重大改進（即利用規模經濟）鋪平了道路。

 找到共同語言

性能領域的一大核心問題是找到一種通用的術語來討論各個方面的用戶體驗，同時考慮技術層面和感知層面的性能表現。在組織內使用定義明確的通用語言使我們能夠輕鬆討論和分類各種技術部分和權衡取捨、理解我們的性能報告，尤其重要的是幫助我們瞭解首先應該關注的改進領域。

我們調整了所有監視指標和內部討論，加入了很多行業標準指標，如 Web Vitals，包括：

Core Web Vitals

 網站的複雜性和性能得分

創建一個可以立即加載的網站很容易，只要你把它做的很簡單，只使用 HTML 並通過 CDN 發佈即可。

PageSpeed 洞察示例

但現實情況是，站點變得越來越複雜和精細，其運行方式越來越像應用程序而不是文檔，並且支持諸如博客、電子商務解決方案和自定義代碼等功能。Wix 提供了種類繁多的模板，使用戶可以輕鬆地構建具有許多業務功能的站點，而這些附加特性通常會帶來一些性能成本。

2 旅程

 一開始是 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。

https://varnish-cache.org/?fileGuid=g3TQWXCD6kc6ppKW

這個解決方案讓我們能將這些輕巧的組件部署在遍佈全球的更多地理位置和多個雲提供商區域。2019 年，我們引入了超過 15 個新區域，並逐漸爲 90％以上適合緩存的頁面訪問啓用了緩存。從更多位置提供站點可以減少客戶端和提供 HTML 響應的服務器之間的網絡延遲，因爲內容離網站訪問者的距離更近了。

我們還開始使用相同的解決方案來緩存某些只讀 API 響應，並在對網站內容進行任何更改時使緩存無效。例如，網站上的博客文章列表會被緩存，而有文章發佈 / 修改時緩存會被無效化）。

 降低複雜度

實現緩存可以顯著提高性能（主要是在 TTFB 和 FCP 階段），它讓我們可以在更接近最終用戶的位置提供內容，從而提高了可靠性。

但是，爲每個響應修改 HTML 的做法引入了不必要的複雜性。如果能消除這種複雜性，就能爲進一步提高性能創造條件。

 瀏覽器緩存（以及爲 CDN 做的準備）

HTML 請求直接從瀏覽器緩存中提供，從而節省了大量帶寬並減少了重複視圖的加載時間（～13%）

下一步是從 HTML 完全刪除這部分特定於訪問者的數據，並在 HTML 到達後從客戶端爲此目的調用的一個獨立端點中檢索這部分數據。

我們將這些數據和 cookie 小心地遷移到一個新端點，該端點在每次頁面加載時都會被調用，但是返回一個輕巧的 JSON（只有水合流程才需要它），以實現完整的頁面交互。

這樣，我們就能啓用瀏覽器對這個 HTML 的緩存，也就是說瀏覽器現在會爲重複訪問的站點存儲 HTML 響應，並且只調用服務器來驗證內容是否更改。這是使用 HTTP ETag 完成的，它基本上是一個識別器，被分配給 HTML 源的特定版本。如果內容沒有變化，我們的服務器會向客戶端發送一個 304 Not Modified 響應，其中沒有正文。

https://en.wikipedia.org/wiki/HTTP_ETag?fileGuid=g3TQWXCD6kc6ppKW

WebPageTest Repeat View

此外，這一更改意味着我們的 HTML 不再是特定於訪問者的，並且不再包含 Cookie。換句話說，它基本上可以緩存在任何地方，這樣就可以充分利用 CDN 提供商的能力。這些 CDN 提供商的地理部署優勢更大，在全球數百個位置都有部署。

 DNS、SSL 和 HTTP/2

啓用緩存後，等待時間減少，初始連接的其他重要部分也顯得更加突出了。增強我們的網絡基礎架構和監視能力後，我們得以改善 DNS、連接和 SSL 時間。

響應時間圖

我們已爲所有用戶域啓用 HTTP/2，從而減少了所需的連接數量以及每個新連接的開銷。這是相對容易部署的更改，同時利用了 HTTP/2 帶來的性能和彈性優勢。

 Brotli 壓縮（vs gzip）

減少文件傳輸大小中值（21-25%）

傳統上，我們的所有文件都是用 gzip 壓縮的（這是網絡上最流行的 HTML 壓縮選項），這個壓縮協議最初是在 30 年前實現的！

Brotli 壓縮級別估算器

較新的 Brotli 壓縮引入了很多壓縮改進，幾乎沒有任何負面代價，並且正逐漸流行起來。所有主流瀏覽器已經支持它有一段時間了。

我們所有支持的客戶端在邊緣的 nginx 代理上啓用了 Brotli 支持。

轉向 Brotli 壓縮讓我們的文件傳輸大小中值減少了 21％-25％，從而減少了帶寬用量並縮短了加載時間。

響應大小中值

3 內容交付網絡（CDN）

 動態 CDN 選擇

在 Wix，我們一直使用 CDN 在用戶網站上提供所有 JavaScript 代碼和圖像。

最近，我們集成了一個 DNS 提供商的解決方案，可以根據客戶端的網絡和區域自動選擇性能最好的 CDN。這讓我們能爲每個訪問者從最佳位置提供靜態文件，並避免某些 CDN 的可用性問題。

 即將推出……CDN 提供的用戶域

問題的最後一部分是通過 CDN 提供最後，也是最關鍵的部分：用戶域中的 HTML。

如上所述，我們創建了自己的內部解決方案來緩存和提供特定於站點的 HTML 和 API 結果。在這麼多新區域維護這個方案是有運營成本的，添加新區域的流程也需要我們不斷維護和優化。

目前，我們正在集成多個 CDN 提供商，以支持直接從 CDN 位置提供整個 Wix 站點，從而改善我們的服務器在全球範圍內的分發效率，進一步縮短響應時間。由於我們服務的域衆多，因此這是一個挑戰，需要在邊緣進行 SSL 終止。

與 CDN 集成使 Wix 網站比以往任何時候都更貼近客戶，並且在加載體驗方面有了更多改進（包括諸如 HTTP/3 之類的更新技術），而這些改進無需我們付出更多努力。

4 關於性能監控說兩句

如果你在運營一個 Wix 網站，你可能想知道這些改進是如何轉變爲 Wix 網站性能結果的，以及我們如何與其他網站平臺進行比較。上面完成的大多數工作都在過去的一年中部署完畢，而有些工作仍在推廣中。

HTTPArchive 的 Web 年鑑（Web Almanac）最近發佈了 2020 年版，其中包括有關 CMS 用戶體驗的一個精彩章節。請記住，本文中提到的許多數字都是從 2020 年中期開始的。

https://almanac.httparchive.org/en/2020?fileGuid=g3TQWXCD6kc6ppKW

https://almanac.httparchive.org/en/2020/cms?fileGuid=g3TQWXCD6kc6ppKW

我們期待在 2021 年看到更新後的報告，並正在積極監控我們站點的 CrUX 報告以及我們的內部性能指標。

我們致力於不斷改善加載時間，併爲我們的用戶提供一個平臺，讓他們可以在不影響性能的前提下構建自己理想的網站。

移動網站的 LCP、速度指數和 FCP 的長期變化

DebugBear 最近發佈了一個非常有趣的 “網站構建器性能評估”，它涉及了我上面提到的某些領域，並檢查了在每個平臺上構建的非常簡單的網站的性能。該網站建於大約兩年前，此後未做過修改，但是平臺還在持續改進，網站性能也隨之提高。查看過去一年半的數據就可以找到證據。

https://www.debugbear.com/blog/website-builder-performance-review?fileGuid=g3TQWXCD6kc6ppKW

https://www.debugbear.com/project/175/pageLoad/873/overview?dateRange=2019-03-31T21:00Z-to-2021-03-31T21:59Z&fileGuid=g3TQWXCD6kc6ppKW

5 結論

我們希望我們的經驗能激勵你在組織中推行以性能爲導向的文化，也希望上面的信息對你的平臺或站點能有幫助。

總結一下：

• 選擇一組可以使用行業認可的工具進行一致跟蹤的指標，我們建議你使用 CoreWebVitals。

• 利用瀏覽器緩存和 CDN。

• 遷移到 HTTP/2（如果可能，遷移到 HTTP/3）。

• 使用 Brotli 壓縮。

原文鏈接：

https://web.dev/wix/?fileGuid=g3TQWXCD6kc6ppKW

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/0R9W9kttPQ9HemDEFMb91Q