一個用戶去訪問一個頁面的請求過程，如下圖：
- 數據傳輸時間
從瀏覽器輸入網址。敲回車，開始------------真實的用戶場景請不要忽略數據傳輸時間， 當我們發一個請求，到服務器接收到這個請求需要時間，系統處理完后，將處理結果返回給我們也需要時間。
網絡傳輸時間往往也很難模擬真實的場景，因為你網站的用戶可能來自世界各地，總不能在世界各地都搞一個客戶端，就算可以，我們通過什么方式讓他們“同時”發送請求給服務器呢？所以，我們的性能測試都是放在局域網里進行的，就是為了盡量降低傳輸時間，模擬並發。
- 客戶端處理時間
從瀏覽器得到響應數據開始----------瀏覽器拿到返回的數據后，只是一些HTML、JS、CSS、圖片的資源，更底層當然是二進制數據，需要時間把它們渲染成我們想要的網頁。
然而，我們在LoadRunner、Jmeter進行性能測試的時候，是沒有客戶端處理時間，你當然可以打開100個網頁（多線程+Selenium實現）訪問某網站試試，這沒對服務器產生多大壓力，先把自己的電腦搞掛了。
- 系統處理時間
從系統得到請求后開始------------這是我們的性能測試主要關心的時間，當系統得到請求后，需要對請求進行處理，可能需要查詢數據庫服務，也可能調用其他服務，最終生成處理結果並返回給客戶端。
基於以上問題，我們所做的性能測試是無法模擬真實的情況，網絡傳輸時間太過復雜，客戶端處理時間取決於用戶的設備。我們能做的就是盡量保證服務器端的處理時間，以及在一定的時間可以支撐的並發量。
隨着，技術的發展，越來越多的系統開始做前后端分離。后端，服務只提供接口，前端在不同的設備上以不同的方式展示。
在這樣的架構下，我們的性能測試也划分為后端性能和前端性能。
后端性能其實就是接口性能。我們更多時候不再設計模擬用戶場景，而是針對單個或一組關聯接口進行性能測試，這在一定的程度上降低了測試的難度。其實，不管是否是前、后端分離的架構，大多數時候它們用的都是HTTP協議，如果是前、后端不分離，當你發送一個請求時，它會返回一堆數據：HTML,JS,CSS,圖片，音視頻等。如果是前、后端分離的架構，那么后端API返回的數據就單純多了，一般為JSON格式的數據。
顯然只做后端性能是不夠的，當用戶看到一個頁面時，不單單只有后端返回的接口數據。
這是我們在訪問一個頁面得到的所有數據，在你的后端服務器沒有達到最大並發的前提下，那么影響用戶體驗的就兩方面，一個是請求的個數，另一個就是請求的文件的大小。所以，請求的個數，比如有些JS文件可以做到合並；減少請求的大小，比如：有些圖片做壓縮處理。自然用戶體驗就會好很多，前段性能其實不需要通過“並發”來測試的。