瀏覽器前端優化

時間 2019-11-07

原文原文鏈接

本文轉載自：衆成翻譯
譯者：網絡埋伏紀事
連接：http://www.zcfy.cc/article/2847
原文：https://hackernoon.com/optimising-the-front-end-for-the-browser-f2f51a29c572#.81dkyz4uujavascript

優化全都是與速度和滿意度有關。css

從用戶體驗的角度，咱們但願前端提供能夠快速加載和執行的網頁。html
而從開發者體驗的角度，咱們但願前端是快速、簡單而規範的。前端

這不只會給咱們帶來快樂的用戶和快樂的開發者，並且因爲 Google 偏向於優化，SEO 排名也會顯著提升。html5

若是你已經花費了大量時間來改善你網站的 Google Pagespeed Insights分數，那麼這將有助於揭示這一切實際上意味着什麼，以及咱們必須爲優化前端所採起的大量策略。java

背景

最近個人整個團隊有機會花一些時間加快把咱們提出的升級變爲代碼庫，多是用 React。這確實讓我思考起了咱們該如何建立前端。很快，我意識到瀏覽器將是咱們的方法中的一個重要因素，同時也是咱們知識中的大瓶頸。node

方法

首先

咱們不能控制瀏覽器或者改變它的行爲方式，可是咱們能夠理解它的工做原理，這樣就能夠優化咱們提供的負載。react

幸運的是，瀏覽器行爲的基礎原理是至關穩定並且文檔齊全的，而且在至關長一段時間內確定不會發生顯著變化。git

因此這至少給了咱們一個目標。github

其次

另外一方面，代碼、技術棧、架構和模式是咱們能夠控制的東西。它們更靈活，變化的更快，並給咱們這一邊提供了更多選擇。

所以

我決定從外向內着手，搞清楚咱們代碼的最終結果應該是什麼樣的，而後造成編寫代碼的意見。在這第一篇博文中，咱們打算專一於對於瀏覽器來講咱們須要瞭解的一切。

瀏覽器都作了什麼

下面咱們來創建一些知識。以下是咱們但願瀏覽器要運行的一些簡單 HTML：

<!DOCTYPE html>
<html>
  <head>
    <title>The "Click the button" page</title>
    <meta charset="UTF-8">
    <link rel="stylesheet" href="styles.css" />
  </head>
  
  <body>
    <h1>
      Click the button.
    </h1>
    
    <button type="button">Click me</button>
    
    <script>
      var button = document.querySelector("button");
      button.style.fontWeight = "bold";
      button.addEventListener("click", function () {
        alert("Well done.");
      });
    </script>
  </body>
</html>

瀏覽器如何渲染網頁

當瀏覽器接收到 HTML 時，就會解析它，將其分解爲瀏覽器所能理解的詞彙，而這個詞彙因爲HTML5 DOM 規範定義，在全部瀏覽器中是保持一致的。而後瀏覽器經過一系列步驟來構造和渲染頁面。以下是一個很高層次的概述：

使用 HTML 建立文檔對象模型（DOM）。
使用 CSS 建立 CSS 對象模型（CSSOM）。
基於 DOM 和 CSSOM 執行腳本（Script）。
合併 DOM 和 CSSOM 造成渲染樹（Render Tree）。
使用渲染樹佈局（Layout）全部元素的大小和位置。
繪製（Paint）全部元素。

步驟一 — HTML

瀏覽器開始從上到下讀取標記，而且經過將它分解成節點，來建立 DOM 。

HTML 加載優化策略

樣式在頂部，腳本在底部

雖然這個規則有例外和細微差異，不過整體思路是儘量早地加載樣式，儘量晚地加載腳本。緣由是腳本執行以前，須要 HTML 和 CSS 解析完成，所以，樣式儘量的往頂部放，這樣在底部腳本開始編譯和執行以前，樣式有足夠的時間完成計算。

下面咱們進一步研究如何在優化的同時作細微調整。

最小化和壓縮

這適用於咱們提交的全部內容，包括 HTML、CSS、JavaScript、圖片和其它資源。

最小化是移除全部多餘的字符，包括空格、註釋、多餘的分號等等。

壓縮（好比 GZip）是將代碼或者資源中重複的數據替換爲一個指向原始實例的指針，大大壓縮下載文件的大小，而且是在客戶端解壓文件。

左右開弓的話，能夠潛在將負載下降 80% 到 90%。好比：光 bootstrap 就節省了 87% 的負載。

可訪問性

雖然可訪問性不會讓頁面的下載變得更快，可是會大大提升殘障人士的滿意度。要確保是給全部人提供的！給元素加上 aria 標籤，給圖片提供 alt 文本，以及全部其它好東西。

使用像 WAVE 這樣的工具確認在哪些地方能夠改善可訪問性。

步驟二 — CSS

當瀏覽器發現任何與節點相關的樣式時（即外部樣式表、內部樣式表或行內樣式），就當即中止渲染 DOM ，並用這些節點來建立 CSSOM。這就是人們稱 CSS 阻塞渲染的緣由。這裏是不一樣類型樣式的一些優缺點。

//外部樣式
<link rel="stylesheet" href="styles.css">

// 內部樣式
<style>
  h1 {
    font-size: 18px;
  }
</style>

// 行內樣式
<button style="background-color: blue;">Click me</button>

CSSOM 節點的建立與 DOM 節點的建立相似，隨後，二者會被合併。這就是如今它們的樣子：

CSSOM 的構建會阻塞頁面的渲染，所以咱們想在樹中儘量早地加載樣式，讓它們儘量輕便，而且在有效的地方延遲加載它們。

CSS 加載優化策略

使用 media 屬性

media 屬性指定要加載樣式必須知足的條件，好比：是最大仍是最小分辨率？是面向屏幕閱讀器嗎？

桌面是很強大，可是移動設備不是，因此咱們想給移動設備儘量最輕的負載。咱們能夠假設先只提供移動端樣式，而後對桌面端樣式放一個媒體條件。雖然這樣作不會阻止桌面端樣式下載，不過會阻止它阻塞頁面加載和使用寶貴的資源。

// 這個 css 在全部狀況都會下載，並阻塞頁面的渲染。
// media="all" 是默認值，而且與不聲明任何 media 屬性同樣。
<link rel="stylesheet" href="mobile-styles.css" media="all">

// 在移動端，這個 css 會在後臺下載，並且不會中斷頁面加載。
<link rel="stylesheet" href="desktop-styles.css" media="min-width: 590px">

// CSS 中只爲打印視圖計算的媒體查詢
<style>
  @media print {
    img {
      display: none;
    }
  }
</style>

延遲加載 CSS

若是咱們有一些樣式能夠等到首屏有價值的內容渲染完成後，再加載和計算，好比出如今首屏如下的，或者頁面變成響應式以後不那麼重要的東西。咱們能夠把樣式加載寫在腳本中，用腳本等待頁面加載完成，而後再插入樣式。

<html>
  <head>
    <link rel="stylesheet" href="main.css">
  </head>
  
  <body>
    <div class="main">
      摺疊內容之上的重要部分。
    </div>
    
    <div class="secondary">
      摺疊內容之下。頁面加載以後，向下滾動纔會看到的東西。
    </div>
    
    <script>
      window.onload = function () {
        // 加載 secondary.css
      }
    </script>
  </body>
</html>

這裏有一個如何實現這個的例子，還有另外一個例子。

較小的特殊性

鏈在一塊兒的元素越多，天然要傳輸的數據就越多，於是會增大 CSS 文件，這是一個明顯的缺點。不過這樣作還有一個客戶端計算的損耗，即會把樣式計算爲較高的特殊性。

// 更具體的選擇器 == 糟糕
.header .nav .menu .link a.navItem {
  font-size: 18px;
}

// 較不具體的選擇器 == 好
a.navItem {
  font-size: 18px;
}

只加載須要的樣式

這聽起來可能有點愚蠢或者裝模做樣，不過若是你已經從事前端工做多年的話，就會知道 CSS 的一個最大問題是刪除東西的不可預測性。設計的時候它就是被下了不斷增加這樣的詛咒。

要儘量多削減 CSS ，可使用相似uncss)包這樣的工具，或者若是想有一個網上的替代品，那就處處找找，仍是有挺多選擇的。

步驟三 — JavaScript

而後，瀏覽器會不斷建立 DOM / CSSOM 節點，直到發現任何 JavaScript 節點，即外部或者行內的腳本。

// 外部腳本
`<script src="app.js">`</script>

// 內部腳本
<script>
  alert("Oh, hello");
</script>

因爲腳本可能須要訪問或操做以前的 HTML 或樣式，咱們必須等待它們構建完成。

所以瀏覽器必須中止解析節點，完成建立 CSSOM，執行腳本，而後再繼續。這就是人們稱 JavaScript 阻塞解析器的緣由。

瀏覽器有種稱爲'預加載掃描器'的東西，它會掃描 DOM 的腳本，並開始預加載腳本，不過腳本只會在先前的 CSS 節點已經構建完成後，纔會依次執行。

假如這就是咱們的腳本：

var button = document.querySelector("button");
button.style.fontWeight = "bold";
button.addEventListener("click", function () {
  alert("Well done.");
});

那麼這就是咱們的 DOM 和 CSSOM 的效果：

JavaScript 加載優化策略

優化腳本是咱們能夠作的最重要的事情之一，同時也是大多數網站作得最糟糕的事情之一。

異步加載腳本

經過在腳本上使用 async 屬性，能夠通知瀏覽器繼續，用另外一個低優先級的線程下載這個腳本，而不要阻塞其他頁面的加載。一旦腳本下載完成，就會執行。

`<script src="async-script.js" async>`</script>

這意味着這段腳本能夠隨時執行，這就致使了兩個明顯的問題。首先，它能夠在頁面加載後執行很長時間，因此若是依靠它爲用戶體驗作一些事情，那麼可能會給用戶一個不是最佳的體驗。其次，若是它恰好在頁面完成加載以前執行，咱們就無法預測它會訪問正確的 DOM/CSSOM 元素，而且可能會中斷執行。

async 適用於不影響 DOM 或 CSSOM 的腳本，並且尤爲適用於與 HTML 和 CSS 代碼無關，對用戶體驗無影響的外部腳本，好比分析或者跟蹤腳本。不過若是你發現了任何好的使用案例，那就用它。

延遲加載腳本

defer 跟 async 很是類似，不會阻塞頁面加載，但會等到 HTML 完成解析後再執行，而且會按出現的次序執行。

這對於會做用於渲染樹上的腳原本說，確實是一個好的選擇。不過對於加載摺疊內容之上的頁面，或者須要以前的腳本已經運行的腳原本說，並不重要。

`<script src="defer-script.js" defer>`</script>

這裏是使用 defer 策略的另外一個好選擇，或者也可使用 addEventListener。若是想了解更多，請從這裏開始閱讀。

// 全部對象都在 DOM 中，而且全部圖像、腳本、link 和子幀都完成了加載。
window.onload = function () {
};

// 在 DOM 準備好時調用，在圖像和其它外部內容準備好以前
document.onload = function () {
};

// JQuery 的方式
$(document).ready(function () {
});

不幸的是 async 和 defer 對於行內腳本不起做用，由於只要有行內腳本，瀏覽器默認就會編譯和執行它們。當腳本內嵌在 HTML 中時，就會當即運行，經過在外部資源上使用上述兩個屬性，咱們只是把腳本抽取出來，或者延遲把腳本發佈到 DOM/CSSOM。

操做以前克隆節點

當且僅當對 DOM 執行屢次修改時看到了沒必要要的行爲時，就試試這招。

先克隆整個 DOM 節點，對克隆的節點作修改，而後用它來替換原始節點，這樣可能效率更高。由於這樣就避免了屢次重畫，下降了 CPU 和內存消耗。這樣作還能夠避免更改頁面時的抖動和無樣式內容的閃爍（Flash of Unstyled Content，FOUC）。

// 經過克隆，高效操做一個節點

var element = document.querySelector(".my-node");
var elementClone = element.cloneNode(true); // (true) 也克隆子節點， (false) 不會

elementClone.textContent = "I've been manipulated...";
elementClone.children[0].textContent = "...efficiently!";
elementClone.style.backgroundColor = "green";

element.parentNode.replaceChild(elementClone, element);

請注意，克隆的時候並無克隆事件監聽器。有時這實際上恰好是咱們想要的。過去咱們已經用過這種方法來重置不調用命名函數時的事件監聽器，並且那時也沒有 jQuery 的 .on() 和 .off() 方法可用。

Preload/Prefetch/Prerender/Preconnect

這些屬性基本上也實現了它們所作的承諾，並且都棒極了。不過，這些屬性都是至關新，還沒被瀏覽器廣泛支持，也就是說對咱們大多數人來講它們實際上不是真正的競爭者。不過，若是你有空的話，能夠看看這裏和這裏。

步驟四 — 渲染樹

一旦全部節點已被讀取，DOM 和 CSSOM 準備好合併，瀏覽器就會構建渲染樹。若是咱們把節點當成單詞，把對象模型當成句子，那麼渲染樹即是整個頁面。如今瀏覽器已經有了渲染頁面所需的全部東西。

步驟五 — 佈局

而後咱們進入佈局階段，肯定頁面上全部元素的大小和位置。

步驟六 — 繪製

最終咱們進入繪製階段，真正地光柵化屏幕上的像素，爲用戶繪製頁面。

整個過程一般會在幾秒或者十分之一秒內發生。咱們的任務是讓它作得更快。

若是 JavaScript 事件改變了頁面的某個部分，就會致使渲染樹的重繪，而且迫使咱們再次經歷佈局和繪製。如今瀏覽器足夠智能，會僅進行部分重畫。不過咱們不能期望靠這就能高效或者高性能。

話雖如此，不過很顯然 JavaScript 主要是在客戶端基於事件，並且咱們想讓它來操做 DOM，因此它就得作到這一點。咱們只是必須限制它的不良影響。

至此你已經足夠認識到要感謝 Tali Garsiel 的演講。這是 2012 年的演講，可是信息依然是真實的。她在此主題上的綜合論文能夠在這裏讀到。

若是你喜歡迄今爲止所讀過的內容，但仍然渴望知道更多的底層技術性的東西，那麼全部知識的權威就是HTML5 規範。

咱們差很少搞定了，不過請和我多待段時間！如今咱們來探討爲何須要知道上面的全部知識。

瀏覽器如何發起網絡請求

本節中，咱們將理解如何才能高效地把渲染頁面所需的數據傳輸給瀏覽器。

當瀏覽器請求一個 URL 時，服務器會響應一些 HTML。咱們將從超級小的開始，慢慢增長複雜性。

假如這就是咱們頁面的 HTML：

<!DOCTYPE html>
<html>
  <head>
    <title>The "Click the button" page</title>
  </head>
  
  <body>
    <h1>
      Button under construction...
    </h1>
  </body>
</html>

咱們須要學習一個新術語，關鍵渲染路徑（Critical Rendering Path，CRP），就是瀏覽器渲染頁面所需的步數。以下就是如今咱們的 CRP 示意圖看起來的樣子：

瀏覽器發起一個 GET 請求，在咱們頁面（如今尚未 CSS 及 JavaScript）所需的 1kb HTML 響應回來以前，它一直是空閒的。接收到響應以後，它就能建立 DOM，並渲染頁面。

關鍵路徑長度

三個 CRP 指標的第一個是路徑長度。咱們想讓這個指標儘量低。

瀏覽器用一次往返來獲取渲染頁面所需的 HTML，而這就是它所需的一切。所以咱們的關鍵路徑長度是 1，很完美。

下面咱們上一個檔次，加點內部樣式和內部 JavaScript。

<!DOCTYPE html>
<html>
  <head>
    <title>The "Click the button" page</title>
    <style>
      button {
        color: white;
        background-color: blue;
      }
    </style>
  </head>
  
  <body>
    <button type="button">Click me</button>
    
    <script>
      var button = document.querySelector("button");
      button.addEventListener("click", function () {
        alert("Well done.");
      });
    </script>
  </body>
</html>

若是咱們檢查一下 CRP 示意圖，應該能看到有兩點變化。

新增了兩步，建立 CSSOM和執行腳本。這是由於咱們的 HTML 有內部樣式和內部腳本須要計算。不過，因爲沒有發起外部請求，關鍵路徑長度沒變。

可是注意，渲染沒那麼快了。並且咱們的 HTML 大小增長到了 2kb，因此某些地方仍是受了影響。

關鍵字節數

那就是三個指標之二，關鍵字節數出現的地方。這個指標用來衡量渲染頁面須要傳送多少字節數。並不是頁面會下載的全部字節，而是隻是實際渲染頁面，並把它響應給用戶所需的字節。

不用說，咱們也想減小這個數。

若是你認爲這就不錯了，誰還須要外部資源啊，那就大錯特錯了。雖然這看起來很誘人，可是它在規模上是不可行的。在現實中，若是個人團隊要經過內部或者行內方式給頁面之一提供所需的一切，頁面就會變得很大。而瀏覽器不是爲了處理這樣的負載而建立的。

看看這篇關於像 React 推薦的那樣內聯全部樣式時，頁面加載效果的有趣文章。DOM 變大了四倍，掛載花了兩倍的時間，到能夠響應多花了 50% 的時間。至關不能接受。

還要考慮一個事實，就是外部資源是能夠被緩存的，所以在回訪頁面，或者訪問用相同資源（好比 my-global.css）的其它頁面時，瀏覽器就用發起網絡請求，而是用其緩存的版本，從而爲咱們贏得更大的勝利。

因此下面咱們更進一步，對樣式和腳本使用外部資源。注意這裏咱們有一個外部 CSS 文件、一個外部 JavaScript 文件和一個外部 asyncJavaScript 文件。

<!DOCTYPE html>
<html>
  <head>
    <title>The "Click the button" page</title>
    <link rel="stylesheet" href="styles.css" media="all">
    `<script type="text/javascript" src="analytics.js" async>`</script>  // async
  </head>
  
  <body>
    <button type="button">Click me</button>
    
    `<script type="text/javascript" src="app.js">`</script>
  </body>
</html>

以下是如今 CRP 示意圖看起來的樣子：

瀏覽器獲得頁面，建立 DOM，一發現任何外部資源，預加載掃描器就開始介入。繼續，開始下載 HTML 中所找到的全部外部資源。CSS 和 JavaScript 有較高的優先級，其它資源次之。

它挑出咱們的 styles.css 和 app.js，開闢另外一條關鍵路徑去獲取它們。不過不會挑出 analytics.js，由於咱們給它加了 async屬性。瀏覽器依然會用另外一個低優先級的線程下載它，不過由於它不會阻塞頁面渲染，因此也與關鍵路徑無關。這正是 Google 本身的優化算法對網站進行排名的方式。

關鍵文件

最後，是咱們最後一個 CRP 指標，關鍵文件，也就是瀏覽器渲染頁面須要下載的文件總數。在例三中，HTML 文件自己、CSS 和 JavaScript 文件都是關鍵文件。async 的腳本不算。固然，文件越少越好。

回到關鍵路徑長度

如今你可能會認爲這確定就是最長的關鍵路徑吧？個人意思是說要渲染頁面，咱們只須要下載 HTML、CSS 和 JavaScript，並且只須要兩個往返就能夠搞定。

HTTP1 文件限制

不過，生活依然沒那麼簡單。拜 HTTP1 協議所賜，咱們的瀏覽器一次從一個域名併發下載的最大文件數是有限制的。範圍從 2（很老的瀏覽器）到 10（Edge）或者 6（Chrome）。

你能夠從這裏查看用戶瀏覽器請求你的域名時的最大併發文件數。

你能夠而且應該經過把一些資源放在影子域名上，來繞開這個限制，從而最大限度地提升優化潛力。

警告：不要把關鍵的 CSS 放到根域名以外的其餘地方，DNS 查找和延遲都會抵消這樣作時所帶來的任何可能的好處。

HTTP2

若是網站是 HTTP2，而且用戶的瀏覽器也是兼容的，那麼你就能夠徹底避開這個限制。不過，這種好事並不常見。

能夠在這裏測試你網站的 HTTP2。

TCP 往返限制

另外一個敵人逼近了！

任何一次往返可傳輸的最大數據量是 14kb，對於包括全部 HTML、CSS 和腳本在內的全部網絡請求都是如此。這來自於防止網絡擁堵和丟包的一個 TCP 規範。

若是一次請求中，咱們的 HTML 或者任何累積的資源超過了 14kb，那麼就須要多作一次往返來獲取它們。因此，是的，這些大的資源確實會給 CRP 添加不少路徑。

大招

如今將咱們的大網頁傾巢而出。

<!DOCTYPE html>
<html>
  <head>
    <title>The "Click the button" page</title>
    <link rel="stylesheet" href="styles.css">     // 14kb
    <link rel="stylesheet" href="main.css">       // 2kb
    <link rel="stylesheet" href="secondary.css">  // 2kb
    <link rel="stylesheet" href="framework.css">  // 2kb
    `<script type="text/javascript" src="app.js">`</script>  // 2kb
  </head>
  
  <body>
    <button type="button">Click me</button>
    
    `<script type="text/javascript" src="modules.js">`</script> // 2kb
    `<script type="text/javascript" src="analytics.js">`</script> // 2kb
    `<script type="text/javascript" src="modernizr.js">`</script>  // 2kb
  </body>
</html>

如今我知道一個按鈕就有不少 CSS 和 JavaScript，可是它是一個很重要的按鈕，它對咱們來講意義重大。因此就不要評判，好嗎？

整個頁面被很好地最小化和壓縮到 2kb，遠低於 14kb 的限制，因此咱們又回到正好一次 CRP 往返了，而瀏覽器開始忠實地用一個關鍵文件，即咱們的 HTML，來建立 DOM。

CRP 指標：長度 1，文件數 1，字節數 2kb

瀏覽器發現了一個 CSS 文件，而預加載掃描器識別出全部外部資源（CSS 和 JavaScript），併發送一個請求開始下載它們。可是等一等，第一個 CSS 文件是 14kb，超出了一次往返的最大負載，因此它自己就是一個 CRP。

CRP 指標：長度 2，文件數 2，字節數 16kb

而後它繼續下載資源。餘下的資源低於 14kb，因此能夠在一次往返中搞定。不過因爲總共有 7 個資源，並且咱們的網站還沒啓用 HTTP2，並且用的是 Chrome，因此此次往返只能下載 6 個文件。

CRP 指標：長度 3，文件數 8，字節數 28kb

如今咱們終於能夠下載完最終文件，並開始渲染 DOM了。

CRP 指標：長度 4，文件數 9，字節數 30kb

咱們的 CRP 總共有 30kb 的關鍵資源，在 9 個關鍵文件和 4 個關鍵路徑中。有了這個信息，以及一些關於鏈接中延遲的知識，咱們實際上就能夠開始對給定用戶的頁面性能進行真正準確的估計了。

瀏覽器網絡優化策略

Pagespeed Insights

使用Insights 來肯定性能問題。Chrome DevTools 中還有個 audit標籤。

善用 Chrome 開發者工具

DevTools 如此驚人。咱們爲它單獨寫一整本書，不過這裏已經有很多資源能夠幫助你。這裏)有一篇開始解釋網絡資源的文章值得一讀。

在好的環境中開發，在糟糕的環境中測試

你固然想在你的 1tb SSD、32G 內存的 Macbook Pro 上開發，不過對於性能測試，應該轉到 Chrome 中的 network 標籤下，模擬低帶寬、節流 CPU 鏈接，從而真正獲得一些有用的信息。

合併資源/文件

在上面的 CRP 示意圖中，我省略了一些你不須要知道的東西。不過基本上，每接收到一個外部 CSS 和 JavaScript 文件後，瀏覽器都會構建 CSSOM，並執行腳本。因此，儘管你能夠在一次往返中傳遞幾個文件，它們每一個也都會讓瀏覽器浪費寶貴的時間和資源，因此最好仍是將文件合併在一塊兒，消除沒必要要的加載。