個案研究：Wix 導入了幾項重大變更，改善數百萬個網站的網站載入速度，讓這些網站取得良好 PageSpeed Insights 和網站體驗核心指標分數的機會。
得益於業界標準、雲端服務供應商和 CDN 功能，加上我們網站執行階段的重大改寫，根據 CrUX 和 HTTPArchive 的資料，Wix 網站在所有 Core Web Vitals 指標中，達到 75 個百分位數良好分數的 Wix 網站百分比超過三倍。
Wix 採用效能導向的文化，而日後將繼續推出改善功能。目前我們將重心放在效能 KPI，預計會發現達到網站體驗核心指標門檻的網站數量會增加。
總覽
效能的世界具有絕妙的複雜，有許多變數和細節。研究顯示，網站速度對轉換率和收益有直接影響。近年來，業界越來越重視效能的可視性，並加快網頁連線速度。自 2021 年 5 月起，Google 搜尋排名將納入網頁體驗信號。
Wix 面臨的獨家挑戰，就是支援數百萬個網站，其中有些網站是在多年前成立，且不曾更新。我們提供多種工具和文章，協助使用者瞭解如何分析及提升網站效能。
Wix 是代管環境，並非使用者都能獲得。 共用通用的基礎架構會對上述所有網站帶來許多挑戰，但同時也開啟企業整體重大改進的機會，即利用規模經濟。
以共通語言說話
效能的一大難題，是找出共通的術語來討論使用者體驗的不同層面，同時又在思考技術和感知效能時。只要使用組織內明確定義的通用語言，我們就能夠輕鬆討論及分類不同的技術部分和權衡方法、釐清成效報表內容，也讓瞭解我們應該優先改善哪些方面。
我們調整了所有監控和內部討論內容，加入網站體驗指標等業界標準指標，包括：
網站複雜度和效能分數
建立網站並不容易，只要設計得非常簡單，只要使用 HTML 並透過 CDN 放送即可。
然而實際上，網站越來越複雜且複雜，以應用程式而非文件的形式運作，並支援網誌、電子商務解決方案、自訂程式碼等功能。
Wix 提供種類繁多的範本，讓使用者輕鬆建構具備許多企業功能的網站。這些額外的功能通常會產生「部分」效能成本。
旅程
一開始
每次載入網頁時，都必須先向網址發出初始要求，才能擷取 HTML 文件。此 HTML 回應會觸發所有額外的用戶端要求和瀏覽器邏輯，以執行及轉譯您的網站。這是網頁載入中最重要的部分，因為直到回應開始之前才會發生任何內容 (又稱為 TTFB - 到第一個位元組的時間)。
過去：用戶端轉譯 (CSR)
當您執行大規模的系統時，總需要權衡效能、可靠性和成本等因素。早在幾年前，Wix 使用了用戶端轉譯 (CSR)，在用戶端 (例如瀏覽器) 上透過 JavaScript 產生實際 HTML 內容，讓我們可以支援大量網站，而無需耗費大量的後端作業成本。
CSR 讓我們能使用常見的 HTML 文件，基本上是空的。這全都是觸發下載必要程式碼和資料的行為，再用於在用戶端裝置上產生完整的 HTML。
目前：伺服器端轉譯 (SSR)
幾年前，我們改採伺服器端轉譯 (SSR) 的做法，因為這項工具不但有助於搜尋引擎最佳化 (SEO) 並提升效能、縮短初始網頁曝光時間，也確保沒有針對執行 JavaScript 的搜尋引擎能更妥善地建立索引。
這個方法可以改善瀏覽權限體驗，特別是在速度較慢的裝置/連線速度緩慢時，也開啟了進一步效能最佳化的大門。然而，這也代表每個網頁要求都會即時產生不重複的 HTML 回應，這是一種「極大」回應，尤其對於觀看次數大量的網站更是如此。
在多個位置推出快取功能
每個網站的 HTML 大多都是靜態的，但有幾點注意事項：
- 資料經常變動。每次使用者編輯網站或變更網站資料 (例如網站商店商品目錄資料) 時。
- 其中含有特定訪客的資料和 Cookie，也就是說，造訪相同網站的兩位使用者看到的 HTML 會稍有不同。例如支援產品功能，例如記住訪客放進購物車的項目，或訪客稍早以商家發起的即時通訊等。
- 並非所有網頁都可供快取。舉例來說，如果網頁中有自訂使用者程式碼，並在文件中顯示目前時間，就不符合快取的資格。
起初，我們採用相對安全的方法，在「沒有」訪客資料的情況下快取 HTML，然後只針對每位訪客每次快取命中，即時修改 HTML 回應的特定部分。
內部 CDN 解決方案
為此，我們部署了一項內部解決方案：使用 Varnish HTTP 快取進行 Proxy 處理和快取、Kafka 處理無效訊息，以及以 Scala/Netty 為基礎的服務來代理這些 HTML 回應，但會變更 HTML，並將訪客專屬資料和 Cookie 新增至快取回應。
這個解決方案讓我們能夠將這些精簡元件部署至全球更多的地理位置和多個雲端服務供應商區域，並部署在世界各地。我們在 2019 年推出了超過 15 個新地區，並逐漸針對超過 90% 的可快取網頁檢視啟用快取功能。 從其他位置提供網站，藉由將內容拉近網站訪客的位置，縮短用戶端和提供 HTML 回應的伺服器之間的網路延遲時間。
我們也開始快取特定的唯讀 API 回應，方法是使用相同的解決方案，並在網站內容發生任何變更時撤銷快取。舉例來說，系統會快取網站上的網誌文章清單，並在發布/修改文章時失效。
減少複雜性
實作快取可以大幅提升效能 (多半在 TTFB 和 FCP 階段上)，並透過從更靠近使用者的位置提供內容，進而改善我們的可靠性。
然而，必須為每個回應修改 HTML，這會造成不必要的複雜性，移除後，有機會可以進一步提升效能。
瀏覽器快取 (以及 CDN 的準備)
約 13%
直接透過瀏覽器快取提供的 HTML 要求，不僅能節省頻寬，還能縮短重複檢視畫面的載入時間
下一步是實際將這項訪客資料從 HTML 中「完全」移除，然後在 HTML 產生後，透過用戶端呼叫的獨立端點擷取這些資料。
我們小心地將這些資料和 Cookie 遷移至新的端點，系統會在每次載入網頁時呼叫這個新端點，但會傳回精簡的 JSON，只有在飲水程序需要，才能達到完整頁面互動功能。
這讓我們得以啟用 HTML 的瀏覽器快取功能，表示瀏覽器現在會為了重複造訪而儲存 HTML 回應，並且只呼叫伺服器來確認內容並未變更。這時可以使用 HTTP ETag，這個 HTTP ETag 基本上是指派給 HTML 資源特定版本的 ID。如果內容仍相同，則我們的伺服器會將 304 Not Modified 回應傳送至用戶端，而且不會有主體。
此外，這項變更也意味著我們的 HTML 不再是訪客專用，也不包含 Cookie。換句話說，您基本上可以在任何地方快取及快取，因此能採用 CDN 供應商在全球數百個地點具有更佳地域性的 CDN 供應商。
DNS、SSL 和 HTTP/2
啟用快取後，等待時間縮短了，初始連線的其他重要部分也變得更加顯著。我們強化網路基礎架構和監控功能，成功改善 DNS、連線和安全資料傳輸層 (SSL) 時間。
所有使用者網域均已啟用 HTTP/2，減少每次新連線時所需的連線數量和負擔。這是相對簡單的部署變更，同時利用 HTTP/2 提供的效能與彈性優勢。
Brotli 壓縮 (相較於 gzip)
21 - 25%
縮減檔案傳輸大小中位數
以往，我們所有檔案都會使用 gzip 壓縮壓縮，這是網路上最常見的 HTML 壓縮選項。這個壓縮通訊協定起初在近 30 年前就已推出！
新的 Brotli 壓縮在幾乎沒有權衡的情況下導入了壓縮改善功能，並且逐漸成為較為熱門的功能，如《Web Almanac Compression Chapter》年度所述。所有主要瀏覽器都已經支援一段時間。
我們為邊緣網路中的 nginx Proxy 啟用 Brotli 支援，支援所有支援 Proxy 的用戶端。
改用 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 最近發布了一項非常有趣的網站製作工具效能審查，探討我提及的部分領域，並檢視在各個平台上建構的簡易網站成效。這個網站建構於近兩年內，且至今仍未修改，但平台不斷改善，其網站效能也會不斷提升，如要檢視該網站的效能，則可查看過去一年半年的資料。
結論
希望 Google 的經驗可激勵貴機構採用成效導向的文化，且上述詳細資料實用且適用於您的平台或網站。
總結：
- 挑選一組可以持續使用業界認可的工具進行追蹤的指標。建議使用網站體驗核心指標
- 可運用瀏覽器快取和 CDN。
- 遷移至 HTTP/2 (如果可能，或改用 HTTP/3)。
- 使用 Brotli 壓縮。
感謝您瞭解我們的故事，並邀請您在 Twitter 和 GitHub 上提問、分享想法，以及加入您最愛的管道上的網站效能對話。