自網站誕生以來，響應速度/響應時間一直都是大家關心的話題，而速度慢乃是網站的一個殺手，正當大家以為四核和寬帶能力的提升能夠解決這些問題時，Wi-Fi和移動設備為熱點移動互聯網又悄然興起。

　　在2006年，Amazon曾做過一個報道，響應時間每提高100ms，他們便會增加1%的收入。優化的價值已顯而易見，但到底多快才是個標準，或者速度有多快才算夠快呢？那么到底什么是響應時間，它有多大的價值？

　　從技術上來講，響應時間是指用戶發送一個指令（例如，一個頁面請求）瀏覽器接收到完成加載的時間。定義看起來非常簡單，但當你在思考如何設計一個帶有許多額外對象的現代網頁時，響應時間對用戶體驗是非常重要的，并且它也不會告訴你，哪些因素影響著響應時間。

　　一個稍微好點的衡量標準則是頁面加載時間。頁面加載時間是指從用戶發送指令到瀏覽器加載完整個頁面對象所用的時間。好比響應時間，頁面加載整個過程涉及到很多事情，它由一系列執行步驟組成，并且每一步都需要單獨監控，每一步都會告訴你問題所在。

　　步驟包括：

• DNS解析時間
• TCP鏈接時間
• HTTP重定向時間
• 首字節加載時間
• HTML內容時間
• 整個頁面對象加載時間

　　DNS解析時間

　　DNS查找的時間就是將域名翻譯成具體ip的時間，大多人數認為，無論DNS是否工作，都不是件簡單的事情。

　　在這個過程中，你可能會遇到許多微妙的問題，比如響應時間太長、超時、無效的緩存等。這些情況下，一個查詢便可通過，但它需要花費更多的時間。

　通常，如果DNS的查找時間過長，那么意味著你或托管服務商的DNS服務有問題。記住，如果網站與其DNS服務之間距離太遠，那么解析時間也會稍微增加，這在一些國際網站上會體現出來，而有效的緩存則會降低時間。

　　TCP鏈接時間

　　當URL被解析成一個IP地址后，TCP鏈接時間表示客戶端鏈接到服務端所花費的時間。監控鏈接時間有助于開發者發現一些影響響應時間的問題，比如網絡延時、路由問題、服務器寬帶問題等。

　　例如，如果寬帶服務器不足以處理工作負載，那么客戶端要先與服務器端意識到這個問題，當客戶端向服務器端發送請求時，可能會被拒絕或者時間超時、響應時間延遲等問題。

　　HTTP重定向時間

　　HTTP重定向時間主要是指TCP鏈接完成時間，它意味著發送初始通知到重定向網站并且瀏覽器最終定向到目標網站所花費的時間。如果沒有重定向，那么重定向時間就為0。它包括了DNS解析時間、TCP鏈接等等。

　　HTTP重定向可用于縮短URL、當網頁鏈接移動時，可用于防止鏈接損壞，或允許多個域名鏈接到一個網站上。

　　首字節加載時間

　　當開發人員思考如何優化網站時，往往會選擇優化內容——文件組合、多媒體優化、緩存和壓縮文件，但也有需要對服務器進行優化。其中一個最佳指標就是首字節的加載時間，首字節加載時間表示從鏈接創建到首字節成功轉換所花費的時間。這個時間也包括了服務器執行各種協議和計算的時間。

　　通常服務器端遇到與首字節相關的問題包括內存泄露、程序派生的進程太多——沒有完全關閉——低效SQL查詢，并且調用外部資源，例如谷歌和Facebook。

　　HTML內容時間

　　HTML內容時間主要包括加載Web頁面布局、CSS、javaScript，這個時間與HTML頁面的大小有著直接的關系。HTML內容加載時間通常會作為衡量寬帶的一個指標，但也不完全是。

　　整個頁面對象加載時間

　　一旦整個HTML內容被整個接收，瀏覽器會解析所有的頁面對象，并且直到所有對象加載完畢。這些對象包括圖片、Javascript、CSS、Flas對象、rss回饋、JavaScript文件等。

　　衡量全頁加載時間對監控第三方內容非常有用，特別是廣告，但它并不會告訴你有哪些用戶看了這個廣告。例如，它不會告訴你第三方內容放在哪加載速度會快些。但站在用戶角度來看，這些并不算問題。

　　作者對網站的響應時間和頁面加載時間進行了詳細的劃分與解釋，相信你對這些指標都有了更深地理解，開發者可以根據這些指標來確定網站的問題所在（如果這方面存在問題）。

　　來自：SMARTBEAR