对于loadrunner而言，response time只反映了传输时间和系统处理事务的时间，而客户的浏览器从接收完所有字节开始到浏览器加载完所有元素、运行完所有js，呈现给用户的这段时间loadrunner是不统计的，这部分属于页面前端性能，需要通过前端工具辅助分析。

通过Loadrunner获取的事务响应时间，主要可以分解为：First Buffer +Receive + Client Time

       1）First Buffer（建立Connection后，浏览器发送请求并成功接收第一个字节的时间）

       2）Receive（浏览器接收到第一个字节到最后一个字节的时间）

       3）Client Time（请求在客户端浏览器延迟的时间，基本可以忽略）

       除了这三个时间，一般细分时间表里还包括DNS解析时间、FTP认证时间、SSL加密握手时间、Connection创建连接时间等（all time = dns time + connection time  + first buffer time + received time + ssl time + error time + client time + ftp authrioze time），以下是Loadrunner中的页面时间细化表：

        针对first buffer time我们还可以进一步分解：first buffer time = server time  + network time，以下说明一下这两个时间：

Network Time   每个网页组件的网络时间

Server Time  每个网页组件的服务器时间   ＝ web application time + server deal time + database time

|C-----------------request------------>S| 浏览器发送请求

|C<----------------ACK-----------------S| 服务器发送ACK

|C<--------the first buffer------------S| 服务器发送the first buffer

network time 是发出请求到收到ACK的时间

Server time  是收到ACK后到完成接收the first buffer的时间

        由于Loadrunner统计的事务响应时间不包括浏览器的加载显示时间，所以不能完全体现用户的真实体验时间，所以借用浏览器性能分析工具进行单用户操作分析是有必要的，以下通过浏览器的F12开发者工具进行响应时间的细分分析：

（1）Firefox（Firebug插件）

1）阻挡(Blocking)：每个浏览器有并发连接数量的上限（例如Firefox对每个host限制6个连接），如果当前建立的连接数已经超过上限，那么其余该请求会被阻塞，等待新的可以用的连接。

2）域名解析(DNS Lookup)：就是从DNS请求发出去到收到回复的时间。

3）建立连接(Connecting)：三次握手建立TCP链接的时间。如果是HTTPS的话，还有SSL链接的时间。

4）发送请求(Sending)：从发送本次请求的第一个bit，到最后一个bit。对应Request sent

5）等待响应(Waiting)：从发送结束起，到收到host返回的第一个bit。相当于是Request和Response中间的间隙。这段时间即系统处理时间（包括后台数据库、应用服务处理时间）。

6）接收数据(Receiving)：从收到host返回的第一个bit，到收到最后一个bit。

7）DOMContentLoaded：DOMContentLoaded事件完成的时间，从请求发起时开始，到所有页面元素加载完成。

8）Load：事件，页面load事件完成的时间，从请求发起时开始，到所有js事件运行完成。

（2）Chrome（F12）

1）DNS lookup：域名解析时间

2）stalled：相当于Blocking，是浏览器得到要发出这个请求的指令，到请求可以发出的等待时间（一般是代理协商、以及等待可复用的TCP连接释放的时间，不包括DNS查询、建立TCP连接等时间等）。

3）request sent：请求第一个字节发出前到最后一个字节发出后的时间，也就是上传时间。

4）waiting：请求发出后，到收到响应的第一个字节所花费的时间(Time To FirstByte)。

5）Content Download/ Downloading：接收响应数据的时间（可理解为下载时间）。

6）InitialConnection / Connecting：建立连接的时间，包括TCP握手/重试和协商SSL。

7）DOMContentLoaded：DOMContentLoaded事件完成的时间，从请求发起时开始，到所有页面元素加载完成。

8）Load：事件，页面load事件完成的时间，从请求发起时开始，到所有js事件运行完成。

（3）IE（F12）

1）等候：自开始页面导航起至开始此请求之间的时间。

2）开始：从最初创建请求到发送请求之间的时间。

3）请求：接收到第一个字节所需的时间。发送请求并接收服务器的第一个响应所需花费的时间。

4）响应：接收服务器的响应数据所花费的时间。

5）差距：完成此请求到加载页面之间的时间。

6）DOMContentLoaded（event）：DOMContentLoaded事件完成的时间，从请求发起时开始，到所有页面元素加载完成。

7）Load（event）：事件，页面load事件完成的时间，从请求发起时开始，到所有js事件运行完成。

        以上这些工具已经能够站在用户角度分析响应时间了，但是如果站在开发角度分析应用响应时间，还不足以细分，比如我们已经知道Watting花的时间长，大都是由于后台处理慢引起的，但不知道是Web服务慢还是数据库处理慢。这时候我们就可以利用一些市面上的APM工具（或更直接一点的，利用一些性能分析小工具，比如.Net的ANTS、Java的visualvm），来监控分析关键事务的响应时间，其监控原理比较复杂，不在这细说，APM的主要功能就是统计分析应用（如.net或Java等）的CPU、内存、网络、数据库、UI等性能，并提供错误日志捕获。以下是监控事务响应时间的效果图：

        细分到具体的慢组件，就可以看到是否是数据库组件慢：