性能優化--慕課網學習筆記(前5章)

2-2性能指標和優化目標

快唄，還能有啥。

2.2.1理解加載瀑布圖

• Queueing: 先要通過排隊，才能從瀏覽器發出去。
• DNS Loopup: 每一個資源有一個域名，域名最終要被翻譯成IP，而後找到這個服務器，因此還有一個DNS查找的過程
• initial connection： 找到資源之後呢，客戶端要和服務器創建鏈接，tcp協議創建連接的過程
• SSL ：有些網站使用https，還有一個安全性驗證的過程，SSL協商
• TTFB： 請求發出到請求回來的時間（重要）（後臺的數據處理能力，其次是回來的網絡情況）
• Content Download : 最後纔是資源的下載

藍色是dom加載結束的時間，紅色是頁面上全部的資源加載成功的時間

---

2.2.2基於HAR存儲於重建性能信息

保存加載完成的結果

---

2.2.3 速度指數

First Contentful Paint: 不是白屏的時間

Speed Index >4就是慢 <4就是快

---

2.2.4 重要測量指標

交互響應足夠快

畫面足夠流暢,畫面的幀數，1秒60幀

異步請求要足夠的快（儘可能在1秒內完成，完成不了加loading動畫）

Speed Index

TTFB

頁面加載時間

首次渲染

2.2.5 其餘

這個工具能夠監聽渲染的幀數

2-3 RAIL 測量模型【黃金指南】

2.3.1 什麼是RAIL

一流公司作標準，Google寫的標準

Response ： 響應，是咱們的網站給用戶的反饋，google給出的響應在50ms以內完成。
Animation：10ms 以內產生一幀動畫
Idle 空閒,儘量的增長空閒,儘可能讓後端去計算
Load 加載，在5s內完成加載並能夠進行交互

花裏胡哨，很高級的樣子。

2.3.2 性能測試工具：

Chrome DevTools 開發調試、性能評測
Lighthouse 網站總體質量評估
WebPageTest 多測試地點、全面性能報告 連接在此

waterfall chart 請求瀑布圖

first view 首次訪問

repeat view 二次訪問

2.3.3 本地安裝WebPageTest

先安裝docker。

同理，建立agent的鏡像

3-1瀏覽器渲染原理和關鍵渲染路徑

3.1.1瀏覽器的渲染原理

javascript（引發視覺的變化，js，css,動畫）->style(從新對視覺進行計算)->layout（佈局）->paint（繪製）->Composite（合成，相似ps）

寫的代碼是文本，計算機是不能理解的。須要轉換成計算機可以理解的數據結構。

以html的dom結構爲例，識別標記，轉換成鏈式結構。
構建DOM對象：HTML->DOM
而後掛載CSS
構建CSSOM對象：CSS-CSSOM

二者，結合，生成Render Tree。

3-2 迴流與重繪

佈局關心位置和大小

什麼是佈局抖動？

如何避免？

避免迴流

讀寫分離，

3-3使用Fast Dom防止佈局抖動的利器

連接在此

3-4 複合線程與圖層[深刻渲染流水線的最後一站]

複合線程（compositor thread）與圖層（layers）

複合線程作什麼

• 將頁面拆分圖層進行繪製再進行復合，就像ps
• 利用DevTools瞭解網頁的圖層拆分狀況
• 哪些樣式僅影響複合？transform opcity

錄製樣式。

3-5 避免重繪 [必學，加速頁面呈現]

利用DevTools識別paint的瓶頸

command + P打開工具，檢查重繪

Paint flashing閃瞎狗眼

利用will-change建立新的圖層

使用tansform,op減小repaint

隻影響複合而不去觸發佈局和繪製。

willChange 不可過多。

# 3-6 高頻事件防抖[解救頁面卡頓]
滾動
touch
poinermove
觸發的頻率高於刷新的頻率

window.requestAnimationFrame 官方連接在此

window.requestAnimationFrame() 告訴瀏覽器——你但願執行一個動畫，而且要求瀏覽器在下次重繪以前調用指定的回調函數更新動畫。該方法須要傳入一個回調函數做爲參數，該回調函數會在瀏覽器下一次重繪以前執行

包上一層函數就能去抖動，達到一幀只觸發一次的目的。

3-7 React時間調度實現[中高級前端須要瞭解的React調度原理]

4-1 Javascript 開銷和如何縮短解析時間

在字體，html，圖片這些資源當中，最爲昂貴的是JavaScript。它後面還有解析和編譯的過程。最後纔是執行.

一樣170kb的文件,js的文件解析須要大約2秒，jpg只須要解碼，大概0.06秒，繪製的總過程0.028s.

js處理的時間大概須要佔三分之一。就算用戶可以看到咱們的頁面，也沒辦法交互。

解決方案

Code splitting 代碼查分，按需加載。

當前訪問路徑須要哪些資源就加載哪些資源，不須要的咱們給它延遲，訪問的時候再去加載。達到減小加載js的目的

Tree shaking 代碼減重

舉例來講，咱們只是引用了loadsh裏面的一個函數，就能夠把這一個函數打包到bundle文件中。

減小主線程的工做量

避免長任務

任務時間越長，佔據的阻塞越久

避免超過1kb的行間腳本

寫行間腳本多是爲了加快首屏的渲染。剩下的再經過web文件進行加載。

對於行間腳本，瀏覽器不能進行優化。

使用rAF和rIC進行時間調度

具體看上一章。

4-2配合V8有效優化代碼

v8編譯原理

node用v8引擎

v8會對代碼進行優化，發現優化的不行了呢，還會反向優化，就會浪費不少時間。

抽象語法樹

源碼=》抽象語法樹=》字節碼Bytecode=》機器碼

編譯過程會進行優化

運行時可能會發生反優化

v8優化機制

腳本流

檢查超過30kb的腳本，就認爲問價已經足夠大，會單獨開一個線程進行解析。

字節碼緩存

常用的變量進行緩存

懶解析

主要針對於函數，先聲明可是不解析。

4-3 函數優化

懶解析的好處，若是不須要解析，那就不用在「堆」裏面分配內存，不用爲它建立一個語法樹。能夠提升咱們加載js的一個總體的效率。

可是現實中，咱們有時候仍是須要咱們的函數當即去執行的。

函數解析方式

lazy parseing 懶解析 vs eager parseing 飢餓解析

假如咱們先進行懶解析，而後發現須要當即執行，還須要一個eager parseing,這樣反而性能減半。

那麼，咱們怎樣告訴解析器，咱們須要進行eager parseing？

利用Optimize.js優化初次加載時間

連接在此

上面添加的括號會在壓縮的時候被去掉，可是Optimize會幫咱們把括號找回來。

可是如今webpack4已經本身可以實現這個功能。（老師講話真是喜歡大喘氣）。

4-4 對象優化

學習js對象，就像是練習內功。學習得好很差，就看你對對象學習的程度。

這些寫法的目的就是爲了迎合V8引擎對你的代碼進行優化。

以相同順序初始化對象成員，避免隱藏類的調整

實例化後避免添加新屬性

儘可能使用Array代替array-like對象（轉換的代價<）

4-5 html優化

減小ifames 的使用

至關於多加了一個文檔。父級文檔要等它。

壓縮空白符

避免深層次的嵌套

嵌套越深，遍歷越慢

避免使用table佈局

已經out

css儘可能外聯

何時寫在行間?
首屏優化

刪除註釋

語義化標籤，方便瀏覽器作一些優化

有些標籤能夠不閉合

好比，ul裏面的li

js放在下面，別阻塞dom加載

總結：html的優化佔比較少，爲了把優化作到極致，能夠關注上面幾點，可是webpack集成了這樣的功能。（html-minifile）

4-6 CSS對性能的影響

解析css，會自右向左去讀，先找出全部的a標籤，而後再找出第二個條件進行過濾。

下降css的阻塞，用不到的到後面再進行加載。

利用GPU進行完成動畫，就是使用複合圖層。

使用contain屬性。

告訴瀏覽器，我和外面的不要緊，只對我裏面的元素進行更改，不用進行迴流，佈局的從新計算。

font-display 屬性

在頁面上先展現文字，減輕文字閃動的問題

5-1 資源的壓縮與合併

目的

減小http請求量
減少http請求資源的大小

怎麼作？

html壓縮。

（谷歌就沒壓縮，由於在別的方面作得更好）

css壓縮

js壓縮與混淆，大部分時候都是使用webpack在構建時進行壓縮。

css與js文件合併：

有的人認爲合併比較好，有的人認爲拆分比較好。在網絡上加載比較快。
總結就是同一模塊的小文件，ok的，由於如今都是漸進式加載。單純的爲了優化，減小http請求，會影響用戶體驗。

5-2 圖片格式優化[多種圖片格式-哪一種最合適]

一、jpg 有損壓縮 色彩好

連接在此

工具：

imagemin 對jpg圖片本身壓縮

場景

使用場景，圖片比較大，還想要儘可能保存畫質。

缺陷

當圖片有比較多的紋理和邊緣，就不太合適，由於壓縮比較高，會有鋸齒感。

二、PNG 透明背景

色彩上不相上下

工具

連接在此

場景

logo，紋理。

缺陷

大

三、webP

谷歌新推出的圖片格式
色彩上與JPG不相上下，可是壓縮比更高。
支持webp的瀏覽器。

5-3 圖片加載優化

圖片的懶加載

原生的圖片懶加載方案

<img loading="lazy" src="http://,,,,">

第三方圖片懶加載方案

連接在此（react-lazy-load-image-component）
verlok/lazyload,yall.js,Blazy

使用漸進式圖片

橫掃描的方式

漸進式圖片

優勢

剛開始就能看到圖片的全貌，用戶體驗更好

響應式圖片

適配。

剛開始只會加載一張圖片，srcset裏面是不一樣尺寸的圖片。會根據窗口的大小加載相應大小的圖片。

5-4 字體優化

什麼是FOIT ？什麼是Fout？

字體下載未完成時，瀏覽器隱藏或自動降級，致使字體閃爍。

Flash Of Invisible Text

Flash Of Unstyled Text

字體閃動不可避免。

font-display:auto|block|swap|fallback|optional

// block
// swap 替換的字體 不會白屏，可是很差看 
// fallback 100ms 提早下載完，下載完以前不顯示； 還沒下載完，我就替換
// optional 手機端優化，可以判斷網速，不佳，默認字體，可是默認字體設置上，就不退了

@font-face{
    unicode-
}