前端體驗優化地最終目的就是讓使用者的使用體感舒適,無阻塞、流暢的得到預期想要的結果,而其中的使用者可分為三層:產品使用者、公司同事和研發自己。UX、效能優化其實都是體驗優化的子集,前端體驗猶如下圖的冰山那樣,在水下別有洞天。
可以將體驗優化大致分為 5 個模組,分別是終端、網路、前端、後端以及資料,這 5 個模組可以形成一個閉環。
終端就是瀏覽器、微信等一類裝置,網路就是快取、協定等一類概念,前端和後端針對的就是技術細節,而資料其實就是最後的分析,對優化前後進行量化對比,最終得出結論,判斷此次優化是否成功。
與以往的視覺體驗優化(例如線框圖的不同佈局)不同,本文著重分析的前端體驗側重於技術端和資料分析,更偏向於前端開發人員,而不是 UI 設計人員。
下面是一張前端體驗優化的思維導圖,還在持續更新中。
其中終端模組的影象、呈現,網路模組,前端模組的 JavaScript、構建都被記錄在前端效能精進專欄中。
資料模組的效能指標記錄在方法論之測量和分析,監控體系記錄在監控系統專欄內(包括 SDK、儲存和分析、頁面奔潰)。
終端優化的核心是減少渲染時間,網路優化的核心是減少延遲時間,另外三個模組都在服務於這兩個模組。
下圖描繪了網頁在載入過程中,各階段與上述模組之間的優化關係。
終端最常用的就是瀏覽器,瀏覽器最需要關注的優化點是兩個:影象和呈現。
微信是一款國民級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營收、紀錄檔釋出率等),指標的變化就是核心業務的變化。
而在這個指標下面,還有許許多多的細節指標,支撐著北極星指標,以會員為例,日付費人數、日下單量、首次充值人數等。
如果有條件的話,可以讓分析人員開放些與自己有關的指標,再與相關人員緊密溝通,讓這些資料更有活性。