性能優化第一步：性能瓶頸分析

將精力放到關鍵性的指標之上
一般咱們講的性能優化就是縮短用戶可見區域的內容的加載時間，通常來講就是咱們的首屏。由於它和用戶體驗息息相關，而不是隻關注於整個頁面的加載時間（例如 onLoad 和 DOMContentLoaded 時間）。固然若是你網站確實很龐大，你也能夠將精力放到減小白屏時間上，由於一個好的 loading 動畫能讓用戶在內心上縮短網站首屏時間。下面就給出這兩個指標的定義。

白屏時間：指從瀏覽器開始跳轉到第一次有內容渲染的時間（一般狀況下，這一段時間用戶的瀏覽器都是白色的，因此叫作白屏時間）。

首屏時間：指從瀏覽器開始跳轉到用戶可見區域的內容渲染完畢的時間。

Audits 使用

Audits 是 chrome 開發者工具中自帶的專門用於識別影響站點性能、可訪問性和用戶體驗的常見問題。

使用 chrome 瀏覽器隱身模式打開你要測量的頁面（避免插件的干擾），而後打開開發者工具，找到 Audits ，點擊它就進入了 Audits 頁面。

圖 1 ：Audits 設置界面

選項說明

Device: 選擇你要測量的網站是移動端仍是桌面端

mobile: 移動端
desktop: 桌面端
Audits: 選擇你要測量的內容

Performance: 網站性能
Progressive Web App: 漸進式支持
Best practices: 最佳實踐
Accessibility: 可訪問性
SEO： SEO 支持
Throttling: 設置網速和 CPU 速度

模擬 fast-3g 網速， 1/4 倍 CPU 速度
真實 fast-3g 網速，1/4 倍 CPU 速度
不節流
Clear storage: 清除緩存

Run audits: 開始測量

測試結果分析

如下測試結果環境

測試網頁地址：https://www.xiguacity.cn/fe-p...

測試選項：mobile, 真實 fast-3g 網速，1/4 倍 CPU 速度, Clear storage

點擊 Run audtis 後，稍等片刻後咱們就能夠獲得以下的測量結果頁面：

圖 2 ：Audits 結果頁面

結果頁指標說明

Metrics: 關鍵性指標

First Contentful Paint: 首次內容渲染時間（第一個文本或圖像繪製的時間）
First Meaningful Paint:頁面主要內容出如今屏幕上的時間點
Speed Index: 首屏時間
First CPU Idle : CPU 第一次空閒的時間
Time to Interactive: 第一次可交互的時間
Estimated Input Latency: 估計的輸入延遲 (估計您的應用程序在頁面加載最繁忙的 5s 窗口中響應用戶輸入所需的時間，以毫秒爲單位若是您的延遲超過50毫秒，用戶可能會認爲您的應用程序是卡頓的)
Opportunities: 能夠改進的地方

例舉出了你能夠作的優化來加快頁面加載速度，

Diagnostics: 診斷

有關應用程序性能的更多信息

好的，咱們如今已經對咱們網站的性能狀況有了一個初步的瞭解，白屏時間： First Contentful Paint 2.3s，首屏時間： Speed Index 7.1s。並且咱們在 Opportunities 也獲得了一些建議好比 Preload 關鍵請求，使用下一代圖片格式及有效的編碼圖像。可是隻有這些數據仍是咱們仍是一臉懵比，咱們如今已經知道咱們白屏和首屏很慢，可是關鍵問題出在哪裏？咱們怎麼去改進仍是不太清除。下面就會介紹怎麼用 Performance 對網站性能進行詳細分析。

Performance 使用

在圖 2 中 Time to Interactive 指標下面與有個按鈕 View Trace，點擊它就能夠進入到 Performance 看板，在這裏能夠對網站的詳細性能狀況進行分析。
Performance 能夠搭配 Audits 使用也能夠單獨使用

圖3: performance 測試結果頁面

也許你第一次進入這個頁面面對這麼多數據有點手足無措，可是咱們如今只用關心咱們最關心的數據——Network（圖中間的部分），它還原了咱們的頁面載入過程當中的網路請求時序圖。下面詳細解釋。

Network 詳解

座標軸

圖的橫軸表示時間，縱軸堆疊在一塊兒的請求代表他們是同一時間發起的。

請求方塊顏色

藍色：html
紫色：css
黃色：js
綠色：img
每個顏色又分爲淺色部分和深色部分，其中淺色部分表示從發送請求到第一個字節返回的時間（TTFB: Time To First Byte），深色的部分表示內容下載的時間。

**請求方塊左右的兩側的灰色實線
**
左側：請求發送前等待的時間
右側：請求發送後等待主線程處理的時間
好的咱們如今對 Network 看板有了一個大體的瞭解，下面就結合 Network 來對性能瓶頸進行詳細分析。

結合 Network 對性能進行分析

咱們按照請求發起的時間將請求大體劃分爲 7 步，從下圖能夠看出走完前 6 步後纔開始請求內容圖片，對應到項目裏面就是 react 第一次渲染出頁面內容，而這個時間都已經到了第 5s。

圖4: network 請求時序圖

因此根據上圖咱們至少找到兩處瓶頸

串聯請求太多，從第一步到第六步
圖片太大，請求時間太長
找到了瓶頸咱們就有了方向來優化它，咱們決定先解決第一個瓶頸串聯請求太多的問題，爲了解決它咱們須要弄清除這六步到底在作什麼。

其中第 3 步你們可能不太清楚這裏是由於項目採用了單頁面入口模式，而後用了 react-router 去作前端路由加以前端路由的頁面又作了懶加載，因此第三步就是前端路由命中咱們想要的頁面後去拉取這個頁面所需的資源（js，css）。第 4， 5， 6 你們均可以簡單理解爲去請求服務器 API 而後等待服務器數據返回。因此根據上面的分析，咱們初步就能夠得出如下幾項優化措施

去掉路由懶加載，項目改爲多頁面模式，直接幹掉第 3 步。
在服務端去調用 5 和 6 步 API 直接生成靜態頁面，幹掉第 5 和 6 步。
使用下一代圖片格式（webp）優化圖片大小，縮短第7步。
使用圖片懶加載，優先加載首屏圖片。
優化後的 Network 時序圖

圖5: 優化後的 network 請求時序圖

能夠看見咱們將步數壓縮到了4步

html 請求
html 中連接的資源，可是與以前的不一樣的是，作了靜態化模版後首屏的圖片也會在這裏發起請求
主要是進行微信受權
微信受權後再加載須要身份認證的組件
特別說明一下，這個頁面受限與微信受權的影響，仍是要分 4 步，理想狀況下，咱們能夠是能夠壓縮到 2 步。這樣在 fast-3g 網速下首屏時間就能進 2s 了。

結語

自此，對網站性能瓶頸的分析就結束了，詳細的手段將在下一節進行介紹。本文只是用一個例子來介紹瞭如何對網頁性能瓶頸進行分析。更重要的是但願你們掌握對性能分析工具 Audits 和 Performance 的使用，在平常工做中觸類旁通，養成注重網頁性能的良好習慣。