前端體驗優化地最終目的就是讓使用者的使用體感舒適，無阻塞、流暢的得到預期想要的結果，而其中的使用者可分為三層：產品使用者、公司同事和研發自己。UX、效能優化其實都是體驗優化的子集，前端體驗猶如下圖的冰山那樣，在水下別有洞天。

　　

　　可以將體驗優化大致分為 5 個模組，分別是終端、網路、前端、後端以及資料，這 5 個模組可以形成一個閉環。

　　終端就是瀏覽器、微信等一類裝置，網路就是快取、協定等一類概念，前端和後端針對的就是技術細節，而資料其實就是最後的分析，對優化前後進行量化對比，最終得出結論，判斷此次優化是否成功。

　　與以往的視覺體驗優化（例如線框圖的不同佈局）不同，本文著重分析的前端體驗側重於技術端和資料分析，更偏向於前端開發人員，而不是 UI 設計人員。

　　

　　下面是一張前端體驗優化的思維導圖，還在持續更新中。

　　

　　其中終端模組的影象、呈現，網路模組，前端模組的 JavaScript、構建都被記錄在前端效能精進專欄中。

　　資料模組的效能指標記錄在方法論之測量和分析，監控體系記錄在監控系統專欄內（包括 SDK、儲存和分析、頁面奔潰）。

　　終端優化的核心是減少渲染時間，網路優化的核心是減少延遲時間，另外三個模組都在服務於這兩個模組。

　　下圖描繪了網頁在載入過程中，各階段與上述模組之間的優化關係。

　　

一、終端

　　終端最常用的就是瀏覽器，瀏覽器最需要關注的優化點是兩個：影象和呈現。

1. 在網頁中充斥著影象，而影象往往會增加網頁的尺寸，所以優化的重點是用盡手段減小尺寸，例如動態裁剪、響應式、WebP、載入時機的轉變等等。
2. 呈現涉及瀏覽器渲染和靜態資源的請求，核心就是縮短渲染和資源載入時間，例如只渲染首屏、提前載入後續資源、對重要資源優先請求等等。

　　微信是一款國民級APP，提供了 JSSDK 和小程式的功能，JSSDK 賦予了使用者部分微信的能力，依託微信的生態，小程式現在有了非常廣泛的應用。所以對於這個環境，也會有各類獨特的優化手段，不過我本人還不熟悉這塊。

　　還有一個很重要的終端就是各類 APP 內建的 WebView，使用者端通過 WebView 可以暴露出許多功能，幫助前端頁面的優化，例如喚起使用者端的登入和支付介面，還有就是最大限度的快取網頁資源，減少網路請求，例如容器化、離線包。

　　除此之外，還可以增加預請求的能力，將序列的網路請求優化為並行的網路請求，充分利用空閒時間。

　　諸如 Electron、WebRTC、多媒體等這類優化點，自己並不是很熟悉，在此也不再贅述。

二、網路

　　當一個請求從終端發出到伺服器接收，這段網路傳輸的時間，其實是我們不可控的。

　　要優化就只能從起點和終點兩處入手。最先想到的就是開啟快取：強快取和協商快取。

　　日常使用最多的是協商快取，但是在效能提升上，決定強快取更為明顯，因為強快取後就不會再去伺服器請求資源。

　　不過，為了頁面正確，還得設法破壞快取，尤其是 HTML 檔案，例如給 URL 包一層短鏈，在請求時自動加個時間戳，以此讓快取不再命中。

　　HTTP 是一種網路協定，目前已經可以廣泛使用 HTTP/2 協定，在之前的基礎上做了許多優化，例如二進位制分幀層、多路通訊、首部壓縮等，讓資料傳輸的更快以及更大限度的利用好頻寬。

　　協定中的壓縮欄位，預設都已經開啟，對於非媒體檔案（例如 HTML、CSS、JavaScript 等）經過壓縮後，尺寸可減少 50%，甚至 80%。

　　HTTP/3 協定解決了上一個協定的幾個問題，例如 TCP 隊首阻塞、網路切換成本等，不過目前最大的問題還是支援度不夠，不能大範圍的使用。

　　HTTPS 是 HTTP 的安全版本，目前有些瀏覽器預設會將 HTTP 的請求重定向到 HTTPS，這種多餘的重定向完全可以避免。

　　CDN 是一種網路加速服務，目前有很多公司都提供了這類服務，但就是要花錢，只要花錢了，海外都能給你加速，無論靜態資源還是動態介面，都可以藉助 CDN 加速，現在還能提供對影象的動態裁剪和壓縮的功能。

　　有時候瀏覽網頁會遇到閘道器報出的 500、502、503、504 等錯誤，其實就是服務異常、找不到轉發服務或轉發服務在指定時間內未響應。

　　對於未響應，可以從相關分析平臺找出效能瓶頸，然後在後端部分進行程式碼優化，很多時候與資料庫有關。無論如何，要盡一切可能避免此類錯誤，這類體驗最為糟糕，無法得到預期結果。

三、前端

　　前端現在已經離不開工程化構建，常見的 Webpack、Rollup 等打包工具提供了許多優化功能，例如壓縮、合併、剪枝等，儘量減少網路請求和資源尺寸。

　　除此之外，儘量減少和選擇輕量級的依賴庫，也能降低不少的尺寸。隨著 IE 這個毒瘤退出舞臺，行動端興起之後，ES6 也被廣泛的支援，很多時候都沒必要降級到 ES5，再也不用平白無故的多出一大段程式碼了。

　　ESBuild 也是一個構建工具，不過與之前的不同，它內部是用 go 編寫的，所以說它非常快。

　　Vite 的開發環境依賴的就是它，但是為了快，就沒有提供 AST 的操作能力，導致目前很多的外掛無法使用，所以 Vite 生產環境使用的還是 Rollup，是對效能與靈活性的一種平衡。

　　前端三劍客之一的 JavaScript，是每個前端開發人員每日必會使用到的，對於它的優化基本上都是程式碼層面的優化，常見的節流和防抖，演演算法和資料結構，分解或非同步執行長任務，本地儲存等。

　　有個庫叫 Partytown.js，比較有意思，可以將第三方指令碼遷移到 Web Worker 中執行，防止阻塞主執行緒，不過這還只是個測試性的庫。

　　前端為了讓自己的日常工作比較爽，技術棧不能太舊，否則很多新功能都體驗不到，太可惜了。在升級技術棧時，還不能影響業務，運營、產品等人可不會在意你用什麼技術棧，他們在意的是業務保持穩定，並且還能持續迭代。

　　前端的基建包括元件化、標準化、工具化、自動化、檔案化以及頁面規範化，本質就是讓自己組的開發效率能更高，與別人共同作業發生的錯誤能更少，產品上線後最好沒有問題。一句話就是你要好，大家也要好，和諧辦公。

　　在功能上線前，可以對新功能加個開關，萬一有問題，就直接關閉新功能，粒度可以是頁面級別的。不過前端發版不像使用者端那麼困難，畢竟做開關是要成本的。灰度和 A/B 測試，在前端也可以執行。

四、後端

　　傳統的前端開發是不接觸後端的，但是自從 Node.js 拓寬了前端的邊界後，越來越多的前端開始涉足後端，那麼就很有必要了解後端的體驗優化。

　　後端的優化大致可分為兩部分：Node.js 和資料庫，對於它們的監控，市面上有許多成熟的平臺，自己搭建的話，成本有點高。

　　我剛到公司時，還在用 Node.js 的 8.7 版本，明顯太老，在挑選第三方庫時，還得特地挑老版本，所以說，要將版本進行最適當的升級，在改造成本最小的前提下，升級到最高的那個版本。

　　上一節講到基建，其中很多內容都是需要藉助 Node.js 實現的，例如通用設定、指令碼執行等。

　　還有下一節中的監控系統，也需要 Node.js 實現，並且還要涉及到訊息佇列、MySQL、ElasticSearch 等技術點。注意，對於那些非業務服務，需要單獨分離，以免異常時影響線上業務。

　　在有了後端能力後，就能自己寫介面，介面的響應格式很重要，在統一後，更容易分析介面的成功和失敗細節。並且對於介面，要有安全意識，以及不能因為介面的問題而讓頁面直接異常，需要用更友好的反饋方式。

　　目前市面上有許多種資料庫，常見的關係型資料庫 MySQL，遇到比較多的問題就是資料量上去後的慢響應，很可能導致 504 異常，要麼縮小查詢範圍，要麼就是建立合適的索引。

　　MySQL 處理百萬級的資料量綽綽有餘，但千萬級就比較夠嗆了，此時除了索引加持外，還需要進行分表、資料歸檔等手段，其實本質都是為了減少資料量。

　　與之前的 Node.js 服務類似，對於那些非業務表，可以單獨生成一個庫來儲存，也是避免資料庫異常導致線上業務出錯。

　　MySQL 全文檢索的能力不行，所以對於巨量資料量的全文檢索需要改用 ElasticSearch，還有那些需要聯多張表的情況，也可以將資料儲存到 ElasticSearch 中再做查詢。

　　Redis 其實也是一種非關係型的資料庫，最大的特點就是快，若要對介面的查詢進行優化， Redis 無疑是一種高效的手段。

　　不過在用 Redis 時需要注意，它只是一種快取，若沒有它，也要能得到預期的資料。也就是說，儘量不要讓業務邏輯依賴 Redis 中的資料，Redis 只是為了加速，即使沒有了它，線上業務也不應該出錯。

五、資料

　　為了能更好的優化體驗，很有必要量化效能，以及監控頁面的方方面面。

　　首先關於效能，目前已有很多工具，例如 Lighthouse、WebPageTest 和 Chrome Devtools，它們會分析頁面的效能，不過這些只能算是實驗室資料，並不是真實使用者的資料。

　　我們自研了效能監控系統，記錄了一系列的指標，包括白屏、首屏等，在蒐集過後，提供了多種圖表進行效能分析。

　　力圖重現真實使用者的使用場景，發現效能瓶頸。前端監控也是自研的，會記錄頁面的異常、通訊、點選等行為，同樣提供了各類圖表。

　　通過此係統，可以主動發現頁面中的錯誤，而不是等待使用者上報，並且還發現了許多冗餘介面。

　　除此之外，每天都會推播核心指標到前端的飛書群中，包括介面慢響應占比、SLA（服務質量保證，即5XX佔比）等，關注服務的健康度。

　　線上還會實時監控頁面、介面和資料庫的錯誤情況，當達到某一個閾值時，就會傳送告警到飛書中，同樣是為了在使用者上報前發現問題。

　　為了能更好的與公司同事共同作業，我們組制訂的每雙月的需求提測率和使用者滿意度評分，當然，這個使用者是內部員工。

　　之所以是提測率而不是完成率，是因為很多時候專案是要與伺服器端共同作業的，可能我們做完了，他們還沒完成，而這種情況還比較普遍，所以就使用了提測率。

　　除了技術監控之外，前端人員還需要了解業務監控資料，其實也是為了讓自己能更好的理解業務，培養產品思維。

　　通過埋點將某一處的動作，傳輸到伺服器做儲存，然後再經過資料分析人員，繪製成一張張的圖表。埋點的採集並不複雜，常見的就是侵入式的在某一處位置加入埋點程式碼。

　　若對頁面做了某種優化，涉及到業務邏輯時，可以分析埋點資料，比對前後的變化，來決定優化是否成功。

　　在我們公司，每一個小組都會有一個或兩個北極星指標（例如使用者新增數、XX營收、紀錄檔釋出率等），指標的變化就是核心業務的變化。

　　而在這個指標下面，還有許許多多的細節指標，支撐著北極星指標，以會員為例，日付費人數、日下單量、首次充值人數等。

　　如果有條件的話，可以讓分析人員開放些與自己有關的指標，再與相關人員緊密溝通，讓這些資料更有活性。