聲明與保證

本文寫作于2023年6月，性能優化的評價標準和優化方式僅適用于當前觀測云控制臺，當然隨著產品迭代及技術更新，本文也會應要求適當更新。

創建、修訂時間	創建修改人	版本
2023/6/24	觀測云***	v1.0.0

1.網站性能評價的發展史（近20年）

講到網站性能優化，離不開網站技術發展史，更離不開網站性能的評價標準的發展。優化既離不開不斷演進發展的技術，也離不開前人對技術優化的方法論和具體實踐。近20年來，網站性能評價的標準有三次比較值得關注的關鍵節點，這三次關鍵節點分別能看出性能優化的視角與方法。

性能優化技術和評價標準的發展歷史圖

1.1 Yahoo軍規打下夯實的基礎：有定性無定量的坑

最初，在只有純文本閱讀的時代，幾乎或者很少會像現在一樣考慮性能（產品）上的優化。隨著互聯網時代的到來以及信息化發展，圖片、音視頻等多媒體時代降臨，開始有了在網站性能優化的第一次啟蒙。雅虎作為第一梯隊，率先推出了網站優化的軍規，很快被廣大開發者所接受，這些軍規即使現在看，依舊有很大的借鑒和指導意義。其中基本包含了以下內容，因篇幅有限，故未完全展開講述：

1. 減少http請求

2. 使用內容發布網絡

3. 添加Expires頭

4. 壓縮組件

5. 將樣式表放在頂部

6. 將腳本放在底部

7. 避免css表達式

8. 使用外部javascript和css

9. 減少DNS查找

10. 精簡Javascript

11. 避免重定向

12. 刪除重復腳本

13. 配置ETag

14. 使用Ajax可緩存

內容來源：《高性能網站建設指南》

注：此處不建議完全照搬雅虎軍規進行以上設置，尤其是在沒有構建全面的網站指標體系和性能模型前，單獨照搬不僅可能抓不住痛點甚至還有可能有反作用；

1.2.RAIL性能模型首次提出：以用戶體驗為中心的可量化標準

搜索引擎時代谷歌對于網站評價標準的影響非常大，在谷歌的不斷探索中，首先提出了以用戶為中心的性能模型，因為谷歌的巨大影響力，這個評價模型也開始在開發人員中傳播開來，性能評價的視角也逐漸轉向了用戶體驗，非常可喜的是對于這四項用戶體驗的維度，每個維度都有量化的指標。

RAIL模型圖

來源：web.dev/rail

如下介紹一下用戶如何感知性能延遲的關鍵指標：

數據來源：web.dev/rail

總結一下，該模型非常強調對于性能的延遲，特別強調：

• 響應 ：100ms內響應

• 動作：50毫秒內處理事件

• 動畫：10毫秒內生成一幀

• 加載：在5s內交付內容并交互

1.3. 網站核心指標幾乎統一了性能的評價標準：從三個維度可量化

然而直到2020年的十年左右的時間，RAIL并沒有像搜索引擎一樣被大眾完全使用，在這期間谷歌陸續推出了開源框架lighthouse，并在chrome devtools中開始使用web vitals。谷歌也有很多開發開始了在web vitals的布道。web vitals很快被廣大開發者所接受，并快速被APM廠商作為衡量網站性能的方法。

web vitals是一種思想，該思想吸收囊括了性能發展過程中的幾個關鍵指標，分別從加載速度、交互情況、視覺穩定性這三個方面入手，每部分包括1個或者多個指標。web vitals也在不斷調整其指標內容，目前廣為接受的分別是LCP、FID和CLS。

網站核心指標圖

數據來源：web.dev/defining-co…

• LCP :最大內容繪制 (LCP) 是測量感知加載速度的一個以用戶為中心的重要指標，因為該項指標會在頁面的主要內容基本加載完成時，在頁面加載時間軸中標記出相應的點，迅捷的 LCP 有助于讓用戶確信頁面是有效的。

• FID:首次輸入延遲 (FID) 是測量加載響應度的一個以用戶為中心的重要指標，因為該項指標將用戶嘗試與無響應頁面進行交互時的體驗進行了量化，低 FID 有助于讓用戶確信頁面是有效的。

• CLS:累積布局偏移 (CLS) 是測量視覺穩定性的一個以用戶為中心的重要指標，因為該項指標有助于量化用戶經歷意外布局偏移的頻率，較低的 CLS 有助于確保一個頁面是令人愉悅的。

需注意：web vitals標準也在不斷變化中，目前一個比較新穎的指標就包括即將替代FID的INP，這不是本篇最佳實踐的重點，但必須要認識到，web vitals是目前接受度最為廣泛的標準，也是觀測云的網站性能體系中的重要組成部分。

2.觀測云用戶體驗方案

言歸正傳，網站核心指標給出了比較規范易接受的性能評價體系。在觀測云的用戶體驗的最佳實踐中，首先推薦用戶的，便是使用觀測云用戶體驗監測功能。

隨著產品支持的用戶和平臺越來越多，雖然基礎設施和服務都健康運行，但沒有客戶端的可觀測性，也只是偽全面，因為很有可能報錯出現在客戶端，或者用戶體驗差已經流失了。

觀測云的用戶體驗監測（rum）既包含了RAIL的精華，也囊括了網站核心指標。作為基于瀏覽器的性能指標收集性能和用戶體驗的方式（這部分會在后續實踐的文章詳細介紹），遠比實驗室或者開發者本地性能測試有好處，正是因為基于真實的物理設備和網絡情況，以及真實的用戶行為，所提供的指標和數據也更有意義和價值，比如可以

• 通過洞察用戶行為改善業務
• 通過查看會話重放提高轉化率
• 使用漏斗圖了解用戶旅程，或者
• 根據會話生成指標

今天作為入門篇，我將簡單介紹一下基礎功能

2.1 用戶訪問監測介紹

觀測云用戶體驗方案推薦用戶接入用戶訪問監測，收集真實的用戶行為數據和性能數據，分析用戶行為和性能數據，做出對研發和業務做出最佳的決策。

需注意：不同網站有不同的性能需求，觀測云推薦用戶根據業務場景收集訪問和性能數據，不代表推薦用戶收集100%的用戶訪問數據，用戶需根據實際情況選用接入方式和接入情況，觀測云允許用戶對用戶數據進行采樣。

2.1.1 有關觀測云 SDK 的接入和數據的分析

網站接入觀測云SDK后，用戶的訪問數據（包含用戶旅程）和性能數據就有了進一步分析的可能。在登錄觀測云后不僅可以看到這部分的數據，包括有會話、頁面、動作、錯誤、卡頓這幾個維度，更重要的是可以以此創建基于業務的數據分析，以下將先介紹基礎的面板以滿足日常訪問和性能數據的查看。

a.數據查看

在性能方面，首先觀測云推薦用戶關注性能儀表盤中的網站核心指標，為方便用戶查看，在觀測云用戶監測中有專門的性能看板，不僅能夠滿足對網站核心指標的查看，還包含了卡頓、xhr、資源等分析情況。

觀測云用戶訪問數據的分析看板

其次，由于卡頓和報錯越來越成為制約性能和用戶體驗的兩大因素，觀測云推薦從會話和頁面的維度，關注以下4個和性能關鍵的指標：

• session_long_task_count，會話卡頓次數
• session_error_count，會話錯誤次數
• view_long_task_count，頁面卡頓次數
• view_error_count，頁面錯誤次數

注意：頁面級別的網站核心指標依然非常重要，核心指標對于good/needs improvement和poor的評價標準是一般指標，e.g. 讓用戶等2.5s（LCP 在2.5s內）才看到頁面這顯然又太寬泛，在沒有更適用的定量標準前，以產品使用場景設定一個benchmark非常有意義。

b.數據分析前的小知識點補充

性能數據分析

說到性能瓶頸分析，多基于瀏覽器的性能指標，這個過程通常劃分為以下十幾個階段：

Navigation Api 時間圖

數據來源：developer.mozila

看上圖的內容，具體指標的計算邏輯如下表所示，若感到枯燥，可以直接調到表格后的下一個部分看精簡內容，不過如果想成為網站性能專家，這部分算是基礎入門內容。

字段	類型	描述
first_contentful_paint	number（ns）	首次內容繪制時間 (FCP)計算方式：firstPaintContentEnd - firstPaintContentStart
largest_contentful_paint	number（ns）	最大內容繪制（頁面加載時間軸中的一剎那，其中呈現了視口中最大的 DOM 對象）參考鏈接：LCP計算方式：統計最近上報的一次 PerformanceEntry 時間
cumulative_layout_shift	number	累計布局版面轉移 (CLS)，0 表示載入過程沒有版面移動變化
first_input_delay	number（ns）	首次輸入延時 (FID)計算方式：performance.now() - event.timeStamp
loading_time	number（ns）	頁面加載時間initial_load 模式下計算公式:① loadEventEnd - navigationStart② 頁面首次無活動時間 - navigationStartroute_change 模式下計算公式：用戶點擊時間 - 頁面首次無活動時間頁面首次無活動時間：頁面超過 100ms 無網絡請求或 DOM 突變
dom_interactive	number（ns）	DOM 結構構建完畢時間獲取方式：time = performanceTiming.domInteractive;參考鏈接：MDN dom_interactive
dom_content_loaded	number（ns）	DOM 內容加載時間計算方式：domContentLoadedEventEnd - domContentLoadedEventStart
dom_complete	number（ns）	DOM 樹解析完成時間獲取方式：time = performanceTiming.domComplete;參考鏈接：MDN dom_complete
load_event	number（ns）	事件加載時間計算方式：loadEventEnd - loadEventStart
first_meaningful_paint	number（ns）	首屏時間計算方式：firstPaintContentEnd - firstPaintContentStart
first_paint_time	number（ns）	首次渲染時間計算方式：responseEnd - fetchStart
resource_load_time	number（ns）	資源加載時間計算方式：loadEventStart - domContentLoadedEventEnd
time_to_interactive	number（ns）	首次可交互時間計算方式：domInteratice - requestStart
dom	number（ns）	DOM 解析耗時計算方式：domComplete - domInteractive
dom_ready	number（ns）	DOM Ready時間計算方式：domContentLoadedEventEnd - navigationStart
time_spent	number（ns）	頁面停留時間

resource_size	number	資源大小，默認單位：byte
resource_dns	number（ns）	資源加載 DNS 解析時間計算方式：domainLookupEnd - domainLookupStart
resource_tcp	number（ns）	資源加載 TCP 連接時間計算方式：connectEnd - connectStart
resource_ssl	number（ns）	資源加載 SSL 連接時間計算方式：connectEnd - secureConnectStart
resource_ttfb	number（ns）	資源加載請求響應時間計算方式：responseStart - requestStart
resource_trans	number（ns）	資源加載內容傳輸時間計算方式：responseEnd - responseStart
resource_first_byte	number（ns）	資源加載首包時間計算方式：responseStart - domainLookupStart
duration	number（ns）	資源加載時間計算方式：duration(responseEnd-startTime)

是不是看著眼睛都暈了？其實單純只看一下這部分其實也可以：

2.2 有關網站核心指標的數據分析初步展示與標準

在之前有關網站核心指標的敘述中，已經能夠看到對于幾個指標的benchmark。

需注意：網站核心指標最早針對MPA架構，現在也支持SPA架構的網站，但必須注意到，SPA目前沒有統一的標準和路由規范，谷歌也在不斷提高對SPA的適配，觀測云也不斷更新和補充用戶體驗的指標和相關功能，不斷滿足用戶需求。

觀測云內置的時序數據儀表盤，能夠清晰地觀測到真實的網站核心指標的數據情況，對于異常的性能數據指標，方便下鉆進行分析。

3.優化實踐參考

觀測云性能指標列表

這部分內容更多的是賦能、啟迪與實踐，所以不再列出具體的指標列表，詳情參考以下鏈接。

《web應用數據采集》

這里我特意列出在會話級別的幾個指標，這些可能是數據分析、網站性能、 用戶行為分析、用戶增長與運營需要格外關注的：

session_referrer	string	會話來源。一般是記錄來源的頁面地址。
session_first_view_url	string	當前會話的第一個頁面的 URL
session_last_view_url	string	當前會話的最后一個頁面的 URL
session_error_count	number	當前會話產生錯誤個數
session_action_count	number	當前會話用戶操作次數
session_long_task_count	number	當前會話產生長任務次數

3.1 需要關注的指標

控制性和可觀測性需要專家構建評價系統給出關鍵指標及其相關性指標構建模型，給出大一統的數據模型可能很難，但落地到具體產品場景可能會有一些方法，這需要有一定經驗的人對已有指標進行數據分析，在這點上觀測云又給用戶設置了特定的入口，供小白、中高級開發、專家乃至是產品同學進行場景建設。網站性能可以構建的模型可以從以下幾方面來搭建場景：

-網站加載性能的現場指標收集，包括前面描述的各種指標

-網站加載性能的可視化和評價標準體系，這部分可以參考觀測云默認的性能模板

-網站加載性能的相關性分析，這部分正好是一系列文章的第一篇。

下面我們便以觀測云為例進行探索：

3.2 性能探索與實踐

a.觀測云控制臺

第一個分析的例子，觀測云推薦用戶使用場景儀表板中的散點圖工具，來探查性能和不同指標之間的關系散點圖能直觀看出x和y的相關性，這里可以把y為加載時間，根據經驗推薦用戶分別以頁面為維度，將X軸可以設置為資源加載數量。

資源加載數量和頁面加載時間的數據可視化圖

圖注：其中X軸代表頁面資源加載的數量；Y軸代表頁面加載時間（單位：s）

肉眼就能看出x在0-30間存在比較明顯的正相關，導出該數據分析，發現數值遠小于0.05，也就是從統計分析上也能看出較強的相關性。

我們打開控制臺的network選項，進行查看，發現在該頁面有169個請求：

這么多資源看起來很不方便，我們使用觀測云的場景儀表板繼續探索，使用餅圖對當前的資源類型進行分類，發現js、css、image三者的數量合占比60%。

對這些靜態資源我們可以做一個耗時比的統計，一般我們可以取avg、min、max、p99、p90，這里我們采用max的duration來看，主要是想知道哪種類型耗時時間最長。

上圖可以看出，image類型耗時非常長，到底都是哪些內容呢，我們對image的類型繼續做探索：

我們加載耗時最長的圖片進行排序，看下圖發現大多是icon類型:

因為上面講到的樣式資源加載的數量，所以按照請求加載的數量進行排行：

能夠看到chart-loading等icon文件加載次數占比最多，但大小基本都在5kb以下，我們看到這些圖片的文件名都是非增量更新的，也就是不會經常變動的靜態資源，我們把這幾個文件打開查看一下分別是：

看到這里，優化的角度也就非常清晰了，這100多個icon需要設計整理到一個文件就可以了。

我們看到loading這個文件加載的次數比任何都要多，這個文件是做什么的？我們還可以進一步對這個loading的文件進行探究，可以以頁面功能或者viewid來進一步探索，這里以矩形樹圖為例：

看著是以login加載次數最多，其他幾乎所有頁面都有加載，看來這個文件還是挺重要的，我們看看這個文件的緩存情況，我們來按照resource_status來進行查看：

我們發現95%左右的狀態碼是200，我們看一下它的傳輸時間來判斷是否使用了本地緩存，在這個時候可以使用resource_trans這個來判斷：

這里從上圖也基本能推測該資源比較好的使用了緩存，大概在幾天左右，max基本可以理解成緩存失效后消耗的時間（>100ms），min可以理解成加載本地緩存的時間（幾乎為0ms），所以這塊可以如果適當做調整的話，可能得一個方向便是要從文件的大小入手，同理我們把其他類似的圖片傳輸耗時進行分析：

看avg都不大，但max較大，說明文件大小還是需要調整（也可能是文件格式），我們按照max進行排序：

看到這些文件不僅max時間長，avg也很長，要減少大小，可能還要考慮調整格式等手段了。

這里我再深入一點舉個例子以login_left_bg這個圖片為例子，其resource_status的餅形圖如下所示：

上圖所示，說明該文件幾乎都要經常去服務器查看文件是否有最新，這塊就需要考慮這個文件是否是需要將緩存時間設置長一些了。

綜上，使用了resource的很多指標字段進行了基本的數據分析，發現基本可以利用場景儀表板把揭示非常多的內容，不論是從loading_time和其他指標相關性的探索，還是對該指標的優化，我們都能看出當前網站的指標體系是非常復雜的，影響因素眾多，需要深入探索，這塊也是觀測云不斷投入力量研發的。

b.觀測云官網

同理對官網進行相關性分析，看到view_resource_count則沒有顯著性，但js_size、css_size的相關性較高.

我們打開官網進行查看，發現js和css較大存在blank_line和white_space，webpack有對應的compress插件可以去掉white_space和blank_line，這部分比較簡單就不展開了。

現在使用觀測云對resource進行分析，首先先以resource_status篩選resource_trans的情況，

上圖得知，304的資源平均傳輸時間比200的傳輸時間要長很多，也就是去服務器查看沒有更新的文件，發現沒有更新的內容，依舊使用了緩存內容，這里也能明顯看出使用了合理設置緩存時間的好處，但這里有點問題，下面以時序圖來推測緩存時間：

這時候 我們還可以直接將200、304時序圖拉出來，這里選擇加入resouce_type做篩選一并做可視化：

上圖看出css的耗時max和avg明顯大于js的耗時，我們看看css這部分的內容：

我們打開其中的文件進行查看：

這部分是第三方庫，可以摘出來放CDN可能效果會好很多。

下面針對js進行查看

限于篇幅，此處就不再做具體分析，相信小伙伴已經能夠看出性能調優的基本思路和方法。這里最后補充一張資源加載首包時間和頁面架子時間的可視化圖，感興趣的小伙伴可以繼續探索。

資源加載首包時間和頁面加載時間的數據可視化圖

圖注：其中X軸代表資源加載首包時間；Y軸代表頁面加載時間（單位：s）

注意：觀測云推薦用戶根據使用場景來洞察性能，需要明確的是，除了資源加載數量、資源加載首包時間，還有很多影響網站性能的因素，如TCP、DNS等網絡情況。

總結

綜上所述，隨著技術與評價標準的發展，觀測云既能給用戶提供完整的指標體系，提供了指標洞察的方法，讓網站系統的性能能夠被觀測和提升，限于篇幅內容，有關網站加載性能提升的第一篇內容到這里就先結束了，之后會對網站核心指標中有關加載性能的LCP以及提升的四大方法做分享。

后續補充：

1. 儀表板配置json

2. python或者r的代碼 隨附：

本文使用觀測云-中國區 1（杭州）站點，商業版賬號。

直接開通商業版可獲得?500?元無限制代金券，實現本文觀測場景每天消費僅需幾分錢，可以用幾十年了。

docs.guance.com/billing/tra…

或可以選擇開通體驗版，每天有2000的免費額度，，可參考：

docs.guance.com/billing/tra…

完成觀測云賬號注冊后，會登錄到觀測云工作空間控制臺，之后的數據可視化都會在這里展現。

作者：卡曼在觀測
鏈接：https://juejin.cn/post/7267797785088573480
來源：稀土掘金
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。