本案例研究說明 Wix 導入的幾項重大變更，這些變更可改善數百萬個網站的網站載入效能，讓這些網站獲得良好的 PageSpeed Insights 和 Core Web Vitals 分數。
我們運用業界標準、雲端服務供應商和 CDN 功能，並重新編寫網站執行階段，根據 CrUX 和 HTTPArchive 的資料，Wix 網站達到所有 Core Web Vitals 指標良好 75 百分位數分數的百分比，相較於前一年增加了三倍以上。
Wix 採用以效能為導向的文化，並會持續為使用者推出更多改善措施。我們會著重於成效 KPI，因此預期通過網站使用體驗核心指標門檻的網站數量會增加。
總覽
效能的世界複雜而精彩，其中包含許多變數和複雜性。研究顯示，網站速度會直接影響轉換率和商家的收益。近年來，業界更重視成效可見度，並加快網頁速度。自 2021 年 5 月起，網頁體驗信號將納入 Google 搜尋排名。
Wix 面臨的獨特挑戰，是支援數百萬個網站，其中有些網站是在多年前建立，且從未更新過。我們提供各種工具和文章，協助使用者瞭解如何分析及改善網站成效。
Wix 是受管理的環境，並非所有內容都由使用者自行管理。共用通用基礎架構對所有網站而言都會帶來許多挑戰，但也為全面改善帶來商機，也就是善用規模經濟。
以通用語言交談
效能方面的核心難題之一，就是要找到通用的術語來討論使用者體驗的不同面向，同時考量技術和感知效能。在公司內部使用明確的通用語言，可讓我們輕鬆討論及分類不同的技術部分和取捨，釐清成效報表，並大幅協助我們瞭解應先著重改善哪些部分。
我們調整了所有監控和內部討論內容，納入業界標準指標，例如 Web Vitals，包括：
網站複雜度和成效分數
只要簡化網站，只使用 HTML 並透過 CDN 提供服務，就能輕鬆建立可立即載入的網站。
但實際上，網站的複雜度和複雜程度越來越高，運作方式更像應用程式而非文件，並支援網誌、電子商務解決方案、自訂程式碼等功能。
Wix 提供多種範本，讓使用者輕鬆建構具備多項商務功能的網站。這些額外功能通常會帶來一些效能成本。
旅程
起初，HTML 就已存在
每次載入網頁時，系統一律會先發出對網址的初始要求，以便擷取 HTML 文件。這個 HTML 回應會觸發所有額外的用戶端要求和瀏覽器邏輯，執行並轉譯您的網站。這是網頁載入作業中最重要的部分，因為在回應開始傳送之前，系統不會執行任何動作 (稱為 TTFB - 第一個位元組的時間)。
過去：用戶端轉譯 (CSR)
在運作大型系統時，您必須考量效能、可靠性和成本等因素，做出取捨。幾年前，Wix 使用了用戶端轉譯 (CSR)，在用戶端 (即瀏覽器) 上透過 JavaScript 產生實際的 HTML 內容，讓我們能夠支援大量網站，而無須支付龐大的後端營運成本。
有了 CSR，我們就能使用一般 HTML 文件，但該文件基本上是空白的。它只會觸發所需程式碼和資料的下載作業，然後用於在用戶端裝置上產生完整的 HTML。
今天：伺服器端算繪 (SSR)
幾年前，我們改用伺服器端算繪 (SSR)，因為這對 SEO 和效能都有益處，可改善初始網頁顯示時間，並確保不完全支援執行 JavaScript 的搜尋引擎能更好地編入索引。
這種做法可改善可見度體驗，特別是在速度較慢的裝置/連線中，並為進一步改善效能開啟了新的大門。不過，這也代表每個網頁要求都會動態產生專屬的 HTML 回應，這「絕非」是最佳做法，特別是對於有大量瀏覽量的網站。
推出多個位置快取功能
每個網站的 HTML 大多為靜態，但有幾點需要注意：
- 經常變動。每次使用者編輯網站或變更網站資料 (例如網站商店商品目錄)。
- 其中包含特定資料和 Cookie，這些資料和 Cookie 是特定訪客專屬，也就是說，兩位造訪同一網站的使用者會看到略有不同的 HTML。例如支援產品功能，例如記住訪客放入購物車的商品，或訪客先前與商家進行的即時通訊等。
- 並非所有網頁都能快取。舉例來說，如果網頁含有自訂使用者程式碼，並在文件中顯示目前時間，就無法快取。
一開始，我們採用相對安全的方法，也就是在不使用訪客資料的情況下快取 HTML，然後只針對每位訪客的每個快取命中，即時修改 HTML 回應的特定部分。
內部 CDN 解決方案
我們是透過部署內部解決方案來達成這項目標：使用 Varnish HTTP Cache 進行 Proxy 和快取作業、使用 Kafka 處理無效訊息，以及使用以 Scala/Netty 為基礎的服務，以便 Proxy 這些 HTML 回應，但會變更 HTML，並在快取回應中加入訪客專屬資料和 Cookie。
這個解決方案讓我們能夠在更多地理位置和多個雲端供應商區域 (遍及全球) 部署這些精簡的元件。我們在 2019 年推出超過 15 個新區域，並逐步為超過 90% 可進行快取的網頁瀏覽啟用快取功能。從其他位置提供網站，可讓內容更靠近網站訪客，進而減少用戶端與提供 HTML 回應的伺服器之間的網路延遲。
我們也開始使用相同的解決方案，並在網站內容有任何變更時，將快取無效，藉此快取特定的唯讀 API 回應。舉例來說，網站上的網誌文章清單會快取，並在文章發布/修改時失效。
降低複雜度
實施快取功能後，效能大幅提升，尤其是在 TTFB 和 FCP 階段，且透過更靠近使用者的位置提供內容，可提高可靠性。
不過，由於需要修改每個回應的 HTML，因此產生了不必要的複雜性，如果移除這些複雜性，就能進一步改善效能。
瀏覽器快取 (以及 CDN 的準備工作)
約 13%
直接從瀏覽器快取提供 HTML 要求，可節省大量頻寬，並縮短重複檢視畫面的載入時間
接下來，我們會在 HTML 到達後，從完整移除這類訪客專屬資料，並從用戶端為此呼叫的獨立端點擷取資料。
我們已小心將這些資料和 Cookie 遷移至新的端點，該端點會在每次網頁載入時呼叫，但會傳回精簡的 JSON，這項資料僅用於重新整理程序，才能達到完整的網頁互動性。
這讓我們能夠啟用瀏覽器的 HTML 快取功能，也就是說，瀏覽器現在會為重複造訪儲存 HTML 回應，並只呼叫伺服器來驗證內容是否未變更。這項操作會使用 HTTP ETag，這基本上是指派給 HTML 資源特定版本的 ID。如果內容仍相同，我們的伺服器會傳送 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 Almanac 壓縮章節所述。所有主要瀏覽器已支援這項功能一段時間。
我們已為所有支援 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 的網路年鑑最近發布了2020 年版，其中包含一章精彩的內容，說明內容管理系統使用者體驗。請注意，本文中許多數字均來自 2020 年中。
我們期待 2021 年推出的更新版報表，並積極監控網站的 CrUX 報表和內部成效指標。
我們致力於持續改善載入時間，並為使用者提供平台，讓他們能按照自己的構想建構網站，同時不犧牲效能。
DebugBear 最近發布了一篇非常有趣的網站架構工具效能評論，內容涵蓋我上述提到的部分領域，並檢視在各個平台上建立的簡單網站效能。這個網站是在將近兩年前建立，自此之後就沒有修改，但平台會持續改善，網站成效也會隨之提升，只要查看資料，就能瞭解過去一年半的情況。
結論
我們希望我們的經驗能激勵您在貴機構中採用以成效為導向的文化，並希望上述詳細資料對您的平台或網站有所幫助。
總結如下：
- 選擇一組指標，以便您持續使用業界認可的工具進行追蹤。我們建議使用網站體驗核心指標。
- 善用瀏覽器快取和 CDN。
- 遷移至 HTTP/2 (或盡可能遷移至 HTTP/3)。
- 使用 Brotli 壓縮。
感謝您瞭解我們的發展歷程。歡迎在 Twitter 和 GitHub 上發問問題、分享想法，並在您偏好的管道上加入網頁效能討論。