摘要：幸運(yùn)的是，瀏覽器行為的基礎(chǔ)原理是相當(dāng)穩(wěn)定而且文檔齊全的，并且在相當(dāng)長一段時間內(nèi)肯定不會發(fā)生顯著變化。瀏覽器有種稱為預(yù)加載掃描器的東西，它會掃描的腳本，并開始預(yù)加載腳本，不過腳本只會在先前的節(jié)點(diǎn)已經(jīng)構(gòu)建完成后，才會依次執(zhí)行。

本文轉(zhuǎn)載自：眾成翻譯
譯者：網(wǎng)絡(luò)埋伏紀(jì)事
鏈接：http://www.zcfy.cc/article/2847
原文：https://hackernoon.com/optimising-the-front-end-for-the-browser-f2f51a29c572#.81dkyz4uu

優(yōu)化全都是與速度和滿意度有關(guān)。

從用戶體驗的角度，我們希望前端提供可以快速加載和執(zhí)行的網(wǎng)頁。

而從開發(fā)者體驗的角度，我們希望前端是快速、簡單而規(guī)范的。

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

如果你已經(jīng)花費(fèi)了大量時間來改善你網(wǎng)站的 Google Pagespeed Insights分?jǐn)?shù)，那么這將有助于揭示這一切實際上意味著什么，以及我們必須為優(yōu)化前端所采取的大量策略。

最近我的整個團(tuán)隊有機(jī)會花一些時間加快把我們提出的升級變?yōu)榇a庫，可能是用 React。這確實讓我思考起了我們該如何創(chuàng)建前端。很快，我意識到瀏覽器將是我們的方法中的一個重要因素，同時也是我們知識中的大瓶頸。

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

幸運(yùn)的是，瀏覽器行為的基礎(chǔ)原理是相當(dāng)穩(wěn)定而且文檔齊全的，并且在相當(dāng)長一段時間內(nèi)肯定不會發(fā)生顯著變化。

所以這至少給了我們一個目標(biāo)。

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

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

下面我們來建立一些知識。如下是我們希望瀏覽器要運(yùn)行的一些簡單 HTML：

  
    
    
    
  
  
  
    

      Click the button.
    
    
    Click me
    
    
  

當(dāng)瀏覽器接收到 HTML 時，就會解析它，將其分解為瀏覽器所能理解的詞匯，而這個詞匯由于HTML5 DOM 規(guī)范定義，在所有瀏覽器中是保持一致的。然后瀏覽器通過一系列步驟來構(gòu)造和渲染頁面。如下是一個很高層次的概述：

使用 HTML 創(chuàng)建文檔對象模型（DOM）。

使用 CSS 創(chuàng)建 CSS 對象模型（CSSOM）。

基于 DOM 和 CSSOM 執(zhí)行腳本（Script）。

合并 DOM 和 CSSOM 形成渲染樹（Render Tree）。

使用渲染樹布局（Layout）所有元素的大小和位置。

繪制（Paint）所有元素。

瀏覽器開始從上到下讀取標(biāo)記，并且通過將它分解成節(jié)點(diǎn)，來創(chuàng)建 DOM 。

樣式在頂部，腳本在底部

雖然這個規(guī)則有例外和細(xì)微差別，不過總體思路是盡可能早地加載樣式，盡可能晚地加載腳本。原因是腳本執(zhí)行之前，需要 HTML 和 CSS 解析完成，因此，樣式盡可能的往頂部放，這樣在底部腳本開始編譯和執(zhí)行之前，樣式有足夠的時間完成計算。

下面我們進(jìn)一步研究如何在優(yōu)化的同時做細(xì)微調(diào)整。

最小化和壓縮

這適用于我們提交的所有內(nèi)容，包括 HTML、CSS、JavaScript、圖片和其它資源。

最小化是移除所有多余的字符，包括空格、注釋、多余的分號等等。

壓縮（比如 GZip）是將代碼或者資源中重復(fù)的數(shù)據(jù)替換為一個指向原始實例的指針，大大壓縮下載文件的大小，并且是在客戶端解壓文件。

雙管齊下的話，可以潛在將負(fù)載降低 80% 到 90%。比如：光 bootstrap 就節(jié)省了 87% 的負(fù)載。

可訪問性

雖然可訪問性不會讓頁面的下載變得更快，但是會大大提高殘障人士的滿意度。要確保是給所有人提供的！給元素加上 aria 標(biāo)簽，給圖片提供 alt 文本，以及所有其它好東西。

使用像 WAVE 這樣的工具確認(rèn)在哪些地方可以改善可訪問性。

當(dāng)瀏覽器發(fā)現(xiàn)任何與節(jié)點(diǎn)相關(guān)的樣式時（即外部樣式表、內(nèi)部樣式表或行內(nèi)樣式），就立即停止渲染 DOM ，并用這些節(jié)點(diǎn)來創(chuàng)建 CSSOM。這就是人們稱 CSS 阻塞渲染的原因。這里是不同類型樣式的一些優(yōu)缺點(diǎn)。

//外部樣式


// 內(nèi)部樣式


// 行內(nèi)樣式
Click me

CSSOM 節(jié)點(diǎn)的創(chuàng)建與 DOM 節(jié)點(diǎn)的創(chuàng)建類似，隨后，兩者會被合并。這就是現(xiàn)在它們的樣子：

CSSOM 的構(gòu)建會阻塞頁面的渲染，因此我們想在樹中盡可能早地加載樣式，讓它們盡可能輕便，并且在有效的地方延遲加載它們。

使用 media 屬性

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

桌面是很強(qiáng)大，但是移動設(shè)備不是，所以我們想給移動設(shè)備盡可能最輕的負(fù)載。我們可以假設(shè)先只提供移動端樣式，然后對桌面端樣式放一個媒體條件。雖然這樣做不會阻止桌面端樣式下載，不過會阻止它阻塞頁面加載和使用寶貴的資源。

// 這個 css 在所有情況都會下載，并阻塞頁面的渲染。
// media="all" 是默認(rèn)值，并且與不聲明任何 media 屬性一樣。


// 在移動端，這個 css 會在后臺下載，而且不會中斷頁面加載。


// CSS 中只為打印視圖計算的媒體查詢

延遲加載 CSS

如果我們有一些樣式可以等到首屏有價值的內(nèi)容渲染完成后，再加載和計算，比如出現(xiàn)在首屏以下的，或者頁面變成響應(yīng)式之后不那么重要的東西。我們可以把樣式加載寫在腳本中，用腳本等待頁面加載完成，然后再插入樣式。

  
    
  
  
  
    

      折疊內(nèi)容之上的重要部分。
    
    
    

      折疊內(nèi)容之下。頁面加載之后，向下滾動才會看到的東西。
    
    
    
  

這里有一個如何實現(xiàn)這個的例子，還有另一個例子。

較小的特殊性

鏈在一起的元素越多，自然要傳輸?shù)臄?shù)據(jù)就越多，因而會增大 CSS 文件，這是一個明顯的缺點(diǎn)。不過這樣做還有一個客戶端計算的損耗，即會把樣式計算為較高的特殊性。

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

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

只加載需要的樣式

這聽起來可能有點(diǎn)愚蠢或者裝模作樣，不過如果你已經(jīng)從事前端工作多年的話，就會知道 CSS 的一個最大問題是刪除東西的不可預(yù)測性。設(shè)計的時候它就是被下了不斷增長這樣的詛咒。

要盡可能多削減 CSS ，可以使用類似uncss)包這樣的工具，或者如果想有一個網(wǎng)上的替代品，那就到處找找，還是有挺多選擇的。

然后，瀏覽器會不斷創(chuàng)建 DOM / CSSOM 節(jié)點(diǎn)，直到發(fā)現(xiàn)任何 JavaScript 節(jié)點(diǎn)，即外部或者行內(nèi)的腳本。

// 外部腳本
`

// 內(nèi)部腳本

由于腳本可能需要訪問或操作之前的 HTML 或樣式，我們必須等待它們構(gòu)建完成。

因此瀏覽器必須停止解析節(jié)點(diǎn)，完成創(chuàng)建 CSSOM，執(zhí)行腳本，然后再繼續(xù)。這就是人們稱 JavaScript 阻塞解析器的原因。

瀏覽器有種稱為"預(yù)加載掃描器"的東西，它會掃描 DOM 的腳本，并開始預(yù)加載腳本，不過腳本只會在先前的 CSS 節(jié)點(diǎn)已經(jīng)構(gòu)建完成后，才會依次執(zhí)行。

假如這就是我們的腳本：

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

那么這就是我們的 DOM 和 CSSOM 的效果：

優(yōu)化腳本是我們可以做的最重要的事情之一，同時也是大多數(shù)網(wǎng)站做得最糟糕的事情之一。

異步加載腳本

通過在腳本上使用 async 屬性，可以通知瀏覽器繼續(xù)，用另一個低優(yōu)先級的線程下載這個腳本，而不要阻塞其余頁面的加載。一旦腳本下載完成，就會執(zhí)行。

`

這意味著這段腳本可以隨時執(zhí)行，這就導(dǎo)致了兩個明顯的問題。首先，它可以在頁面加載后執(zhí)行很長時間，所以如果依靠它為用戶體驗做一些事情，那么可能會給用戶一個不是最佳的體驗。其次，如果它剛好在頁面完成加載之前執(zhí)行，我們就沒法預(yù)測它會訪問正確的 DOM/CSSOM 元素，并且可能會中斷執(zhí)行。

async 適用于不影響 DOM 或 CSSOM 的腳本，而且尤其適用于與 HTML 和 CSS 代碼無關(guān)，對用戶體驗無影響的外部腳本，比如分析或者跟蹤腳本。不過如果你發(fā)現(xiàn)了任何好的使用案例，那就用它。

延遲加載腳本

defer 跟 async 非常相似，不會阻塞頁面加載，但會等到 HTML 完成解析后再執(zhí)行，并且會按出現(xiàn)的次序執(zhí)行。

這對于會作用于渲染樹上的腳本來說，確實是一個好的選擇。不過對于加載折疊內(nèi)容之上的頁面，或者需要之前的腳本已經(jīng)運(yùn)行的腳本來說，并不重要。

`

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

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

// 在 DOM 準(zhǔn)備好時調(diào)用，在圖像和其它外部內(nèi)容準(zhǔn)備好之前
document.onload = function () {
};

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

不幸的是 async 和 defer 對于行內(nèi)腳本不起作用，因為只要有行內(nèi)腳本，瀏覽器默認(rèn)就會編譯和執(zhí)行它們。當(dāng)腳本內(nèi)嵌在 HTML 中時，就會立即運(yùn)行，通過在外部資源上使用上述兩個屬性，我們只是把腳本抽取出來，或者延遲把腳本發(fā)布到 DOM/CSSOM。

操作之前克隆節(jié)點(diǎn)

當(dāng)且僅當(dāng)對 DOM 執(zhí)行多次修改時看到了不必要的行為時，就試試這招。

先克隆整個 DOM 節(jié)點(diǎn)，對克隆的節(jié)點(diǎn)做修改，然后用它來替換原始節(jié)點(diǎn)，這樣可能效率更高。因為這樣就避免了多次重畫，降低了 CPU 和內(nèi)存消耗。這樣做還可以避免更改頁面時的抖動和無樣式內(nèi)容的閃爍（Flash of Unstyled Content，F(xiàn)OUC）。

// 通過克隆，高效操作一個節(jié)點(diǎn)

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

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

element.parentNode.replaceChild(elementClone, element);

請注意，克隆的時候并沒有克隆事件監(jiān)聽器。有時這實際上剛好是我們想要的。過去我們已經(jīng)用過這種方法來重置不調(diào)用命名函數(shù)時的事件監(jiān)聽器，而且那時也沒有 jQuery 的 .on() 和 .off() 方法可用。

Preload/Prefetch/Prerender/Preconnect

這些屬性基本上也實現(xiàn)了它們所做的承諾，而且都棒極了。不過，這些屬性都是相當(dāng)新，還沒被瀏覽器普遍支持，也就是說對我們大多數(shù)人來說它們實際上不是真正的競爭者。不過，如果你有空的話，可以看看這里和這里。

一旦所有節(jié)點(diǎn)已被讀取，DOM 和 CSSOM 準(zhǔn)備好合并，瀏覽器就會構(gòu)建渲染樹。如果我們把節(jié)點(diǎn)當(dāng)成單詞，把對象模型當(dāng)成句子，那么渲染樹便是整個頁面?，F(xiàn)在瀏覽器已經(jīng)有了渲染頁面所需的所有東西。

然后我們進(jìn)入布局階段，確定頁面上所有元素的大小和位置。

最終我們進(jìn)入繪制階段，真正地光柵化屏幕上的像素，為用戶繪制頁面。

整個過程通常會在幾秒或者十分之一秒內(nèi)發(fā)生。我們的任務(wù)是讓它做得更快。

如果 JavaScript 事件改變了頁面的某個部分，就會導(dǎo)致渲染樹的重繪，并且迫使我們再次經(jīng)歷布局和繪制?，F(xiàn)在瀏覽器足夠智能，會僅進(jìn)行部分重畫。不過我們不能指望靠這就能高效或者高性能。

話雖如此，不過很顯然 JavaScript 主要是在客戶端基于事件，而且我們想讓它來操作 DOM，所以它就得做到這一點(diǎn)。我們只是必須限制它的不良影響。

至此你已經(jīng)足夠認(rèn)識到要感謝 Tali Garsiel 的演講。這是 2012 年的演講，但是信息依然是真實的。她在此主題上的綜合論文可以在這里讀到。

如果你喜歡迄今為止所讀過的內(nèi)容，但仍然渴望知道更多的底層技術(shù)性的東西，那么所有知識的權(quán)威就是HTML5 規(guī)范。

我們差不多搞定了，不過請和我多待段時間！現(xiàn)在我們來探討為什么需要知道上面的所有知識。

本節(jié)中，我們將理解如何才能高效地把渲染頁面所需的數(shù)據(jù)傳輸給瀏覽器。

當(dāng)瀏覽器請求一個 URL 時，服務(wù)器會響應(yīng)一些 HTML。我們將從超級小的開始，慢慢增加復(fù)雜性。

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

  
    
  
  
  
    

      Button under construction...
    
  

我們需要學(xué)習(xí)一個新術(shù)語，關(guān)鍵渲染路徑（Critical Rendering Path，CRP），就是瀏覽器渲染頁面所需的步數(shù)。如下就是現(xiàn)在我們的 CRP 示意圖看起來的樣子：

瀏覽器發(fā)起一個 GET 請求，在我們頁面（現(xiàn)在還沒有 CSS 及 JavaScript）所需的 1kb HTML 響應(yīng)回來之前，它一直是空閑的。接收到響應(yīng)之后，它就能創(chuàng)建 DOM，并渲染頁面。

三個 CRP 指標(biāo)的第一個是路徑長度。我們想讓這個指標(biāo)盡可能低。

瀏覽器用一次往返來獲取渲染頁面所需的 HTML，而這就是它所需的一切。因此我們的關(guān)鍵路徑長度是 1，很完美。

下面我們上一個檔次，加點(diǎn)內(nèi)部樣式和內(nèi)部 JavaScript。

  
    
    
  
  
  
    Click me
    
    
  

如果我們檢查一下 CRP 示意圖，應(yīng)該能看到有兩點(diǎn)變化。

新增了兩步，創(chuàng)建 CSSOM和執(zhí)行腳本。這是因為我們的 HTML 有內(nèi)部樣式和內(nèi)部腳本需要計算。不過，由于沒有發(fā)起外部請求，關(guān)鍵路徑長度沒變。

但是注意，渲染沒那么快了。而且我們的 HTML 大小增加到了 2kb，所以某些地方還是受了影響。

那就是三個指標(biāo)之二，關(guān)鍵字節(jié)數(shù)出現(xiàn)的地方。這個指標(biāo)用來衡量渲染頁面需要傳送多少字節(jié)數(shù)。并非頁面會下載的所有字節(jié)，而是只是實際渲染頁面，并把它響應(yīng)給用戶所需的字節(jié)。

不用說，我們也想減少這個數(shù)。

如果你認(rèn)為這就不錯了，誰還需要外部資源啊，那就大錯特錯了。雖然這看起來很誘人，但是它在規(guī)模上是不可行的。在現(xiàn)實中，如果我的團(tuán)隊要通過內(nèi)部或者行內(nèi)方式給頁面之一提供所需的一切，頁面就會變得很大。而瀏覽器不是為了處理這樣的負(fù)載而創(chuàng)建的。

看看這篇關(guān)于像 React 推薦的那樣內(nèi)聯(lián)所有樣式時，頁面加載效果的有趣文章。DOM 變大了四倍，掛載花了兩倍的時間，到可以響應(yīng)多花了 50% 的時間。相當(dāng)不能接受。

還要考慮一個事實，就是外部資源是可以被緩存的，因此在回訪頁面，或者訪問用相同資源（比如 my-global.css）的其它頁面時，瀏覽器就用發(fā)起網(wǎng)絡(luò)請求，而是用其緩存的版本，從而為我們贏得更大的勝利。

所以下面我們更進(jìn)一步，對樣式和腳本使用外部資源。注意這里我們有一個外部 CSS 文件、一個外部 JavaScript 文件和一個外部 asyncJavaScript 文件。

  
    
    
    `  // async
  
  
  
    Click me
    
    `
  

如下是現(xiàn)在 CRP 示意圖看起來的樣子：

瀏覽器得到頁面，創(chuàng)建 DOM，一發(fā)現(xiàn)任何外部資源，預(yù)加載掃描器就開始介入。繼續(xù)，開始下載 HTML 中所找到的所有外部資源。CSS 和 JavaScript 有較高的優(yōu)先級，其它資源次之。

它挑出我們的 styles.css 和 app.js，開辟另一條關(guān)鍵路徑去獲取它們。不過不會挑出 analytics.js，因為我們給它加了 async屬性。瀏覽器依然會用另一個低優(yōu)先級的線程下載它，不過因為它不會阻塞頁面渲染，所以也與關(guān)鍵路徑無關(guān)。這正是 Google 自己的優(yōu)化算法對網(wǎng)站進(jìn)行排名的方式。

最后，是我們最后一個 CRP 指標(biāo)，關(guān)鍵文件，也就是瀏覽器渲染頁面需要下載的文件總數(shù)。在例三中，HTML 文件本身、CSS 和 JavaScript 文件都是關(guān)鍵文件。async 的腳本不算。當(dāng)然，文件越少越好。

現(xiàn)在你可能會認(rèn)為這肯定就是最長的關(guān)鍵路徑吧？我的意思是說要渲染頁面，我們只需要下載 HTML、CSS 和 JavaScript，而且只需要兩個往返就可以搞定。

不過，生活依然沒那么簡單。拜 HTTP1 協(xié)議所賜，我們的瀏覽器一次從一個域名并發(fā)下載的最大文件數(shù)是有限制的。范圍從 2（很老的瀏覽器）到 10（Edge）或者 6（Chrome）。

你可以從這里查看用戶瀏覽器請求你的域名時的最大并發(fā)文件數(shù)。

你可以并且應(yīng)該通過把一些資源放在影子域名上，來繞開這個限制，從而最大限度地提高優(yōu)化潛力。

警告：不要把關(guān)鍵的 CSS 放到根域名之外的其他地方，DNS 查找和延遲都會抵消這樣做時所帶來的任何可能的好處。

如果網(wǎng)站是 HTTP2，并且用戶的瀏覽器也是兼容的，那么你就可以完全避開這個限制。不過，這種好事并不常見。

可以在這里測試你網(wǎng)站的 HTTP2。

另一個敵人逼近了！

任何一次往返可傳輸?shù)淖畲髷?shù)據(jù)量是 14kb，對于包括所有 HTML、CSS 和腳本在內(nèi)的所有網(wǎng)絡(luò)請求都是如此。這來自于防止網(wǎng)絡(luò)擁堵和丟包的一個 TCP 規(guī)范。

如果一次請求中，我們的 HTML 或者任何累積的資源超過了 14kb，那么就需要多做一次往返來獲取它們。所以，是的，這些大的資源確實會給 CRP 添加很多路徑。

現(xiàn)在將我們的大網(wǎng)頁傾巢而出。

  
    
         // 14kb
           // 2kb
      // 2kb
      // 2kb
    `  // 2kb
  
  
  
    Click me
    
    ` // 2kb
    ` // 2kb
    `  // 2kb
  

現(xiàn)在我知道一個按鈕就有很多 CSS 和 JavaScript，但是它是一個很重要的按鈕，它對我們來說意義重大。所以就不要評判，好嗎？

整個頁面被很好地最小化和壓縮到 2kb，遠(yuǎn)低于 14kb 的限制，所以我們又回到正好一次 CRP 往返了，而瀏覽器開始忠實地用一個關(guān)鍵文件，即我們的 HTML，來創(chuàng)建 DOM。

CRP 指標(biāo)：長度 1，文件數(shù) 1，字節(jié)數(shù) 2kb

瀏覽器發(fā)現(xiàn)了一個 CSS 文件，而預(yù)加載掃描器識別出所有外部資源（CSS 和 JavaScript），并發(fā)送一個請求開始下載它們。但是等一等，第一個 CSS 文件是 14kb，超出了一次往返的最大負(fù)載，所以它本身就是一個 CRP。

CRP 指標(biāo)：長度 2，文件數(shù) 2，字節(jié)數(shù) 16kb

然后它繼續(xù)下載資源。余下的資源低于 14kb，所以可以在一次往返中搞定。不過由于總共有 7 個資源，而且我們的網(wǎng)站還沒啟用 HTTP2，而且用的是 Chrome，所以這次往返只能下載 6 個文件。

CRP 指標(biāo)：長度 3，文件數(shù) 8，字節(jié)數(shù) 28kb

現(xiàn)在我們終于可以下載完最終文件，并開始渲染 DOM了。

CRP 指標(biāo)：長度 4，文件數(shù) 9，字節(jié)數(shù) 30kb

我們的 CRP 總共有 30kb 的關(guān)鍵資源，在 9 個關(guān)鍵文件和 4 個關(guān)鍵路徑中。有了這個信息，以及一些關(guān)于連接中延遲的知識，我們實際上就可以開始對給定用戶的頁面性能進(jìn)行真正準(zhǔn)確的估計了。

Pagespeed Insights

使用Insights 來確定性能問題。Chrome DevTools 中還有個 audit標(biāo)簽。

善用 Chrome 開發(fā)者工具

DevTools 如此驚人。我們?yōu)樗鄮懸徽緯?，不過這里已經(jīng)有不少資源可以幫助你。這里)有一篇開始解釋網(wǎng)絡(luò)資源的文章值得一讀。

在好的環(huán)境中開發(fā)，在糟糕的環(huán)境中測試

你當(dāng)然想在你的 1tb SSD、32G 內(nèi)存的 Macbook Pro 上開發(fā)，不過對于性能測試，應(yīng)該轉(zhuǎn)到 Chrome 中的 network 標(biāo)簽下，模擬低帶寬、節(jié)流 CPU 連接，從而真正得到一些有用的信息。

合并資源/文件

在上面的 CRP 示意圖中，我省略了一些你不需要知道的東西。不過基本上，每接收到一個外部 CSS 和 JavaScript 文件后，瀏覽器都會構(gòu)建 CSSOM，并執(zhí)行腳本。所以，盡管你可以在一次往返中傳遞幾個文件，它們每個也都會讓瀏覽器浪費(fèi)寶貴的時間和資源，所以最好還是將文件合并在一起，消除不必要的加載。

在 head 部分為首屏設(shè)置內(nèi)部樣式

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

但是有一個很好的觀點(diǎn)是對首屏關(guān)鍵內(nèi)容設(shè)置內(nèi)部樣式，可以避免在首次有意義的渲染時獲取資源。

最小化/壓縮圖片

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

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

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

異步加載字體

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

是否真正需要 JavaScript/CSS?

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

CDN

內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）可用于為用戶提供物理上更近和更低延遲的位置，從而降低加載時間。

*

現(xiàn)在你開心慘了，已經(jīng)知道了足夠多的東西，可以從這里走出去，自己探索有關(guān)這個主題的更多東西了。我推薦參加這個免費(fèi)的 Udacity 課程，并且閱讀Google 自己的 優(yōu)化文檔。

如果你渴望更底層的知識，那么這本免費(fèi)電子書《高性能瀏覽器網(wǎng)絡(luò)》是個開始的好地方。

關(guān)鍵渲染路徑是最重要的，它讓網(wǎng)站優(yōu)化有規(guī)律可循。需要關(guān)注的 3 個指標(biāo)是：

1 — 關(guān)鍵字節(jié)數(shù)

2 — 關(guān)鍵文件數(shù)

3 — 關(guān)鍵路徑數(shù)

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

最佳實踐的應(yīng)用將伴隨著良好的 DOM 結(jié)構(gòu)、網(wǎng)絡(luò)優(yōu)化和可用于減少 CRP 指標(biāo)的各種策略的結(jié)合。讓用戶更高興，讓 Google 的搜索引擎更高興。

在任何企業(yè)級網(wǎng)站中，這將是一項艱巨的任務(wù)，但是你必須遲早做到這一點(diǎn)，所以不要再承擔(dān)更多的技術(shù)性債務(wù)，并開始投資于堅實的性能優(yōu)化策略。

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

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

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