教你讀懂網絡請求的瀑布圖

本文題目來源於 阮一峯大神的微博

這是原文

咱們目前都知道, 一個網頁的訪問速度對於SEO和用戶體驗來講很是的重要. 速度快的網站會得到更高的搜索引擎排名, 用戶也能瀏覽其更多的網頁;簡單說來,聰明的SEO不只僅優化其網站內容,同時也要考慮如何提高網站的性能.

正如咱們在以前這篇文章所討論的, 你可使用WebPageTest 這個免費的工具來對你的網站性能進行優化. WebPageTest輸出給你的最有用的內容之一, 是一個叫作瀑布圖的東西. 瀑布圖展示了瀏覽器爲渲染網頁而加載的全部的資源, 包括加載的順序和每一個資源的加載時間.  分析這些資源是如何加載的, 能夠幫助你瞭解到底是什麼緣由拖慢了你的網頁以從而採起對應的措施來提高網頁速度.

瀑布圖很像Excel表格: 概念很清楚並且用處很大, 可是不少人並無將它充分的利用起來. 本文中, 咱們將介紹SEO人員如何利用工具(好比WebPageTest)生成的瀑布圖來提高網站的性能和用戶體驗.

如何閱讀瀑布圖

若是你還不知道如何生成瀑布圖, 用 WebPageTest 給你的網站跑個測試就生成了. 測試結果生成之後, 點擊第一個結果來看瀑布圖. 下邊是一個簡單的瀑布圖表(點擊看大圖).

正如上邊提到的, 瀑布圖是一個級聯圖, 展現了瀏覽器如何加載資源並渲染成網頁. 圖中的每一行都是一次單獨的瀏覽器請求. 這個圖越高, 說明加載網頁過程當中所發的請求越多. 每一行的寬度, 表明瀏覽器發出請求並下載該資源的過程當中所耗費的時間.

每一行都是一個彩色條, 從彩色條能夠看出加載一個資源的過程當中,各個階段消耗的時間,好比:

爲了把一個請求的各階段的時間縮短, 首先須要弄懂每一階段的含義. 下面簡單介紹一下:

• 
  DNS Lookup [深綠色] - 在瀏覽器和服務器進行通訊以前, 必須通過DNS查詢, 將域名轉換成IP地址. 在這個階段, 你能夠處理的東西不多. 但幸運的是, 並不是全部的請求都須要通過這一階段.

• Initial Connection [橙色] - 在瀏覽器發送請求以前, 必須創建TCP鏈接. 這個過程僅僅發生在瀑布圖中的開頭幾行, 不然這就是個性能問題(後邊細說).

• SSL/TLS Negotiation [紫色] - 若是你的頁面是經過SSL/TLS這類安全協議加載資源, 這段時間就是瀏覽器創建安全鏈接的過程. 目前Google將HTTPS做爲其 搜索排名因素 之一, SSL/TLS 協商的使用變得愈來愈廣泛了.

• Time To First Byte (TTFB) [綠色] - TTFB 是瀏覽器請求發送到服務器的時間+服務器處理請求時間+響應報文的第一字節到達瀏覽器的時間. 咱們用這個指標來判斷你的web服務器是否性能不夠, 或者說你是否須要使用CDN.

• Downloading (藍色) - 這是瀏覽器用來下載資源所用的時間. 這段時間越長, 說明資源越大. 理想狀況下, 你能夠經過控制資源的大小來控制這段時間的長度.

瀑布圖上還有一些其餘的線. 垂直的綠色線表明渲染開始.在咱們上一篇文章上一篇文章討論過, 在渲染開始以前, 用戶看到的都是一個空白的屏幕. 若是渲染開始的時間很長, 用戶會以爲你的網站速度很慢, 反應遲鈍. 瀑布圖上還有一些其餘的數據點, 好比"Content Download", 但這些是更高級的話題, 超出了本文所討論的範圍.

根據瀑布圖進行性能優化

那麼咱們如何是一個web頁面加載的更快而且創造更好的用戶體驗呢? 瀑布圖提供是三個直觀的玩意兒來協助咱們達成這一目標:

1. 首先, 減小全部資源的加載時間. 亦即減少瀑布圖的寬度. 瀑布圖越窄, 網站的訪問速度越快.

2. 其次, 減小請求數量 也就是下降瀑布圖的高度. 瀑布圖越矮越好.

3. 最後, 經過優化資源請求順序來加快渲染時間. 從圖上看, 就是將綠色的"開始渲染"線向左移. 這條線向左移動的越遠越好.

我們把每一條都來詳細的解說一下.

把瀑布圖變窄

能夠經過下降每個資源的下載時間達到把瀑布圖變窄. 瀑布圖的每一行使用不一樣的顏色表明獲取資源的不一樣階段. 不一樣的顏色使用不一樣的優化手段來提高網頁的總體速度.哪一種顏色出現的多, 就用對應的方式下降那個階段消耗的時間.

• 橙色出現的比較多? 橙色表明你的網站初始化TCP鏈接的時間. 對於同一個域名,只有最開始的2到6個請求須要創建TCP鏈接, 那以後, 已存在的鏈接會被複用. 若是你在圖上看到不少的橙色, 說明你的網站沒有使用持久鏈接(長鏈接). 下面這張圖就是沒有使用長鏈接的網站. 能夠看到, 每一行的請求開始部分都有橙色.一旦使用了長鏈接, 每一行的請求寬度都會縮短一半. 由於瀏覽器不用爲每次請求都創建新的鏈接了.

• 紫色的部分很長嗎? 紫色是用在SSL/TLS協商的時間. 若是你看到同一個網站一次又一次的出現紫色, 這說明你沒有優化TLS. 在下面這個截圖中, 能夠看見2個HTTPS請求. 其中一個服務器作了優化, 而另外一個把TLS配置的不好:關於優化TLS的性能, 請看以前這個文章.

• 有長條的藍色嗎? 藍色是服務端響應以後, 瀏覽器下載資源所用的時間.若是一行有很長的藍色條, 八成是說明這個資源很是的大. 提高網站速度的一個妙招就是簡單的把須要傳到客戶端的數據量減小. 若是你看到一大堆藍條, 檢討一下"怎麼數據量這麼大?" 你還能夠經過 HTTP compression, minification, 或者 image optimization 來減少數據量. 舉個例子, 在下圖中咱們看到, 下載PNG圖片用了很長時間, 由於藍條特別長.深刻研究一下, 咱們發現這個圖片有1.1MB那麼大! 這說明設計師在PS以後忘了把圖片導出成合適的尺寸. 用圖片優化技術就能縮短這一行而且使總體頁面加載的更快.

• 有不少的綠條? 綠條是等待獲取內容的時間. 你可能常常看到綠條(等待時間)有80或者90毫秒, 而資源下載時間僅用了1毫秒. 減少綠條的最好方法就是把你的靜態資源, 好比圖片, 放到離你用戶比較近的CDN上去.更多關於這個的話題, 之後再說.

下降瀑布圖的高度

若是瀑布圖很高, 說明瀏覽器加載頁面須要發不少的請求. 減小請求的最佳方法就是看看你頁面中包含的全部內容而後想一想這個內容是不是必需的.好比:

• 看到一大堆CSS和JS文件了沒? 我不騙你,下面這個圖是一個AOL網站的瀑布圖的一部分, 網頁中請求了48個CSS文件! 若是你的網站請求了不少獨立的CSS或JS文件, 你須要用CMS插件或者做爲構建過程當中的一步把它們合併. 合併文件能夠減小請求數, 提高網頁速度.
  

• 看到不少"小的"(不到2kb)JS文件和CSS文件了嗎? 考慮一下用<script>, <code>或者<style>標籤直接把這些內容內聯到html文件中.(這個連接加的太蛋疼了, 不知道怎麼翻譯) Consider including the contents of those files directly in your HTML via inline <script>, <code>, or <style> tags.

• 看到不少302重定向嗎? 重定向在圖中是高亮的黃色行. 表明你頁面上的連接常常過時或者出錯. 這些過時或者出錯, 產生了不必的重定向, 這玩意兒沒什麼用, 只能把你的瀑布圖變高. 把那些連接替換成新的URL吧.

提高渲染時間

再說一遍, 開始渲染時間表明用戶首次從空白頁面到看到加載出東西的時間.

你的渲染開始時間如何? 若是超過1.5秒, 就得優化了. 說到優化, 先看一下開始渲染線(垂直的綠線)的"上邊和左邊"的全部資源. 這些東西就是爲了提高渲染時間所要優化的東西.

一些提示:

• 看到加載JS庫了嗎? 引入JS會阻塞頁面的渲染, 若是可能的話, 把這些JS放到頁面的下邊.

• 看到不少單獨的CSS請求嗎? 瀏覽器在渲染頁面以前會等待全部CSS下載完成. 能不能合併這些CSS或者把一些CSS內聯到HTML中?

• 看到額外的字體了嗎? 當使用了額外的字體, 瀏覽器不會繪製任何東西直到下載了 那個字體. 可能的話, 要儘可能避免使用額外加載的字體. 若是避免不了, 確認去掉了任何爲了加載字體而作的沒什麼用的302跳轉, 或者(更好的狀況) 把那個字體copy一份, 放在你本身的服務器上.

舉個例子, 這是一個瀑布圖的開頭部分:

綠色的開始渲染線剛剛超過一秒一點兒, 這很不錯. 然而看線的左側, 你會看到一些能夠優化的地方. 首先, 有多個JS文件. 除了JQuery, 其餘的大概均可以延遲加載. 一樣, 有不少CSS文件. 這均可以合併. 這些優化能提高開始渲染時間.

你可能須要和你的設計師和開發人員一塊兒合做來作這些優化. 但優化結果很划得來. 沒人喜歡看一個空白的屏幕!

其餘因素

個人服務器夠快嗎? 咱們知道, 第一字節返回時間是搜索排名的一個因素. 幸虧瀑布圖能告訴你這個數值. 簡單看一下瀑布圖的第一行. 這個展現了瀏覽器如何下載基本HTML頁面的時間信息. 看看TTFB結果, 若是超過500毫秒, 你的服務器可能不夠給力或者未經優化. 找你的託管服務商聊聊, 提高一下服務器的能力.  下邊這個示例的瀑布圖展現了一個須要將近10秒才能響應的服務器! 真是慢到家了!

我須要弄個CDN嗎?

延遲多是網站請求的一個大資源形成的, 須要解決的問題是你的服務器和瀏覽者的地理距離問題.以前討論過, 延遲受距離和光速影響; 僅僅靠一個高速網絡鏈接解決不了問題. 內容分發網絡(CDNs) 經過把你的靜態資源(圖片, CSS, JS等等)拷貝並存放到全世界的各個服務器上來下降瀏覽網頁的延遲.

瀑布圖揭示了網絡延遲對你站點的速度的影響, 以及你是否須要使用CDN. 看看瀏覽器請求靜態資源時候的TTFB就知道了. TTFB是由請求發過到服務器的時間, 服務器處理請求時間, 響應中的第一字節返回來的時間組成的. 對於靜態資源來講, 服務器對請求不須要作任何的處理, 因此靜態資源的TTFB就是請求和響應在瀏覽器和服務器之間的網絡上走一個來回的時間. 若是這個時間很長, 那就說明內容(譯者按: 原文是content, 我感受就是服務器離用戶太遠吧)離你的用戶距離太遠.

判斷是否須要CDN, 首先要知道服務器的位置. 而後用WebPageTest在離你服務器很遠的地方跑一個測試. 若是你的服務器在美國, 那就在亞洲或者歐洲作測試. 如今, 找幾條到你服務器的圖片或者CSS請求, 而後看看TTFB結果. 若是靜態資源的TTFB超過了150毫秒, 你該考慮用CDN了. 商業的來講, 你可能看下AkamaiIf的企業級功能.  至於便宜點兒的, 看這個 CloudFlare which offers free CDN services.

Summary

信不信由你, 咱們談的僅僅是經過瀑布圖作性能優化的一些皮毛. 可是這對於看懂瀑布圖而且查找網站最基本的性能損耗點來講, 足夠用了.

優化內容, 使每一個請求變快, 瀑布圖就會變窄.減小不必的請求, 瀑布圖就會變矮. 最後, 優化開始渲染以前的全部內容, 是你的用戶在最短期內看到網頁從空白到加載出內容.

若是還不知道從哪下手, 看看這個 Zoompf's Free Performance Report 來分析你的網站並優先用那些大大改善網站性能和瀑布圖指標的手段.

About Zoompf — Zoompf was founded by Billy Hoffman, a well recognized expert in the field of the web application development technologies and web security. Billy served as a research director for leading web app security software firm SPI Dynamics (acquired by Hewlett-Packard in August 2007). Following the acquisition, Billy served as Director for Hewlett-Packard’s Web Security Research Group. Billy’s research focused on Web 2.0 technology and security threats, automated discovery of web application vulnerabilities, and web crawling technologies. After HP, Billy went on to start Zoompf, a technology platform for analyzing the root causes of slow website performance.