網站頁面的打開速度，將會影響網站收錄、網站排名，相信這點長春SEO站長們都知道，那麼對於本身的站點如何判斷訪問加載的速度是快仍是慢那？今天長春SEO站長就和你們說說一款很是實用的網頁測速工具，webpagestest 你們經過這款工具，就能夠對於本身網頁的內容進行詳細的測試了。javascript
WebPagetest的核心是用於測量和分析網頁的性能。有不少選項，看着很嚇人，但其實作快速測試是很簡單的。 本指南將引導你提交測試和結果解釋。css
1、運行性能測試(Running a Performance Test)
1.1 輸入網頁網址(Enter The Page URL)html
你須要作的第一件事是決定一個頁面來測試。大多數人從他們的網站的主頁開始(但不要忽視人們訪問的其餘頁面)。肯定要測試的頁面後，轉到WebPagetest併爲其指定要測試的頁面的URL：
java
1.2 選擇位置(Select a Location)web
接下來，應該決定從哪裏運行測試。WebPagetest具備位於世界各地的測試機器，你應該從接近用戶訪問的位置進行測試，從列表中選擇一個位置，或者單擊Select from Map按鈕，從地圖視圖中選擇一個位置(只需單擊氣球，而後肯定)。若是將指針放在氣泡上，它們將顯示一條消息，提示位置信息：後端
1.3 選擇瀏覽器(Select a Browser)瀏覽器
最後，須要決定使用什麼瀏覽器進行測試。不一樣的位置支持不一樣的瀏覽器，若是給定的位置沒有正在尋找的瀏覽器，能夠嘗試不一樣的位置。 Dulles，VA USA位置支持WebPagetest工做的全部瀏覽器(IE 6,7,8和9)。如今忽略「dynaTrace」瀏覽器，這些用於更高級的分析。咱們一般建議使用IE7進行初始測試，由於它幾乎是最糟糕的狀況，而且更容易看到不少問題，因此若是你不知道什麼瀏覽器，開始只需使用IE7。緩存
1.4 提交測試(Submit the Test)性能優化
一切配置完成後，點擊START TEST按鈕，請求將發送到測試位置進行測試。測試可能須要一段時間才能運行，具體取決於有多少次測試(在測試以前至少有一分鐘的測試時間，可是它的時間甚至更長)。一旦測試完成，你將獲得結果。服務器
2、解釋結果(Interpreting the Results)
第一次看到結果信息可能有點嚇人，信息量有點大，但首先能夠先查看一些關鍵信息。
2.1 優化等級(Optimization Grades)
在結果頁面的頂部是一組最關鍵的性能優化等級。涵蓋了適用於全部網站的基本優化，任何不是A或B的都須要進行進一步的優化。
字母等級 佔比
A 90%+
B 80% ~ 89%
C 70% ~ 79%
D 60% ~ 69%
F 0% ~ 59%
2.1.1 阻塞時間(First Byte Time)
首字節時間是指瀏覽器收到HTML內容的第一個字節時間，包括DNS查找、TCP鏈接、SSL協商(若是是HTTPS請求)和TTFB(Time To First Byte)。
關於First Byte Time和TTFB的區別在Metrics一節中作了簡單分析。
預期首字節 = RTT * 3 + SSL
比值 = 100 - (實際觀測首字節 - 預期首字節) / 10
其中RTT的指往返通訊時間。更多網絡術語能夠參考整理的網絡協議
2.1.2 長鏈接已啓動(Keep-alive Enabled)
請求網頁上的內容(圖像、JavaScript、CSS、Flash等)須要與Web服務器創建鏈接。每次都從新鏈接會耗費一些時間，因此最好複用鏈接，keep-alive實現了這個方法。默認狀況下，在配置中已啓用，並且是HTTP 1.1標準的一部分，但有時它們將被破壞(多是無心的)。啓用keep-alive一般只是服務器上的配置更改，不須要對頁面自己進行任何更改，一般能夠將加載頁面的時間減小40-50%。計算公式以下：
比值 = 實際複用鏈接數 / 預期複用鏈接數
2.1.3 壓縮文本(Compress Text)
除了圖片或視頻，剩餘的都是某種類型的文本(html，javascript，css等)。HTTP提供了一種以壓縮形式傳輸文件的方法。啓用文本資源壓縮一般只是服務器配置更改，不須要對頁面自己進行任何更改，提升性能下降服務內容的成本(經過減小傳輸的數據量)。因爲文本資源一般在頁面的開頭(javascript和css)下載，所以，提供文本資源的快慢很影響用戶體驗。計算公式以下：
比值 = 資源壓縮後的大小 / 實際資源的大小
2.1.4 壓縮圖片(Compress Images)
圖像壓縮檢查僅查看照片圖像(JPEG文件)，確保質量不會設置得過高。JPEG圖像能夠在不下降視覺質量的狀況下壓縮。咱們能夠在Photoshop的「網絡存儲」模式中，使用一種質量級別爲「50」的壓縮圖像的標準。在視覺質量不是不好的狀況下，儘可能多的壓縮圖像。在照片中常常包含其餘數據，特別是若是照片來自數碼相機(包含關於相機，鏡頭，位置，縮略圖的信息)，其中一些應該在被髮布到網絡以前就移除(當心保留任何版權信息)。計算公式以下：
比值 = 圖片壓縮後的尺寸 / 圖片實際的尺寸
2.1.5 緩存靜態內容(Cache Static Content)
靜態內容是網頁上不常常更改的內容(圖片，javascript，css)。能夠配置它們，以便用戶的瀏覽器將它們緩存起來，瀏覽器決定一個資源被緩存多久取決於2個因素：緩存壽命和過時時間(TTL)。資源的壽命能夠經過2個標籤配置：實體標籤(ETags)和首部標籤(Last-Modified)。過時時間是根據2個TTL首部標籤：Cache-Control的max-age屬性和Expires Header。若是用戶回到頁面(或訪問使用相同文件的其餘頁面)，他們可使用已經擁有的副本，而不是從新請求文件Web服務器。在用戶瀏覽器中成功緩存靜態內容能夠顯著提升重複訪問的性能(高達80+%，具體優化率取決於頁面)，並能減小Web服務器上的負載。有時可能很難實現緩存而不改變頁面，因此不要盲目地啓用它(你須要可以更改但願改變的任何文件的文件名)。
比值 = 過時資源數得分 / 靜態資源總數
這個評級須要一個緩存生命週期評分系統，若是一個靜態資源的生命週期超過一週，就100分，超過一小時，最多50分，以上狀況以外都是0分。
2.1.6 合併JS/CSS文件(Combine JS/CSS Files)
提升性能一般意味着減小對內容的請求數，最簡單(最重要的)方法之一是減小在頁面開頭加載的css和javascript文件數量(在 中會阻塞頁面顯示)。一個簡單的實現方法是將JavaScript和CSS分別合併到一個文件中(CSS最好在JavaScript以前加載)。減小用戶從屏幕上看到東西的等待時間，對用戶體驗有巨大的影響。計算方式：
2.1.7 使用CDN(Use of CDN)
每一個內容的請求都是從用戶的瀏覽器到Web服務器，再返回。隨着距離愈來愈遠，這樣一個往返可能消耗不少時間(頁面上的請求越多，消耗的時間越多)，把你的服務器創建在離用戶比較近的地方就能解決這個問題，這正是內容分發網絡(CDN)的做用。他們在世界各地都有靠近用戶的服務器，從靠近用戶的服務器提供網站的靜態內容。使用CDN沒有意義的惟一狀況是若是網站的全部用戶都已經接近Web服務器(例如社區網站)。計算方式：
比值 = 經過CDN服務獲取的靜態資源數 / 靜態資源總數
2.2 高級度量(High-level Metrics)
結果頁頂部的數據表提供了有關已加載頁面的一些高級信息：
2.2.1 首次視圖(First View)
首次視圖的測試，將會把瀏覽器的緩存和Cookie清除，表示訪問者第一次訪問該網頁，將體驗到的狀況。
2.2.2 重複視圖(Repeat View)
重複視圖會在首次視圖測試後當即執行，不會清除任何內容。瀏覽器窗口在First View測試後關閉，而後啓動新瀏覽器以執行Repeat View測試。重複視圖測試模擬的是用戶離開頁面後，立刻再進入此頁面的場景。
2.2.3 文檔加載完畢(Document Complete)
從初始化請求，到加載全部靜態內容(圖片、CSS、JavaScript等)，但可能不包括由JavaScript執行觸發的內容，能夠理解爲開始執行window.onload。原文以下：
The metrics grouped together under the Document Complete heading are the metrics collected up until the browser considered the page loaded (onLoad event for those familiar with the javascript events). This usually happens after all of the images content have loaded but may not include content that is triggered by javascript execution.
2.2.4 頁面全部元素加載時間(Fully Loaded)
從初始化請求，到Document Complete後，2秒內沒有網絡活動的時間，這包括在主網頁加載後由JavaScript觸發的任何活動。原文以下：
The metrics grouped together under the Fully Loaded heading are the metrics collected up until there was 2 seconds of no network activity after Document Complete. This will usually include any activity that is triggered by javascript after the main page loads.
2.2.5 整頁加載時間(Load Time)
與Document Complete中的時間屬性相同。原文以下：
The Load Time is the time from when the user started navigating to the page until the Document Complete event (usually when all of the page content has loaded).
2.2.6 第一個字節加載時間(First Byte)
這個時間表示從初始化請求到服務器響應後，接收到第一個字節的時間。此時的大部分時間一般稱爲「後端時間」，服務器爲用戶構建頁面的時間量。原文以下：
The First Byte time is the time from when the user started navigating to the page until the first bit of the server response arrived. The bulk of this time is usually referred to the "back-end time" and is the amount of time the server spent building the page for the user.
2.2.7 頁面渲染時間(Start Render)
渲染時間表示屏幕上顯示東西的第一個時間點，在這個時間點以前，用戶看到的是一個空白頁。這並不表示用戶看到了內容，可能只是一個簡單的背景色，但這是用戶開始看到內容的第一個指標，我理解這個爲白屏時間。原文以下：
The Start Render time is the first point in time that something was displayed to the screen. Before this point in time the user was staring at a blank page. This does not necessarily mean the user saw the page content, it could just be something as simple as a background color but it is the first indication of something happening for the user.
2.2.8 DOM元素數量(DOM Elements)
在測試結束時測試頁面上的DOM元素的計數。
2.2.10 HTTP請求數(Requests)
瀏覽器針對頁面上的內容(圖片，javascript，css等)發出的請求數。
2.2.11 傳輸的字節量(Bytes In)
瀏覽器加載頁面下載的數據量。它一般也被稱爲「頁面大小」。