前端體驗優化地最終目的就是讓用戶的使用體感舒適，無阻塞、流暢的得到預期想要的結果，而其中的用戶可分爲三層：產品用戶、公司同事和研發自己。UX、性能優化其實都是體驗優化的子集，前端體驗猶如下圖的冰山那樣，在水下別有洞天。
可以將體驗優化大致分爲 5 個模塊，分別是終端、網絡、前端、後端以及數據，這 5 個模塊可以形成一個閉環。
終端就是瀏覽器、微信等一類設備，網絡就是緩存、協議等一類概念，前端和後端針對的就是技術細節，而數據其實就是最後的分析，對優化前後進行量化對比，最終得出結論，判斷此次優化是否成功。
與以往的視覺體驗優化（例如線框圖的不同佈局）不同，本文着重分析的前端體驗側重於技術端和數據分析，更偏向於前端開發人員，而不是 UI 設計人員。
下面是一張前端體驗優化的思維導圖，還在持續更新中。
其中終端模塊的圖像、呈現，網絡模塊，前端模塊的 JavaScript、構建都被記錄在前端性能精進專欄中。
數據模塊的性能指標記錄在方法論之測量和分析，監控體系記錄在監控系統專欄內（包括 SDK、存儲和分析、頁面奔潰）。
終端優化的核心是減少渲染時間，網絡優化的核心是減少延遲時間，另外三個模塊都在服務於這兩個模塊。
下圖描繪了網頁在加載過程中，各階段與上述模塊之間的優化關係。
一、終端
終端最常用的就是瀏覽器，瀏覽器最需要關注的優化點是兩個：圖像和呈現。
- 在網頁中充斥着圖像，而圖像往往會增加網頁的尺寸，所以優化的重點是用盡手段減小尺寸，例如動態裁剪、響應式、WebP、加載時機的轉變等等。
- 呈現涉及瀏覽器渲染和靜態資源的請求，核心就是縮短渲染和資源加載時間，例如只渲染首屏、提前加載後續資源、對重要資源優先請求等等。
微信是一款國民級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營收、日誌發佈率等），指標的變化就是核心業務的變化。
而在這個指標下面，還有許許多多的細節指標，支撐着北極星指標，以會員爲例，日付費人數、日下單量、首次充值人數等。
如果有條件的話，可以讓分析人員開放些與自己有關的指標，再與相關人員緊密溝通，讓這些數據更有活性。