瀏覽器前端優化

liyg0187 7年前發布 | 32K 次閱讀 CSS 前端技術

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

從用戶體驗的角度，我們希望前端提供可以快速加載和執行的網頁。
而從開發者體驗的角度，我們希望前端是快速、簡單而規范的。

這不僅會給我們帶來快樂的用戶和快樂的開發者，而且由于 Google 偏向于優化，SEO 排名也會顯著提高。

如果你已經花費了大量時間來改善你網站的 Google Pagespeed Insights 分數，那么這將有助于揭示這一切實際上意味著什么，以及我們必須為優化前端所采取的大量策略。

背景

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

方法

首先

我們不能控制瀏覽器或者改變它的行為方式，但是我們可以理解它的工作原理，這樣就可以優化我們提供的負載。

幸運的是，瀏覽器行為的基礎原理是相當穩定而且文檔齊全的，并且在相當長一段時間內肯定不會發生顯著變化。

所以這至少給了我們一個目標。

其次

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

因此

我決定從外向內著手，搞清楚我們代碼的最終結果應該是什么樣的，然后形成編寫代碼的意見。在這第一篇博文中，我們打算專注于對于瀏覽器來說我們需要了解的一切。

瀏覽器都做了什么

下面我們來建立一些知識。如下是我們希望瀏覽器要運行的一些簡單 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 文件和一個外部 async JavaScript 文件。

<!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，并執行腳本。所以，盡管你可以在一次往返中傳遞幾個文件，它們每個也都會讓瀏覽器浪費寶貴的時間和資源，所以最好還是將文件合并在一起，消除不必要的加載。

在 head 部分為首屏設置內部樣式

是讓 CSS 和 JavaScript 內部化或者內聯，以防止獲取外部資源，還是相反，讓資源變成外部資源，這樣就可以緩存，從而讓 DOM 保持輕量，二者并非非黑即白。

但是有一個很好的觀點是對首屏關鍵內容設置內部樣式，可以避免在首次有意義的渲染時獲取資源。

最小化/壓縮圖片

這很簡單、基礎，有很多選擇可以這樣做，選一個你最喜歡的即可。

延遲加載圖片直到頁面加載后

用一些簡單的原生 JavaScript，你就可以延遲加載出現在折疊部分之下或者對首次用戶響應狀態不重要的圖片。這里有一些不錯的策略。

異步加載字體

字體加載的代價非常高，如果可以的話，你應該使用帶回退的 web 字體，然后逐步渲染字體和圖標。這看起來可能不咋樣，不過另一個選擇是如果字體還沒有加載，頁面加載時就完全沒有文字，這被稱為不可見文本的閃爍（Flash Of Invisible Text， FOIT ）。

是否真正需要 JavaScript/CSS?

你需要嗎？請回答我！是否有原生 HTML 元素可以產生用腳本一樣的行為？是否可以用行內樣式或圖標而不是內部/外部資源？比如，內聯一個 SVG 。

內容分發網絡（CDN）可用于為用戶提供物理上更近和更低延遲的位置，從而降低加載時間。

現在你開心慘了，已經知道了足夠多的東西，可以從這里走出去，自己探索有關這個主題的更多東西了。我推薦參加這個免費的 Udacity 課程，并且閱讀Google 自己的優化文檔。

如果你渴望更底層的知識，那么這本免費電子書《高性能瀏覽器網絡》是個開始的好地方。

總結

關鍵渲染路徑是最重要的，它讓網站優化有規律可循。需要關注的 3 個指標是：

1 — 關鍵字節數

2 — 關鍵文件數

3 — 關鍵路徑數

這里我所寫的應該足以讓你掌握基礎知識，并幫助你解釋 Google Pagespeed Insights對你的性能有什么看法。

最佳實踐的應用將伴隨著良好的 DOM 結構、網絡優化和可用于減少 CRP 指標的各種策略的結合。讓用戶更高興，讓 Google 的搜索引擎更高興。

在任何企業級網站中，這將是一項艱巨的任務，但是你必須遲早做到這一點，所以不要再承擔更多的技術性債務，并開始投資于堅實的性能優化策略。

感謝你閱讀至此，如果你真的做到了。衷心希望能幫到你，有任何反饋或者糾正，請給我發消息。

在本博客的下一部分中，我希望給出一個真實世界的例子，說明如何在我自己的團隊的大量代碼庫中實現所有這些原則。我們在一個域上擁有超過 2000 個可管理內容的頁面，并且每天為數十萬個頁面瀏覽量提供服務，因此這將很有趣。

不過這可能還需要段時間，我現在需要休息一下。

來自：https://segmentfault.com/a/1190000010818859

本文由用戶 liyg0187 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1503578198073.html

CSS 前端技術