響應時間=網絡傳輸時間（請求）+服務器處理時間（一層或是多層）+網絡傳輸時間（響應）+頁面前段解析時間
響應時間=呈現時間+網絡傳輸時間+服務器端響應時間+應用延時時間
呈現時間
其實主要說的瀏覽器對接收到數據的一個處理展示的過程。幾年前大家都在用IE，如果頁面顯示比較慢，我們肯定不會怪罪IE，只會怪罪電信運營商的網速或被訪問的系統（其實，大多情況我們不會考慮是被訪問系統的問題）。現在chrome來了，我們會發現同一台電腦同一個網站，通過chrome去訪問，頁面的呈現速度會比IE略快。這是各種評測及大眾用戶的整體感受。當然，我個人感覺，opera瀏覽器的呈現速度最快，但它的顯示效果一直不太好。
呈現時間構成主要是前端的響應時間，這部分時間主要取決於客戶度而非服務端。
當然，我說這個呈現時間總不能全怪罪與瀏覽器的身上吧！當然還和承載它的操作系統有關，以及電腦硬件（比如cpu 內存）。假如你有超快的瀏覽器，如果是一台極其垃圾的電腦，我想你多打開兩個網頁就有可能使電腦卡掉。
網絡傳輸時間
千萬不要忽視數據傳輸時間。如果你要寄信給你一個遠方的朋友，你想是什么影響你將信息傳遞給遠方的朋友？不是你寫信的過程（如果你寫的信不像書一樣厚的話），也不是你朋友讀信的過程，而是送信的過程。
你的帶寬是多少？互聯網是個網，就是算是相同的起點與終點，它有可能走的不同的路線。有沒有考慮網絡延遲？就算你的並發請求都能成功的發出，但到目的地的時候，已經不能叫並發了。
這也是為什么我們在一般做性能測試時，一般要強調要在局域網中進行。當然，也有特殊的性能測試需要在互聯網中時行。它們重點不是求用戶的最大的並發量。
服務器端響應時間
系統得到請求后對請求進行處理並將結果返回。那我進行性能測試主要就是驗證系統的處理時間，因為前面的呈現時間和數據傳輸時間都我們不可控制的，用戶使用的電腦及瀏覽器千差萬別，用戶的網絡狀況千差萬別。我們唯一能控制的就是將系統的處理請求的時間縮到最短暫。
如果我們對系統的的處理進行分析和講解的話，它會是一個非常龐大與復雜的過程。語言、語言框架、中間件，數據庫、系統架構以及服務器系統。
現在的測試工具都屏蔽呈現過程，只是模擬多用戶並發請求，計算用戶得到響應的時間，也不會將服務器的每個響應都向客戶端呈現。
對於數據傳輸的問題，這也是我要強調的性能測試要在局域網中進行，在局域網中一般不會受到數據帶寬的限制。所以，可以對數據的傳輸時間忽略不計。
我要訪問百度首頁，發出了一個請求，百度開始給我返回頁面數據，當搜索框與搜索按鈕都已經返回到頁面上了，但那個圖標還在發送中。我不認為這個響應是完整的。必須把頁面上的所有信息都返回給我才是完整的，我要的也是所有結果返回給我的時間。這種情況更符合“相應時間”的定義
某系統有一個信息查詢功能，當我輸入某條件查詢時，可能要查詢幾百萬條數據，如果數據庫，要查詢所有的數據並把所有的數據全部完整的返回給我。可能服務器要查詢很久，而我的電腦全部接收這些數據也可能只直接掛掉。那么服務器可能只查詢100條數據並把數據返回給我，當我點擊“下一頁”時，服務器再次查詢並將第二頁的數據返回給我。這種情況更符合“系統響應時間”的定義。
關於響應時間，要特別說明的一點是，對客戶來說，該值是否能夠被接受是帶有一定的用戶主觀色彩，也就是說，響應時間的“長”和“短”沒有絕對的區別。
合理的響應時間
在互聯網上對於用戶響應時間，有一個普遍的標准。2/5/10秒原則。
也就是說，在2秒之內給客戶響應被用戶認為是“非常有吸引力”的用戶體驗。在5秒之內響應客戶被認為“比較不錯”的用戶體驗，在10秒內給用戶響應被認為“糟糕”的用戶體驗。如果超過10秒還沒有得到響應，那么大多用戶會認為這次請求是失敗的。
這里我們還要考慮一個使用頻率的概念。
我最早安裝windows系統可能要1個小時，我們為什么覺得這很正常，因為我們要很久才裝一次系統，如果系統使用得當，可能一個系統用幾年不用重裝，假如，我們在系統上裝個任何小軟件都要這么長時間，那我們一定是無法忍受的。對於軟件控來說，他們會時常安裝各種新鮮有趣的軟件進行使用。
對於一個稅務報賬系統，該系統的用戶每月使用一次，一次花費3小時進行數據的錄入，
當用戶單擊“提交”按鈕后，即使系統在10分鍾后才給出“處理成功”的消息，我們也覺得是可以接受的。
因此，在進行性能測試時，“合理的響應時間”取決於用戶的需求，而不能依據測試人員自己設想來決定。