建站
咨詢
售后
建站咨詢
新聞中心
我問你：“當你從搜索引擎的結果頁面選擇打開一條搜索結果時，你覺得多長時間之后，如果頁面還處于白屏或者沒有加載到關鍵信息，你會選擇關掉這個窗口?”
為淮北等地區(qū)用戶提供了全套網(wǎng)頁設計制作服務，及淮北網(wǎng)站建設行業(yè)解決方案。主營業(yè)務為成都網(wǎng)站設計、成都做網(wǎng)站、淮北網(wǎng)站設計，以傳統(tǒng)方式定制建設網(wǎng)站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
《Designing for Performance》的作者 Lara Swanson 在2014年寫過一篇文章《Web性能即用戶體驗》，她在文中提到“網(wǎng)站頁面的快速加載，能夠建立用戶對網(wǎng)站的信任，增加回訪率，大部分的用戶其實都期待頁面能夠在2秒內加載完成，而當超過3秒以后，就會有接近40%的用戶離開你的網(wǎng)站”。
Google和亞馬遜的研究表明，Google頁面加載的時間從0.4秒提升到0.9秒導致丟失了20%流量和廣告收入，對于亞馬遜，頁面加載時間每增加100毫秒就意味著1%的銷售額損失。可見，頁面的加載速度對于用戶可能的下一步操作是多么的舉足輕重。
想一想，如果你希望你的網(wǎng)站在一秒鐘之內呈現(xiàn)用戶想看的關鍵信息，有哪些可行的手段?Minify，壓縮，雪碧圖等等。
Google的Web性能工程師 Ilya Grigorik 會告訴你，你只需要理解瀏覽器的關鍵渲染路徑。
頁面性能可能是一個感性的東西
頁面的性能，看似是一個理性和量化的概念，實則也來自于用戶的感知，主觀的評價，是一個偏感性的東西。
(參考自Google關鍵渲染路徑)
如果頁面可以做到優(yōu)先顯示與用戶操作有關的內容，就可以讓用戶更快速的感知到操作得到響應，這個過程叫做“優(yōu)化關鍵渲染路徑”。
什么是關鍵渲染路徑
我記得，有一個非常經(jīng)典的面試題叫做：《當瀏覽器地址欄輸入URL并回車后，發(fā)生了什么?》。
關鍵渲染路徑就是描述瀏覽器從收到 HTML、CSS 和 JavaScript 字節(jié)開始，到如何使用HTML、CSS 和 JavaScript 在屏幕上渲染像素的中間過程。
如果我們能夠優(yōu)化這條路徑，就能讓頁面更快速的展示內容，給用戶更好的體驗。
全景圖
我們先嘗試站在高處，看一眼關鍵渲染路徑的全景圖，這樣能夠快速的領略一個大致輪廓和一些關鍵概念。
文檔對象模型 (DOM)
DOM概念之于Web開發(fā)人員再熟悉不過了，當瀏覽器發(fā)出請求并接收到HTML文檔后，它會有這樣一個流程來構建DOM：字節(jié) → 字符 → 令牌 → 節(jié)點 → 對象模型。
以下面這段代碼為例：
Critical Path Hello web performance students!
瀏覽器接收到HTML請求的返回結果，根據(jù)預定的流程解析HTML，文檔中的“開標簽”，比如，等會轉換成一個令牌(Token)，然后令牌轉換成節(jié)點對象(Node)。
這個令牌解析并轉換為節(jié)點對象的過程，也是每個節(jié)點建立關系(樹形結構)的過程。例如：head的令牌出現(xiàn)在html令牌之后，但其閉標簽出現(xiàn)在html閉標簽之前，這就意味著head是html的子節(jié)點，以此類推，建立節(jié)點的父子關系。
這個過程在瀏覽器中，叫做“Parse HTML”。
CSS 對象模型 (CSSOM)
當DOM捕獲了頁面的內容，我們還需要知道頁面如何展示這些內容，所以需要構建CSS 對象模型(CSSOM)。
瀏覽器解析DOM，遇到了link標簽，發(fā)現(xiàn)它引用了一個外部樣式資源：style.css，于是瀏覽器會向外部請求樣式資源，然后進行后續(xù)的DOM構建工作。
CSS 被視為阻塞渲染的資源，這意味著瀏覽器將不會渲染任何已處理的內容，直至 CSSOM 構建完畢。
CSSOM有著一個和DOM構建相似的流程：字節(jié) → 字符 → 令牌 → 節(jié)點 → CSS對象模型。
以下面的CSS樣式為例，它會根據(jù)具體解析規(guī)則，將CSS文檔轉換成下面的樹形結構：
- body { font-size: 16px }
- p { font-weight: bold }
- span { color: red }
- p span { display: none }
- img { float: right }
這種樹形結構讓CSS有層級繼承關系，子節(jié)點會繼承父節(jié)點的樣式。
前面談到CSS會阻塞瀏覽器的渲染過程，因為渲染樹的構建同時需要DOM和CSSOM，所以當瀏覽器請求的style.css返回之后，瀏覽器會開始解析樣式表，并重新計算樣式(Recalculate Style)，將CSS轉換成CSSOM，然后進行后續(xù)的操作。
值得注意的是，CSSOM運算是一個非常復雜的過程，性能消耗會比較大，所以你會常常聽到“老人們”說寫樣式“盡量使用class和id，保證層級扁平，減少過度層疊”，而且越是通用的CSS樣式，執(zhí)行速度越快，越是具體(選擇器)的CSS樣式，則執(zhí)行速度越慢。
DOM + CSSOM = 渲染樹
渲染樹和DOM樹不同，它只會捕獲一些頁面上可見的元素，比如，Header或display:none的元素不會放在渲染樹中。
渲染樹的構建會從DOM的根節(jié)點開始遍歷，對于不可見節(jié)點會忽略，然后在CSSOM中找到每個對應節(jié)點的樣式規(guī)則并應用，最后輸出的渲染樹會包含所有的可見內容和樣式信息，如下圖：
布局和繪制
有了渲染樹，瀏覽器會進入布局和繪制階段。
布局就是弄清每個對象在頁面視窗(Viewport)上的確切大小和位置，它的輸出是一個“盒模型”，里面準確的捕獲每一個元素在頁面視窗中的位置和尺寸。
在布局工作完成之后，瀏覽器會開始繪制，將渲染樹轉換成屏幕上的像素，這樣，我們就能在瀏覽器中看到頁面的內容。
短暫回顧一下“關鍵渲染路徑”的步驟
- 處理 HTML 標記并構建 DOM 樹
- 處理 CSS 標記并構建 CSSOM 樹
- 將 DOM 與 CSSOM 合并成一個渲染樹
- 根據(jù)渲染樹來布局
- 將各個節(jié)點繪制到屏幕上
當DOM或者CSSOM發(fā)生變化的時候，瀏覽器就需要再次執(zhí)行一次上面的步驟。
JavaScript
到目前為止，我們還沒涉及到JavaScript，但它在整個關鍵渲染路徑中扮演著非常重要的角色，就如全景圖中畫的那樣，我們從一段簡單的代碼開始：
Hello web performance students!
一個大家都知道的重要事實是：腳本在文檔的何處插入，就在何處執(zhí)行。
當HTML解析過程中遇到一個script標記時，它會暫停DOM構建，將控制權移交給JavaScript引擎，等JavaScript引擎運行完畢，瀏覽器再從中斷的地方恢復DOM構建。也就是說，執(zhí)行內聯(lián)的JavaScript會阻塞頁面的首次渲染。
現(xiàn)在我們假設，這段JavaScript是外部資源。
Hello web performance students!
則瀏覽器的渲染會阻塞直到write.js的請求返回后，并執(zhí)行JavaScript后，繼續(xù)。
需要注意的是，在網(wǎng)頁中引入JavaScript腳本有一個微妙事實，就是JavaScript不僅可以讀取和修改DOM屬性，還可以讀取和修改CSSOM屬性。
前面我們提到CSS是阻塞渲染的資源，當它和JavaScript一起出現(xiàn)在頁面上時，會發(fā)生這樣的事情：
Critical Path: Script Hello students!
在瀏覽器解析HTML構建DOM過程中，發(fā)現(xiàn)了link標簽，于是發(fā)出請求獲取style.css，然后繼續(xù)構建DOM，此時，它發(fā)現(xiàn)script標簽，由于JavaScript可能會訪問樣式屬性，所以它會阻止JavaScript的執(zhí)行直到styles.css返回并完成CSSOM構建，然后執(zhí)行這一段JavaScript代碼，再繼續(xù)后面DOM的構建和相關渲染操作。
于是styles.css的請求不僅阻塞后面的渲染，還阻塞了DOM的構建。
如果將這段JavaScript作為外部資源，就是一個比較典型的頁面結構：
Critical Path Render Hello web performance
JavaScript和CSS資源請求是并行的，但仍然需要等到CSSOM構建完成之后，JavaScript才可以執(zhí)行，然后在進行后面的渲染工作。于是，當 DOM、CSSOM 和 JavaScript 執(zhí)行之間有大量的依賴關系時，就很可能導致瀏覽器在處理及渲染網(wǎng)頁時出現(xiàn)延遲。
優(yōu)化策略
我們花了大量的篇幅來理解瀏覽器的渲染過程，理解DOM，CSSOM，渲染樹，瀏覽器繪制，分析HTML，CSS和JS在渲染過程中的關系，我相信你已然受益匪淺，現(xiàn)在，我們來運用這些知識加速你的網(wǎng)站。
第一步，分析你的網(wǎng)站渲染狀況
我們以Google為例，通過Chrome的Performance工具查看頁面渲染情況，如下圖，你應該可以清晰的看到圖中有四條豎線，他們分別是什么含義呢?
(Google主頁的性能分析情況)
- 綠色豎線，代表First Paint，即瀏覽器開始進行像素的繪制
- 黃色豎線，代表First Meaningful Paint(首次有效繪制)用戶可以開始看到部分內容，但繪制仍在繼續(xù)
- 藍色豎線，代表大家比較熟悉的DOMContentLoaded
- 紅色豎線，代表load，頁面加載完成
優(yōu)秀的網(wǎng)站都能夠把“首次有效渲染”做到1秒之內完成，這樣能夠讓用戶更快的看到所請求的頁面得到響應。如果你的網(wǎng)站“首次有效渲染”超過1秒，那么就非常有必要重新分析一下網(wǎng)站的關鍵渲染路徑是否合理。
第二步，分析關鍵渲染路徑
在關鍵渲染路徑中，我們通常要關注三個點：
- 頁面首次渲染需要的關鍵資源數(shù)量
- 關鍵資源的大小
- 關鍵渲染路徑的往返次數(shù)(Roundtrip)
我們的策略也非常簡單，就是減少關鍵資源數(shù)量，降低資源大小，減少關鍵路徑的往返次數(shù)。
關鍵渲染的資源一般是阻止屏幕首次渲染HTML，CSS和JavaScript，所以最重要也是最難的部分的是你需要根據(jù)自己網(wǎng)站的實際情況分析，哪些是頁面繪制的所必須的，哪些是無關的。
第三步，根據(jù)分析采取優(yōu)化手段
(1) 減少關鍵資源的大小
我們首先從最簡單也是最直接的減少關鍵資源的大小開始：
對于所有的資源(HTML，JavaScript，CSS，Image等)，你都應該用上三大絕招：Minify，Compression和Cache，這里不過多的贅述里面的細節(jié)。
這一點對于HTML來說，非常關鍵，HTML作為渲染的關鍵資源，消除或者延遲加載肯定不太可能(這里指的是非局部渲染的關鍵HTML)，能夠做到是消除無用代碼(比如：注釋)和最小化代碼(Minify)以及動態(tài)局部渲染等。
(Google對頁面的HTML進行了壓縮)
(2) 延遲JavaScript非阻塞資源加載
JavaScript和CSS都是阻塞渲染的資源，對于已經(jīng)鑒別出的對于首次渲染沒有起到關鍵作用的代碼，我們首先想到的是要延遲它的加載，讓它脫離關鍵渲染路徑。
首先，對于阻塞渲染的JavaScript，應該將它放置在頁面body的底部，為什么呢?
JavaScript可以查詢和操作DOM和CSSOM，正如前面介紹的，HTML解析過程中構建DOM，當遇到JavaScript就停止DOM構建執(zhí)行JavaScript，如果被執(zhí)行的JavaScript是放置在head附近，那么很可能要被操作或者查詢的DOM還沒有構建到DOM當中。
而對于，非阻塞渲染的JavaScript，我們應該采用異步的方式加載，如下：