小白也能看的懂的頁面性能優化來一波

前言

當你以爲頁面很卡的時候，你有可能須要更換手機，固然也可讓對應的同窗進行性能優化了。本文適用給技術小白 & 部分前端同窗。

固然了，筆者在寫文本以前也針對了部門內部和公司內部的部分H5頁面的性能進行粗略的評估，結果固然是很是不使人滿意的。或許咱們忙於業務，可是有時候咱們仍是要停下來評估性能，不能把性能優化一直說在嘴上。

開始正經文章

前面也說了，頁面很卡，那到底很卡是怎麼一個概念的，或者是說這麼去衡量一個頁面很卡，大概總結了下，能夠分爲如下幾點：

1. 頁面加載出現較長時間的白屏，術語：弱網環境下量化在不能超過4s
2. 頁面在加載過程當中出現了明顯的頁面抖動或屢次白屏，術語：頁面重排耗能厲害
3. 移動端頁面中動畫出現了明顯的卡頓，術語:FPS低於了40幀
4. 移動端頁面在行爲交互（按鈕點擊／頁面滾動）的時候出現明顯的卡頓，術語:FPS低於了40幀

當咱們瞭解如何經過直觀&客觀去簡單判斷一個頁面是否卡後，咱們能夠定性該頁面是否須要開發同窗去介入進行性能優化。那麼性能優化方式又有哪些呢？

1. 頁面自己及其靜態資源大小減小 & 數量減小
2. 頁面交互方式優化，eg：初始化禁止輪播，圖片lazyload等
3. 頁面視覺優化
4. 頁面代碼自己優化
5. 其餘：太繁瑣，省略1W字

可是說到具體的性能優化方案的話咱們應該怎麼選擇，咱們所產出的網站在編碼方式／打包方式等等諸多方面有較大的不一樣，這也給咱們性能優化增長很大難度。也說明了真正作好性能優化很難，就看你的預期和實際的gap。

既然說到了預期和實際的差距，咱們來講說下如何快速縮小這個差距吧，而不是徹底解決。特整理了如下大概的處理方法

1. 砍加載時間最長的線

綠色區域表示TTFB／藍色表示LOAD／灰色表示wait或Stalled

1. 縮小TTFB
2. 減小wait時間 -> 每次只能同時發起5個http請求，咱們須要考慮咱們的打包方式，該規整
3. 縮小部分大文件 -> base文件是否有冗餘代碼，是否能夠拆解到其餘文件，均勻分佈
4. 合理應用gzip -> flexlbie.js gzip後文件反而大了，得不償失

綜上所屬，咱們必須控制打包方式，儘可能減小冗餘代碼的加載，以及均勻分配js文件的大小，避免出現較小的js／css文件。固然了http數量方面仍是須要減小，在大小和數量取時間最小值吧。最後也要說明一點的事情，部分時候咱們會依賴於第三方服務，可能須要第三方的配合來優化。

1. lazyload添加和適當的交互干涉

右下角有個比較明顯的1/5，即表示爲輪播

• 原有邏輯：當頁面渲染過程當中會批量加載全部圖片，且當js加載完畢後即執行輪播，可能會出現圖片尚未顯示徹底即下一張
• 優化後的邏輯：當頁面渲染完成前禁止加載未顯示的圖片，當頁面未渲染完畢&圖片未加載完畢前不進行任何輪播操做

如上的處理方式一方面優化首屏的加載大小，也保證頁面過程不會由於動畫執行致使頁面總體渲染卡頓

1. 視覺干預

白屏時間不管如何都沒法避免，這個時候咱們須要部分的視覺欺騙。具體方式如上圖，在加載過程當中給頁面默認背景色，在頁面開始加載時即會出現load圖，這種狀況下面會適當的給頁面續命，預計可讓用戶多等幾秒

若是你處理好前面三點後，再刪除一些console等冗餘代碼後，恭喜你，你基本上已經完成頁面80%及其以上的性能提高，並且在投入產出比上面很是高，估計1-2天絕對夠了，並且仍是很是值得投入的。

說在最後

其實性能優化真的一個佛系的操做，前面的優化很是的容易，後面10-20%優化就沒有底了，這種仍是須要有同窗有必定的前端功底，深知須要對頁面進行徹底顛覆重構。可是前面的優化確實能夠考慮。

ps：早睡早起，常作運動，多與異性交朋友～