再談前端性能優化

時間 2019-11-11

標籤再談前端性能優化欄目系統性能简体版

原文原文鏈接

好的設計應該簡單，並且始終能夠提供最佳性能。

1、優化緣由

谷歌的數據代表，一個有10條數據0.4秒能夠加載完的頁面，在變成30條數據加載時間爲0.9秒後，流量和廣告收入減小了20%。當谷歌地圖的首頁文件大小從100kb減小到70~80kb時，流量在第一週漲了10%，接下來的三週漲了25%。css

騰訊的前端工程師根據長期的數據監控也發現頁面的一秒鐘延遲會形成9.4%的PV的降低，8.3%跳出率的增長以及3.5%轉化率的降低。html

能夠看出，性能優化商業上來講很重要。前端

可是，更重要的仍是屏幕前咱們的用戶，讓用戶在使用產品時有更快更溫馨的瀏覽體驗，這算是一種前端工程師的自我修養。css3

2、優化目標

以讓用戶滿意爲目標呈現網頁是終極的目標。固然頁面速度要快，不過快只是構成滿意的一個因素。git

咱們使用Google團隊提出的RAIL模型做爲優化的目標。github

目前國內包括騰訊在內的團隊都在使用這個評估方案。web

Response:100ms內響應；chrome

Animation:10ms內生成一幀；瀏覽器

Idle:最大程度增長空閒時間；緩存

Load：1000ms內呈現內容；

1）以用戶爲中心 User-centered

用戶是性能優化的中心，一切性能優化皆是爲了用戶得到更佳的體驗。

那麼，咱們的用戶如何評價性能延遲：

0-16ms	用戶能夠感知每秒渲染 60 幀的平滑動畫轉場。也就是每幀 16 毫秒留給應用大約 10 毫秒的時間來生成一幀。
0-100ms	在此時間窗口內響應用戶操做，他們會以爲能夠當即得到結果。時間再長，操做與反應之間的鏈接就會中斷。
100-300ms	輕微可覺察的延遲
300-1000ms	延遲感受像是任務天然和持續發展的一部分(用戶以爲這是正常流，但不會以爲快)
1000+ms (>1s)	用戶的注意力將離開他們正在執行的任務。
10,000+ms (>10s)	用戶感到失望，可能會放棄任務；以後他們或許不會再回來。

注:1s=1000ms

2）Response：100ms內響應

用戶大多數輸入，無論他們是在點擊按鈕、切換表單控件仍是啓動動畫，若是未獲得響應，操做與反應之間的鏈接就會中斷。用戶會注意到這個延遲，這將會形成不完美的體驗。

在用戶注意到滯後以前，咱們有 100 ms的時間能夠響應用戶輸入。

對於須要超過 500 毫秒才能完成的操做，始終提供反饋，則用戶不會陷入困惑。這也是一些交互設計師一直堅持到處操做有反饋的緣由。

3）Animation: 10ms內生成一幀

在數學上來講，人眼感覺到的幀數爲60幀/s，則會認爲是流暢的動畫。

1s/60 = 1000ms/60 = 16ms/幀；

也就是說加上每一幀的預算是16ms，減去瀏覽器繪製幀的時間，留給咱們的大約只有10ms/幀。若是超過這個時間，用戶眼中動畫的流暢度就會下降。

4）Idle:最大程度增長空閒時間

利用空閒的時間完成推遲的工做。

例如，儘量減小預加載數據，以便您的應用快速加載，並利用空閒時間加載剩餘數據。推遲的工做應分紅每一個耗時約 50 毫秒的多個塊。若是用戶開始交互，優先級最高的事項是響應用戶。

5）Load: 1000ms內呈現內容

在 1 秒鐘內網站加載完畢。

不然用戶的注意力會分散，他們處理任務的感受會中斷。啓用漸進式渲染和在後臺執行一些工做。將非必需的加載推遲到空閒時間段。

總結

上述的RAIL指標，咱們能夠用chrome自帶的timeline工具檢測：

RAIL步驟	關鍵指標	用戶操做
Response	輸入延遲時間（從按下到繪製）小於 100 毫秒。	用戶點按按鈕（例如打開導航）。
Animation	每一個幀的工做（從 JS 到繪製）完成時間小於 16 毫秒。	用戶滾動頁面，拖動手指或看到動畫。拖動時，應用的響應與手指位置有關。
Idle	主線程 JS 工做分紅不大於 50 毫秒的塊。	用戶沒有與頁面交互，但主線程應足夠用於處理下一個用戶輸入。
Load	頁面能夠在 1000 毫秒內就緒。	用戶加載頁面並看到關鍵路徑內容。

3、優化方法

1.加載性能優化

1）優化內容效率

評估每一個資產的表現：其價值及其技術性能。

網頁每每會包含一些沒必要要的資源；或者更糟的是，包含的某些資源會影響網頁性能，同時還沒法給訪問者或所處的網站帶來太大價值。

網頁上一直包含資源 A（例如某個輪播圖）：

它提供給用戶的價值可否抵消下載並顯示它的開銷呢？

是否可以評估並證實其價值？

該資源（特別是第三方資源）可否保持穩定的性能？

該資源是否處於或是否須要處於關鍵路徑中？

若是該資源不可用，是否會影響網頁的性能和用戶體驗？

不斷地去對資源作檢查，以給用戶展現想看到的高性能、有價值信息。

2）圖片優化

圖片是網頁中的必不可少的元素，烘托氛圍，傳達信息，做用很普遍。同時，圖片也佔據大量字節，有極大優化的潛力。

2.1 減小圖片資源

是否真的須要用圖片去表達，若是不須要能夠儘可能去減小使用。這是最直接的優化方式（嗯我已經看見設計師提着刀過來了）。站在用戶和對方的角度思考一下，相信是能夠達到共識的。

2.2選擇合適的圖片格式

目前的圖片大體能夠分爲兩種：光柵圖和矢量圖。

矢量圖形使用線、點和多邊形來表示圖像，放大後仍然能夠保持清晰，最適用於高分辨率屏幕和須要以不一樣尺寸顯示的場景。

光柵圖形經過對矩形格柵內的每一個像素的值進行編碼來表示圖像，適合場景豐富的狀況。

若是能夠用css3等替代圖片，那是極好的。

若是不能被替代，能夠根據場景複雜度進行選擇；場景簡單，用矢量圖；場景複雜，用光柵圖。

光柵圖有不少格式，常見而熟知的有gif,png,jpg,webp等,每種格式都有本身獨特的編碼方式。

2.3深度優化

現今電子設備分辨率層出不窮，對圖片也有不同的要求。

CSS中1px實則是一個虛擬的相對像素，每每 1css像素 = ？設備像素。這裏的問號根據分辨率不一樣有着多種狀況。以下圖：

100 x 100 像素的圖像由 10,000 個像素組成。瀏覽器爲每一個通道分配 256 個值（色階），也就是每一個通道 8 位 (2 ^ 8 = 256)，每一個像素 4 個字節（4 個通道 x 8 位 = 32 位 = 4 個字節）。

10,000 個像素 x 4 個字節 = 40,000 個字節

40,000 個字節/1024 = 39 KB

由圖可知，圖片尺寸的增長，圖片所佔用的內存越大。物理屏幕的分辨率加倍，所需的像素數不僅是加倍，而是增長到原來的四倍。

所以，選擇合適尺寸的圖片對於性能很重要。爲合適的對象選擇合適尺寸從的圖片是有利於性能優化的。

上面提到，光柵圖有多種圖片格式，可是須要根據瀏覽器和需求選擇合適的格式：

GIF支持各類格式，可是畫質不高。png支持透明度和全部瀏覽器可是體積較大。jpg不支持透明度和動畫，可是支持全部瀏覽器並且體積小。後起新秀XR和Webp對於瀏覽器的支持不足，可是Webp體積小，比jpg還要小30%，能夠考慮向下兼容。

而png的可塑性也可圈可點，只要下降通道顏色的數量，體積能夠小到驚喜。畫質的改變見仁見智。

從左至右 (PNG)：32 位（256 色）、7 位（128 色）、5 位（32 色）

國外前端從業者總結出這樣的使用方法：

　　須要動畫：gif

　　不須要動畫

　　　　須要高畫質細節清晰

　　　　　　須要>256色圖片：png24

　　　　　　不須要>256色：png8

　　　　不須要高畫質細節清晰：jpg

【tips】

圖片優化指南

優化gif圖：http://www.lcdf.org/gifsicle/

優化jpg圖：http://jpegclub.org/jpegtran/

png無損優化：http://optipng.sourceforge.net/

png有損優化：https://pngquant.org/

svg壓縮：https://github.com/svg/svgo

2.4提供縮放的圖像

提供多餘像素的開銷只會讓瀏覽器代替咱們從新縮放圖像，減小並優化渲染網頁所需總字節數的大好機會所以被錯過。還要注意的是，尺寸調整不只受圖像縮減像素數的影響，還受其天然尺寸的影響。

應確保多餘像素數最少，並確保特別是較大資產以儘量接近其顯示尺寸的尺寸提供。

2.5合併圖像

優化原理來於web優化中的減小http請求數量，經過減小頁面圖片的數量來實現。

合併圖片後，能夠經過css的background-image、background-size、background-position屬性定位使用單個圖片。

使用cssgaga合併後的圖片

合併圖片後的圖片總大小會變得更小，可是須要注意：

a.合併主要用於圖標和按鈕等小而多的元素，複雜的圖像儘可能不合並，尤爲是jpg格式。

b.logo和內容圖片不要合併，不能破壞html自己的語義結構。

c.儘量讓顏色值相近的圖片合併到同一張雪碧圖裏面。

d.空白也要佔用空間，控制圖片以前的空隙。

e.追求優化度能夠手動合併，追求速度可使用工具合併，例如cssGaga等。

cssgaga目前使用的團隊有：

CSSGAGA的開發者是前騰訊的前端工程師，能夠看出目前騰訊基本是使用了cssgaga 進行圖片優化。

關於cssgaga: http://www.99css.com/cssgaga/

3）字體優化

若是對字體進行優化，再經過制定明智的策略對字體在網頁上的加載和應用方式做出規定，就能夠幫助減少網頁總大小，並縮短網頁渲染時間.

3.1選取字體

重要的是考慮它支持的字符集。

目前字體格式有四種：WOFF二、WOFF、EOT 和 TTF。

WOFF2	許多瀏覽器都未支持
WOFF	支持普遍，較舊的瀏覽器不支持
EOT	只有IE支持
TTF	部分IE支持

因此字體的選用能夠參照：

- 將 WOFF 2.0 變體提供給支持它的瀏覽器。
- 將 WOFF 變體提供給大多數瀏覽器。
- 將 TTF 變體提供給舊 Android（4.4 版如下）瀏覽器。
- 將 EOT 變體提供給舊 IE（IE9 版如下）瀏覽器。

3.2壓縮字體大小

字體是字形的集合；

每一個字形都是一組描述字母形狀的路徑。

各個字形不一樣，但它們仍然包含大量類似信息，這些信息可經過 GZIP 或兼容的壓縮工具進行壓縮。

考慮使用 Zopfli 壓縮處理 EOT、TTF 和 WOFF 格式。Zopfli 是一種兼容 zlib 的壓縮工具，提供的文件大小壓縮率比 gzip 高大約 5%。

3.3 瀏覽器尋找字體順序

字體變體的指定順序很重要。瀏覽器將選取其支持的第一種格式。

若是但願較新的瀏覽器使用 WOFF2，則應將 WOFF2 聲明置於 WOFF 之上，依此類推。

3.4 字體渲染

字體請在css裏面，因此將遠遠滯後於其餘關鍵資源請求的處理，而且在獲取資源以前，可能會阻止瀏覽器渲染文本。

- Safari 會在字體下載完成以前延遲文本渲染。
- Chrome 和 Firefox 會將字體渲染暫停最多 3 秒，以後他們會使用一種後備字體。而且字體下載完成後，他們會使用下載的字體從新渲染一次文本。
- IE 會在請求字體尚不可用時當即使用後備字體進行渲染，而後在字體下載完成後進行從新渲染。

4）關鍵渲染路徑優化

從收到 HTML、CSS 和 JavaScript 字節到對其進行必需的處理，從而將它們轉變成渲染的像素這一過程當中有一些中間步驟，優化性能其實就是了解這些步驟中發生了什麼 - 即關鍵渲染路徑。

4.1 對象模型

HTML 標記轉換成文檔對象模型 (DOM)；CSS 標記轉換成 CSS 對象模型 (CSSOM)。DOM 和 CSSOM 是獨立的數據結構。

字節 → 字符 → 標記 → 節點 → 對象模型

dom樹

瀏覽器根據字節 → 字符 → 標記 → 節點 → 對象模型的順序，逐步建立了dom樹。

4.2 CSS對象模型

瀏覽器構建頁面的 DOM 時，在文檔的 head 部分遇到了一個 link 標記，該標記引用一個外部 CSS 樣式表：style.css。因爲預見到須要利用該資源來渲染頁面，它會當即發出對該資源的請求，並返回樣式的內容：

與處理 HTML 時同樣，咱們須要將收到的 CSS 規則轉換成某種瀏覽器可以理解和處理的東西。所以，咱們會重複 HTML 過程，不過是爲 CSS 而不是 HTML。

cssdom樹

頁面上的任何對象計算最後一組樣式時，瀏覽器都會先從適用於該節點的最通用規則開始（例如，若是該節點是 body 元素的子項，則應用全部 body 樣式），而後經過應用更具體的規則（即規則「向下級聯」）以遞歸方式優化計算的樣式。因此，cssdom樹有樹的形狀。

每一個瀏覽器都提供一組默認樣式（也稱爲「User Agent 樣式」），即咱們不提供任何自定義樣式時所看到的樣式。咱們的樣式只是替換這些默認樣式。

DevTools 中記錄時間線並尋找「Recalculate Style」事件：與 DOM 解析不一樣，該時間線不顯示單獨的「Parse CSS」條目，而是在這一個事件下一同捕獲解析和 CSSOM 樹構建，以及計算的樣式的遞歸計算。

4.3 渲染樹建設、佈局和繪製

CSSOM 樹和 DOM 樹合併成渲染樹，而後用於計算每一個可見元素的佈局，並輸出給繪製流程，將像素渲染到屏幕上。

4.3.1 DOM和CSSOM合併爲渲染樹

遍歷網頁上全部可見的（除了display:none） DOM 內容，以及每一個節點的全部 CSSOM 樣式信息。

過程：

從 DOM 樹的根節點開始遍歷每一個可見節點；

對於每一個可見節點，爲其找到適配的 CSSOM 規則並應用它們；

發射可見節點，連同其內容和計算的樣式。

注： visibility: hidden 與 display: none 是不同的。前者隱藏元素，但元素仍佔據着佈局空間（即將其渲染成一個空框），然後者 (display: none) 將元素從渲染樹中徹底移除，元素既不可見，也不是佈局的組成部分。

4.3.2 佈局（自動重排）

咱們計算每一個對象在設備視口內的確切位置和大小---這就是「佈局」階段。

佈局流程的輸出是一個「盒模型」，它會精確地捕獲每一個元素在視口內的確切位置和尺寸：全部相對測量值都轉換爲屏幕上的絕對像素。

4.3.3 繪製（柵格化）

將渲染樹中的每一個節點轉換成屏幕上的實際像素。

- 「Layout」事件在時間線中捕獲渲染樹構建以及位置和尺寸計算。
- 佈局完成後，瀏覽器會當即發出「Paint Setup」和「Paint」事件，將渲染樹轉換成屏幕上的像素

執行渲染樹構建、佈局和繪製所需的時間將取決於文檔大小、應用的樣式，以及運行文檔的設備：文檔越大，瀏覽器須要完成的工做就越多；樣式越複雜，繪製須要的時間就越長。

4.3.4 渲染

關鍵渲染路徑要求咱們同時具備 DOM 和 CSSOM 才能構建渲染樹。這會給性能形成嚴重影響：HTML 和 CSS 都是阻塞渲染的資源。 HTML 顯然是必需的，由於若是沒有 DOM，咱們就沒有可渲染的內容，但 CSS 的必要性可能就不太明顯。

右側的狀況一般稱爲「內容樣式短暫失效」(FOUC)

CSS 是阻塞渲染的資源。須要將它儘早、儘快地下載到客戶端，以便縮短首次渲染的時間。

第一個聲明阻塞渲染，適用於全部狀況。

第二個聲明一樣阻塞渲染：「all」是默認類型，若是您不指定任何類型，則隱式設置爲「all」。所以，第一個聲明和第二個聲明其實是等效的。

第三個聲明具備動態媒體查詢，將在網頁加載時計算。根據網頁加載時設備的方向，portrait.css 可能阻塞渲染，也可能不阻塞渲染。

最後一個聲明只在打印網頁時應用，所以網頁首次在瀏覽器中加載時，它不會阻塞渲染。

「阻塞渲染」僅是指瀏覽器是否須要暫停網頁的首次渲染，直至該資源準備就緒。不管哪種狀況，瀏覽器仍會下載 CSS資源，只不過不阻塞渲染的資源優先級較低罷了。

4.3.5 使用js增長交互性

咱們的腳本在文檔的何處插入，就在何處執行。

當 HTML 解析器遇到一個 script 標記時，它會暫停構建 DOM，將控制權移交給 JavaScript 引擎；等 JavaScript 引擎運行完畢，瀏覽器會從中斷的地方恢復 DOM 構建，也就延緩了首次渲染。

「優化關鍵渲染路徑」在很大程度上是指了解和優化 HTML、CSS 和 JavaScript 之間的依賴關係譜。

不管咱們使用 <script> 標記仍是內聯 JavaScript 代碼段，瀏覽器都會先暫停並執行腳本，而後纔會處理剩餘文檔。不過，若是是外部 JavaScript 文件，瀏覽器必須停下來，等待從磁盤、緩存或遠程服務器獲取腳本，這就可能給關鍵渲染路徑增長數十至數千毫秒的延遲。

爲此，咱們能夠將腳本標記爲——異步：

向 script 標記添加異步關鍵字能夠指示瀏覽器在等待腳本可用期間不阻止 DOM 構建，這樣能夠顯著提高性能。

4.3.6 評估關鍵渲染路徑

每一個可靠性能策略的基礎，準確的評估和檢測必不可少。

Lighthouse 是一個網絡應用審覈工具，能夠對特定頁面運行一系列測試，而後在彙總報告中顯示頁面的結果。

也能夠安裝成瀏覽器插件使用。

2.渲染性能優化

2.1 優化js執行

測量 JavaScript 開銷和性能狀況的最佳方法是使用 Chrome DevTools

若是發現有長時間運行的 JavaScript，則能夠在 DevTools 用戶界面的頂部啓用 JavaScript 分析器：

有了這些信息以後，能夠評估 JavaScript 對應用性能的影響，並開始找出和修正函數運行時間過長的熱點。如前所述，應當設法移除長時間運行的 JavaScript，或者若不能移除，則將其移到 Web Worker 中，騰出主線程繼續執行其餘任務。

2.2 避免大型複雜的佈局

與樣式計算類似，佈局開銷的直接考慮因素以下：

須要佈局的元素數量。

這些佈局的複雜性。

2.2.1儘量避免佈局操做

當您更改樣式時，瀏覽器會檢查任何更改是否須要計算佈局，以及是否須要更新渲染樹。對「幾何屬性」（如寬度、高度、左側或頂部）的更改都須要佈局計算。

2.2.2 使用 flexbox 而不是較早的佈局模型

1,300 個框上使用浮動的佈局開銷

使用 Flexbox（Web 平臺的新模型）

2.3 Composite:渲染層合併

利用合成層對於提高頁面性能方面有很大的做用。

合成層的位圖，會交由 GPU 合成，比 CPU 處理要快；當須要 repaint 時，只須要 repaint 自己，不會影響到其餘的層；對於 transform 和 opacity 效果，不會觸發 layout 和 paint。

2.3.1合成層好處

a.提高動畫效果

合成層的好處是不會影響到其餘元素的繪製，能夠減小動畫元素對其餘元素的影響，從而減小 paint。

使用 CSS 的 will-change 屬性：

will-change 設置爲 opacity、transform、top、left、bottom、right 能夠將元素提高爲合成層。

對於那些目前還不支持 will-change 屬性的瀏覽器，目前經常使用的是使用一個 3D transform 屬性來強制提高爲合成層。

使用 Timeline 來確認新的合成層是否真的改進了渲染性能。不能盲目提高合成層，必定要分析其實際性能表現。

b.減小繪製區域

對於不須要從新繪製的區域應儘可能避免繪製，以減小繪製區域。

好比一個 fix 在頁面頂部的固定不變的導航 header，在頁面內容某個區域 repaint 時，整個屏幕包括 fix 的 header 也會被重繪。

固定不變的區域，咱們指望其並不會被重繪，所以能夠將其提高爲獨立的合成層。減小繪製區域，須要仔細分析頁面，區分繪製區域，減小重繪區域甚至避免重繪。

c.合理管理合成層

建立一個新的合成層並非免費的，它得消耗額外的內存和管理資源。實際上，在內存資源有限的設備上，合成層帶來的性能改善，可能遠遠趕不上過多合成層開銷給頁面性能帶來的負面影響。

下面的例子中，建立了2000個相同的div元素，第一個未提高爲合成層，第二個提高爲合成層：

內存消耗結果顯示：提高爲合成層後反而消耗更多。

2.3.2合成層原理

一個 Web 頁面的展現，簡單來講能夠認爲經歷瞭如下下幾個步驟。

對頁面中 DOM 元素的繪製是在多個層上進行的。在每一個層上完成繪製過程以後，瀏覽器會將全部層按照合理的順序合併成一個圖層，而後顯示在屏幕上。

DOM 樹中得每一個 Node 節點都有一個對應的 LayoutObject ;

通常來講，擁有相同的座標空間的 LayoutObjects，屬於同一個PaintLayer,特殊狀況會爲一些特殊的 LayoutObjects 建立一個新的渲染層；

合成層擁有單獨的 GraphicsLayer，而其餘不是合成層的渲染層，則和其第一個擁有 GraphicsLayer 父層公用一個。

PaintLayer爲 SelfPaintingLayer時能夠提高爲合成層,也就是必須知足如下之一的條件才能提高爲合成層。

- 根元素（HTML）
- 有明確的定位屬性（relative、fixed、sticky、absolute）
- 透明的（opacity 小於 1）
- 有 CSS 濾鏡（fliter）
- 有 CSS mask 屬性
- 有 CSS mix-blend-mode 屬性（不爲 normal）
- 有 CSS transform 屬性（不爲 none）
- backface-visibility 屬性爲 hidden
- 有 CSS reflection 屬性
- 有 CSS column-count 屬性（不爲 auto）或者有 CSS column-width 屬性（不爲 auto）
- 當前有對於 opacity、transform、fliter、backdrop-filter 應用動畫