網站性能（網站性能之單頁面應用的雜談）

背景都是經驗貼，也歡迎查看我寫的其他文章對前端性能優化的一些小看法 – 掘金網站應用性能簡析 – 掘金裸奔的前端綠皮車-網站裸奔現狀 – 掘金如何快速搭建全鏈路平臺，展示服務拓撲以分析性能？ – 掘金四個簡單例子教你通過用戶行為記錄提高用戶體驗 – 掘金網站性能指標設計詳解 – 掘金報錯/卡頓是衡量產品體驗的基本要素 – 掘金異軍突起的SPASingle Page application，譯為單頁面應用，也就是SPA應用，相比多頁面應用有很多優勢。對於使用react或者vue的js開發者來說，spa給前端應用邏輯帶來瞭極大的靈活性，降低瞭對後端和運維的依賴。對於用戶來說，SPA應用能提供高度可交互的UI和更快的頁面加載，帶來更流暢的用戶體驗。當然，隨著頁面復雜度的攀升，也有一些不足（tradeoffs）。比如，用戶可能使用老款、性能差的設備，而開發者去測試這些設備，可能就意味著要增加額外的復雜度，這對開發者無疑是一種負擔。開發者需要觀測終端用戶體驗，才能保證網站在所有設備上的流暢度。拖後腿的觀測方法和工具然而，前端觀測方法和工具的發展程度，遠遠跟不上javascript和SPA應用的發展。傳統的前端性能監控隻是依賴監測頁面的加載的耗時情況。對於SPA應用來說，雖然隻有一個頁面，傳統性能監控僅僅針對最開始頁面加載的幾秒鐘。而且隨著用戶在SPA 應用中跳轉，瀏覽器會重新根據新數據狀態渲染頁面組件，而不是重新加載document。想要精確監控應用的性能，就需要追蹤能影響用戶體驗的動態頁面元素，包括動畫、api調用和渲染生命周期。就前端架空而言，建議從用戶的視角入手，通過以時間為維度監聽瀏覽器事件和追蹤用戶行為。Google和W3C性能工作組把觀測用戶交互作為網站性能的基礎，為此已重新定義新的API。使用這些api能分解交互元素，細顆粒度的分解交互元素的時間耗時和構建應用的可視化。本文結構本文將專門講解觀測單頁應用的三個方面來改善用戶體驗：路由變化，記錄頁面跳轉耗時用戶交互，保證流暢用戶體驗收集錯誤，捕獲和調試錯誤詳情路由變化越來越復雜的SPA 路由web應用中流暢的切換速度對於用戶體驗至關重要。假如電商單頁應用包含促銷的落地頁，落地頁中有很大的宣傳產品的圖片，用戶可以通過頁面或者鏈接訪問，或者點擊進入主頁面。此時，為瞭保障頁面平滑跳轉，就需要決定圖片需要在兩秒甚至更短的時間內加載。一旦超過耗時，用戶就會失望離開。測量網站切換的常見方法是追蹤最大內容渲染（LCP），根據最大的元素（圖片、video、svg）能夠可見的時間來推測頁面何時加載結束從而頁面可見。但是因為SPA修改瞭頁面路由後，重新渲染頁面組件，老頁面的最大元素不會再新的頁面重新加載，所以測量加載時間就需要找到方式檢測瀏覽器得變化，而不是單獨依靠標準的加載事件。下圖展示傳統頁面和spa瀏覽器加載事件。在這個例子中，除瞭頁面加載事件，建議監聽路由變化並用於計算性能指標。監聽路由變化為瞭追蹤路由變化，需要在代碼中插樁監聽瀏覽器不同事件（而不隻是監聽完整的頁面加載）。Timing API方便用戶自定義加載的指標，滿足用戶精確計算頁面和資源加載的時間。History的API首先，使用瀏覽器 History的API，監聽“popstate”事件，該事件會在瀏覽器路由變化時被觸發（此時需要考慮到該事件可能表示一個完整的新頁面的情況）；其次，使用用戶Timing api設置一個·window.performance.mark()·用來標識路由變化已經開始。window.onpopstate = function(e) {
window.performance.mark('route_change_start');
}

…after requests finish and components render

window.performance.measure('route_change','route_change_start')
一旦選擇的新頁面組件作為就緒指標被渲染後（這個例子中是英雄的照片），就可以把指標傳遞給’window.performance.measure‘這個函數，隨後函數會創建結束標識並計算兩者之間的差值。這樣很容易記錄應用路由切換的加載時間，繼而發送給日志服務，比如觀測雲 – 觀測雲。在計算每個路由變化事件的時間時，追蹤每個資源的加載時間對於定位緩慢發生位置也非常有幫助。下圖是一個路由變化的瀑佈圖，圖中展示瞭加載字體和json文件的耗時。能看到整個頁面完全加載耗時2.26s，很容易能精確看出哪些文件導致網站緩慢，看到哪些文件加載時的錯誤。自動化：節省時間手動追蹤路由變化需要為每次頁面切換增加標識，這樣非常麻煩。另一種計算頁面切換耗時的方法是先創建一個循環，一旦檢測到路由變化就觸發循環。比如，可以在初次性能標識創建後，在應用中插樁，每100ms檢查一次，看是否有網絡請求或者dom變化。如果期間發生變化或者dom 加載，循環就等待100ms再次觸發。否則，就把之前的100ms作為加載時間。觀測雲 – 觀測雲是用類似的方法來追蹤SPA頁面變化。用戶交互追蹤用戶使用應用的關鍵交互行為的耗時能暴露“緩慢”。為瞭改善用戶體驗，應該盡可能地多收集細顆粒度的信息。繼續使用電商網站的例子，當用戶把商品添加到購物車時，用戶的動作觸發一個模態彈窗，彈窗內包含一些推薦的產品。這個關鍵交互需要重點監控，因為這個動作觸發瞭瀏覽器很多行為，包含一系列的api調用，同時更新數據狀態，還有組件的重渲染。以上任意的任務latency都能指數級增加耗時，如果用戶使用移動設備或舊設備。如果彈窗加載耗時太久，或者反饋耗時太久，用戶購物意願受阻，網站可能就要丟失一個客戶瞭。監聽用戶事件event listeners在路由切換時，可以給關鍵的UI元素添加監聽事件event listeners，比如按鈕點擊、滾屏和按鈕，因為它們都能觸發狀態變更。添加監聽事件有利於快速追蹤重要的用戶交互的加載時間和定位耗時最久的情況。需要強調的是，經證實，超過100ms這個臨界值，用戶交互便不自然不流暢。全鏈路監控的重要性SPA頁面中關鍵用戶交互行為，包括modal flow，通常依賴多個隱藏在屏幕背後的任務，比如api調用、數據狀態變更以及組件渲染。這就意味著監控這些後端處理的性能對於判斷前端latency的原因非常重要。比如產品modal的緩慢可能來源於api接口的超時，而這一點僅僅監控頁面加載是不夠的。能夠看到各個技術棧每層的情況有助於定位是代碼或者數據庫導致瞭前端緩慢的問題。比如，下圖能看到前端觸發請求/products.json接口的請求火焰圖。我們能夠分解對此次請求出發的網絡請求和後端任務進行分解。每個span都包含耗時和執行的詳細上下文，包括過程中可能出現的錯誤。清晰的時間線和api動作的層次體系，就能立刻判別出 NoMethodError這個錯誤源於controller中。如果不能可視化的看到技術棧中請求的過程，就不會很容易的定位用戶體驗的根因。前端監控long task有助於判斷影響用戶體驗的卡頓和腳本優化。long task是指影響UI主線程超過50ms的js代碼。可以在瀏覽器控制臺看到。錯誤追蹤SPA應用在用戶設備上要運行更多更復雜的代碼，如果不在代碼插樁是無法發現瀏覽器錯誤的。如果不埋點，當發現需求支持的訂單或者業務單量下降時，就隻能亡羊補牢。捕獲和記錄應用錯誤有助於防患於未然。比如，如果電商網站下單按鈕無法連接後端api，就會產生瀏覽器錯誤。如果用戶點擊下單但無反應，用戶可能不會很開心，也可能去其他網站。如果不追蹤用戶瀏覽器錯誤，那就隻能發現從購物車到下單下降的結果。也可以通過全局事件，比如window.onError，來捕獲和記錄錯誤事件。在記錄錯誤時，應該盡可能多地收集瀏覽器信息、os、應用版本等。這些數據屬於應用采集常見的數據，這些信息為錯誤的影響和後續的調試提供更多的上下文信息。為瞭高效地追蹤錯誤，需要降噪。比如第三方包、瀏覽器擴展程序，以及依賴等可能報錯，雖然這些錯誤實際與網站性能無關，但是過濾這些數據尋找有效信息太難瞭。使用第三方監控方案聚合相似的錯誤日志有助於分析，幫助定位關鍵問題。下面我們列出錯誤追蹤的截圖，圖中能清楚地瞭解錯誤情況，同時sourcemap功能能定位到代碼行數。追蹤錯誤追蹤應用在真實設備上的錯誤能讓測試和開發二次調試的成本降低，因為能及時發現和收集錯誤的上下文環境中的詳細信息提高調試效率，從而避免更大的影響到用戶交互，比如添加商品到購物車或者下單支付。有的第三方包，比如觀測雲 – 觀測雲讓用戶實時追蹤瀏覽器的錯誤日志，尤其是發生錯誤時的上下文場景。觀測SPA應用隨著前端框架和SPA應用復雜度演進，用戶設備上出現大量渲染行為，性能監測的難度也越來越高。所以才建議把前端監控視為監控用戶軌跡：通過記錄用戶交互和資源的加載，以及依賴瀏覽器的錯誤，構建可視化和收集能優化單頁應用的有效視角。如觀測雲一樣的監控方案能幫助用戶清晰看到包括前端應用等技術棧的性能。Web 監測 – 觀測雲能自動追蹤用戶行為的latency，收集關鍵的元數據，比如瀏覽器、os、設備和地理信息。同時，使用觀測雲APM，能夠通過請求把前後端串聯監控網站的性能。現在就使用觀測雲開始觀測SPA應用。如果還沒有註冊，可以免費註冊和試用。試用歡迎試用試用鏈接： – 觀測雲 – 觀測雲