What Transaction Response Time encompasses

The Transaction Response Time encompasses the time taken for the request made to the web server, there after being process by the Web Server and sent to the Application Server, which in most instances will make a request to the Database Server. All this will then be repeated again backward from the Database Server, Application Server, Web Server and back to the user. Take note that the time taken for the request or data in the network transmission is also factored in.
To simplify, the Transaction Response Time comprises of the following:
1. Processing time on Web Server
2. Processing time on Application Server
3. Processing time on Database Server
4. Network latency between the servers, and the client.

We will illustrate using Web (HTTP/HTML) protocol.Keep in mind that when we mention rendering time, it means the time taken for the display of the web components, Javascript or applet to load in the browser (or anything that is considered client-activity, loading in the browser) that is being activated after the HTML page is being received.

When we replay the scripts in LoadRunner, network traffic are being generated by the APIs (functions) and are expected to receive before the subsequent step can be executed. All this are taken place in memory and what LoadRunner does is to generate the traffic and receive the responses in memory. No user interface (UI) is launched in the process of replay for the purpose of rendering the pages received. Having no UI launched, rendering is omitted.

In a real user environment, the entire time for response in user perspective includes the request sending time, request processed time, response time and the browser loading (rendering time). However, in the context of LoadRunner, UI is not part of this entire request and response cycle.

Keep in mind that the transmission of the data is still pure text (or binary) and that needs to be rendered by the browser to be displayed properly. That's considering the Javascript and any applets that needs to be loaded which is greatly dependent on the browser (eg. IE, Modzilla)and your machine specifications.
Even for Web Page Diagnostics, rendering time is not included as part of the transaction response time. It only allows the drill-down of time taken to download web components and not the time taken to render the component for display. In summary, it's still at the network level.

If you are looking for an end-to-end response time testing that includes the rendering of the UI, you should consider using the GUI vuser protocol. Or the AjaxThe protocol utilizes another (famous) HP testing product, Quick Test Professional (QTP) as the recording mechanism, and replays the QTP scripts in the Load Generators as GUI vusers. For official information on the GUI vuser protocol, you can refer to the HP LoadRunner (v9.0) Controller User Guide, Chapter 14, ''Using Functional Testing Scripts in LoadRunner''.

TruClient transactions function differently from other protocols because of the asynchronous nature of TruClient steps. Transactions are defined based on start and end steps and step events. Due to this definition, a transaction's end can be triggered before the true end of a step. (From LR11 help files)