前端性能優化的那些事

前端架構與性能優化那些事

性能優化的學徒工

• html數量控制 html css hint 善用css
  • 壓縮、合併、文件MD5戳更好的緩存
  • (引用多個cdn http1.1有用) 設置爲gzip cookie
  • http2
  • 離線緩存 localstorage
    • a.js -> a.xxx5.js
    • active.js 激活a.js 1.eval 2. add塞進
    • 去localstorage 中取得的時候 須要判斷版本號 是否一致

    1. 維護一個全局版本 一般webpack直接生成 obj = { a.js :'a.xx5.js' }
        2. 創建一個active.js 去激活js
        3. 例如請求 a.js
        4. active("a.js")
        5. localStorage["a.js"] -> script src="a.js"  沒有存過  ajax =>datatype:'text'
                                   script src="a.js" localStorage["a.js"] = "a.xx5.js"
                                                       -> localStorage["a.xx5.js"] = "js內容" 
                                -> script src="a.js"== obj["a.js"] 有存過
                                -> eval(localStorage["a.xx5.js"])
                                -> 請求並從新緩存
        6. 總共5M  超過 2.5M出現卡頓
    複製代碼

    • 廣告位置 經過web SQL存儲
    • localForage basket.js 緩存兼容
  • 緩存的優先級 cache-control expires etag last-modified

    last-modified / if-modified-since
        這是一一組請求/相應頭
        -> 響應頭:
            last-modified: Wed, 16 May 2018 02:57:16 GMT
        -> 請求頭:
            if-modified-since: Wed, 16 May 2018 05:55:38 GMT
        服務器器端返回資源時,若是頭部帶上了了 last-modified, 那麼
        資源下次請求時就會把值加入入到請求頭 if-modified-since 中，
        服務器能夠對比這個值，肯定資源是否發生變化，若是沒有發生變化，則返回304        
    
    etag / if-none-match 
        這也是一一組請求/相應頭 
        -> 響應頭:
            etag: "D5FC8B85A045FF720547BC36FC872550"
        -> 請求頭:
            if-none-match:"D5FC8B85A045FF720547BC36FC872550"
        原理理相似,服務器器端返回資源時,若是頭部帶上了了 etag,
        那麼資源下次請求時就會把值加入入到請求頭 if-none-match 中,
        服務器器能夠對比這個值,肯定資源是否發生變化,若是沒有發生變化,則返回 304
    expires
        -> expires: Thu, 16 May 2019 03:05:59 GMT
        在 http 頭中設置一個過時時間,在這個過時時間以前,瀏覽器的請求都不會發出，
        而是自動從緩存中讀取文件，除非緩存被清空，或者強制刷新。缺陷在於，服務器時間和
        用戶端時間可能存在不一致，因此HTTP1.1加入了cache-control頭來改進這個問題
    cache-control
        設置過時的時間長度（秒）,在這個時間範圍內，瀏覽器請求都會直接讀取緩存。當expires和
        cache-control都存在時，cache-control的優先級更高
    複製代碼

• http2 多路複用

  瀏覽器器請求//xx.cn/a.js
      -->解析域名
      —>HTTP鏈接
      —>服務器器處理文件
      —>返回數據
      ->瀏覽器器解析、渲染文文件。
      Keep-Alive解決的核心心問題就在此,必定時間內,同一域名屢次請求數據,
      只創建一次HTTP請求,其餘請可複用每一次創建的鏈接通道,以達到提升請求效率的問題。
      必定時間是能夠配置的,HTTP1.1仍是存在效率問題
          第一個:串串行行行的文文件傳輸。
          第二個:鏈接數過多。HTTP/2對同一域名下全部請求都是基於流,也就是說同一域名無論訪問多少文件,也只創建一路鏈接。
          一樣Apache的最大大鏈接數爲300,由於有了這個新特性,最大的併發就能夠提高到300,比原來提高了6倍!
  複製代碼

渲染中的性能優化

- Rendering 
  - Paint flashing 重繪
  - FPS meter 一秒繪製多少幀
- Performance
  - loading 加載時間
  - scripting 腳本執行時間
  - rendering 重排時間
  - painting  重繪時間
  - system  系統執行時間
  - idle    空閒時間
  - event log
複製代碼

重繪和重排 網頁總體渲染過程

1. 獲取dom 分割層
2. 根據每層節點結算樣式結果 Recalculate Style
3. 爲每一個節點生成圖形和位置 Layout
4. 將每一個節點繪製填充到當前幀的位圖中
5. 將圖層上傳到gpu(顯卡) gpu bimap 專門處理圖像
6. 顯卡根據符合要求的多個圖層合併生成圖像 Composite Layers

總結 渲染階段 ： Layout -> Paint -> Composite Layers

什麼狀況下會分層

根元素、position、transfrom、半透明、濾鏡、canvas、video、overflow

何時gpu直接參與？： css3d,video,webglk,transform,濾鏡 硬件加速

重排必定會引發重繪 重繪不必定引發重排

重排引發的狀況

1. 添加或者刪除元素
2. 元素位置的變化
3. 元素變化尺寸
4. 頁面的初始化
5. 讀取一些屬性會引發重排 offset、scrolltop、client、width
   • requestAnimationFrame ==> 下一幀

頁面加載的性能優化

• FP: 僅有一個div根節點
• FCP: 包含頁面的基本框架，但沒有數據
• FMP: 包括頁面全部元素以及數據
  • window.performance.getEntriesByType("paint")// 獲取重繪的時間
  • const observer new performanceObserver(); observer.observe({entryTypes:['paint']})
  • const observer new performanceObserver(); observer.observe({entryTypes:['longtask']})
  • requestAnimationFrame() //每一幀都要渲染
  • requestIdleCallback() //

nodeJS性能優化

未完待續......