Zalando 的網頁團隊發現，整合 Lighthouse CI 後，便能採取主動式效能做法，透過自動狀態檢查功能比較目前對主要分支的提交內容，以防效能退步。
Zalando 擁有超過 3,500 萬名活躍客戶，是歐洲首屈一指的線上時尚平台。本篇文章將說明我們開始使用 Lighthouse CI 的原因、導入的簡易性，以及這項工具對我們團隊的好處。
我們瞭解網站成效與收益之間的關係。過去，我們曾測試人為增加目錄頁面載入時間對跳出率、轉換率和每位使用者的收益有何影響。結果很明顯。網頁載入時間縮短 100 毫秒後，參與度提高、跳出率降低，單次工作階段收益也提升了 0.7%。
100 毫秒
改善網頁載入時間
0.7%
單次工作階段收益增加
公司採購不一定能轉化為成效
儘管公司內部對成效的支持度很高，但如果未將成效設為產品提交條件，成效就很容易下滑。我們在 2020 年重新設計 Zalando 網站時，著重於提供新功能，同時維持優異的使用者體驗，並透過自訂字型和更鮮豔的色彩，為網站進行大改造。不過，當重新設計的網站和應用程式準備好發布時，早期採用者指標顯示新版本的速度較慢。首次顯示內容所需時間最慢會慢 53%，而我們測量的互動時間最慢會慢 59%。
Zalando 的網站
Zalando 網站是由開發架構的核心團隊建立，有超過 15 個功能團隊提供前端微服務。除了支援新版本，我們也將部分網站轉換為更集中的架構。
先前的架構稱為「Mosaic」，其中包含一種方法，可透過內部指標評估網頁成效。不過，由於缺乏內部研究室效能監控工具，因此在向實際使用者推出前，很難比較效能指標。雖然每天都會進行部署，但開發人員在改善效能時，大約需要一天的時間才能獲得意見回饋。
網站體驗指標和 Lighthouse 可提供協助
我們對自家指標不甚滿意，因為這些指標無法配合新設定。更重要的是，這些服務並未以客戶體驗為重心。我們改用網站使用體驗核心指標，因為這項指標提供精簡、全面且以使用者為主的指標。
為了在發布前改善效能，我們需要建立適當的實驗室環境。除了代表實地資料第 90 百分位數的測試條件外，這項測試也提供了可重現的測量值。如今，致力於改善效能的工程師知道該將心力集中在哪些地方，以便發揮最大影響力。我們已經在本機使用 Lighthouse 稽核報表。 因此，我們在第一個迭代中，以 Lighthouse 節點模組開發服務，以便在測試環境中測試變更。這讓我們獲得可靠的效能回饋循環，大約一小時後，我們就能讓效能達到相同水準，並保存我們的版本！
針對提取要求向開發人員提供效能意見回饋
我們不想就此打住，因為我們希望藉此機會，不僅能對成效採取反應措施，還能採取主動措施。從 Lighthouse 節點模組轉換至 Lighthouse CI (LHCI) 伺服器並不困難。我們選擇採用自架式解決方案，以便與現有公司服務進行更完善的整合。我們的 LHCI 伺服器應用程式會以 Docker 映像檔的形式建構，然後與 PostgreSQL 資料庫一起部署至 Kubernetes 叢集，並回報至 GitHub。
我們的架構已向開發人員提供一些效能回饋，也就是在每次提交時，將元件套件大小與閾值比較。我們現在可以將 Lighthouse 指標回報為 GitHub 狀態檢查。如果這些項目未達到效能門檻，就會導致 CI 管道失敗，並提供 Lighthouse 詳細報表的連結，如以下圖片所示。
擴大效能涵蓋範圍
我們一開始採用務實的方法。目前 Lighthouse 只會在兩個最重要的網頁上執行：首頁和產品詳細資料頁面。幸好，Lighthouse CI 可讓您輕鬆擴充執行設定。負責網站特定網頁的功能團隊可以設定相符的網址模式和斷言。我們相信，這項功能推出後，成效涵蓋率將會提高。
我們現在在建構較大型版本時，可以更有信心，開發人員也能更快獲得程式碼效能的意見回饋。