H5頁面性能分析神器——lighthouse

前言

在寫這篇文章的時候，以前有看過一大堆性能優化的文章，對的，每次看到別人寫的好的博客最終的歸宿不是腦子🧠，而是收藏夾📖，也就致使於當我真正遇到性能問題的時候一籌莫展，我也真是理解了那句話紙上得來終覺淺，絕知此事要躬行。今天在跟測的時候，測試大哥就一直在吐槽，爲何你這新頁面白屏這麼的久，圖片這裏渲染的這麼的慢，爲何感受這動畫一卡一卡的......真的那一刻我快被問成了十萬個爲何了，這時我打開了塵封已久的收藏夾閱讀了起來......

走進Lighthouse

根據個人收藏夾中的文章顯示，個人谷歌瀏覽器就能進行H5頁面性能的分析，我可真是太開心了，我就喜歡這種0配置0代碼的傻瓜教程。

版本高的Google瀏覽器自帶了lighthouse，無需進行其餘的操做

Categoies（分類）裏面包括了Performance（性能）,PWA,Best practices(最佳實踐),Accessibility(可訪問性),SEO(搜索引擎優化)。

Device(設備)也能夠選擇是Mobile(手機),Desktop(桌面端設備)。

既然咱們是H5頁面，那選擇好Mobile,分類咱們沒有使用PWA技術，那麼咱們除了PWA以外所有勾選,最後點擊Generate report生成最終的報告。

性能指標分析

這即是咱們網頁最終的報告，下圖是各項指標的分數，下面根據更具體一些時間指標來衡量咱們的性能。

真的是隻能淡淡說一句時代變了，原來衡量性能好壞有如下6個方面，我記得以前衡量一個頁面的性能當初張口閉口就是白屏多少秒😂

FCP

FCP(Fisrt Contentful Paint)：這個指標用於記錄頁面首次繪製文本、圖片、非空白 Canvas 或 SVG 的時間。

舉個例子說說，就是頁面從白屏到出現出現一張圖片或者一段文字的時間，固然其實不少時候頁面要去請求接口拉取數據，若是網絡比較慢的話確定會白屏比較久，那麼咱們的其實能夠在數據沒加載前放一個loading的圖片,告訴用戶頁面在加載中,從而減小咱們的FCP的時間。

TTI

TTI(Time to Interactive)：這個表示首次可交互可流暢的交互時間，這個時間有幾個特色：位於FCP以後,而且5秒內無長任務(大於50ms)的執行。

其實這個指標和FCP同樣都很重要，FCP可能意味着咱們的頁面開始渲染，即便渲染出頁面不表明能夠交互了，不少的時候咱們的頁面渲染出來了，可是會比較的卡頓。

Speed Index

速度指數衡量的是內容在頁面加載過程當中的視覺顯示速度。Lighthouse首先會在瀏覽器中捕獲一段頁面加載的視頻，並計算出各幀之間的視覺進度。

TBT

TBT(Total Blocking Time)：表示從FCP到TTI階段中長任務總阻塞時間。

如下爲web.dev官網對TBT所書寫的例子：

上圖表示主線程所作的任務時間線，其中任務分爲長任務和短任務（長短任務的依據爲執行時間是否大於50ms）。

那麼超過50ms的地方實際上就是阻塞時間，那上面實際上阻塞時間就是345ms。固然阻塞致使瀏覽器沒法中斷正在進行的任務，從而使得用戶沒法當即進行交互，從而影響體驗。

LCP

LCP(Largest Contentful Paint):表示頁面最大的內容繪製。該時間會隨着頁面渲染變化而變化，由於頁面中的最大元素在渲染過程當中可能會發生改變，另外該指標會在用戶第一次交互後中止記錄。

CLS

CLS(Cumulative Layout Shift)：表示頁面累計位移偏移。頁面內容的意外移動一般是因爲異步加載資源或將DOM元素動態添加到現有內容上方的頁面而發生的。

若是用戶在使用頁面的過程當中點擊一個按鈕，而後頁面生成一塊內容，致使該內容下面的全部內容下移，這即是一次頁面的位移。

lighthouse的修改建議

lighthouse的優勢不只僅能夠根據這些重要的指標給咱們的頁面打分，更重要的是lighthouse會給咱們不少的優化建議，這就至關於老師既會給學生打分又會講解錯題，真是很爽，否則的話還得去網上一個一個本身找解決方法，並且不少時候本身尚未解決的方向。

• 下面是lighthouse給咱們的一些建議

• 下面是有關咱們的項目對性能的診斷結果

後續的話進行項目性能優化的詳細實踐。