对于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等性能，并提供错误日志捕获。以下是监控事务响应时间的效果图：
细分到具体的慢组件，就可以看到是否是数据库组件慢：