Client side statistics analysis

What is Page Load Time in Performance Testing?

• Page Load Time
• Speed Index
• Time to Interactive
• Total Blocking Time
• Largest Contentful Paint
• First Paint
• First Contentful Paint
• First Meaningful Paint
• Cumulative Layout Shift

Def :  ‘Response Time refers to the amount of time from the moment that a user sends a request until the time that the application indicates that the request has completed and reaches back to the user.’ But, nowadays a new term is getting added in the performance testing which is ‘Page Load Time’. 

Page Rendering Time :- Total time is taking to get the immediate next page.

There are no tools that can provide you client-side rendering times. Client side rendering is not a measurable value,

Page Load Time : How much time it is taking the page to load all the content in the page.. Also, we can say that it is a time when all the components (items) of a page get displayed on the browser for user interaction. It depends on 3 things:

Server Processing Time: How quickly the servers serve the request and send response back to the client.

Network Latency: How quickly the communication channel transfer the information from client to server and server to client.

Component Load Time: How quickly it takes for the browser to parse and execute the document (available in cache or coming from server) and render the page to make it available for user interaction.

Time Taken For First Buffer Graph (TTFB):

If the TTFB is high then the problem is with server or application.

If the TTFB is low and the page response time is very high then that is a network issue.

Note :- 

Put Javascript at the bottom : If you have JavaScript at the top of the page, it'll be executed when the parser gets to it, potentially delaying the rendering of the rest of your page.

If your JavaScript is at the bottom, the parser will execute it only after parsing and rendering the rest of the page.

To analyse the client side statistics we have to merge the following graphs inorder to identify the bottleneck.

 Running Vusers.

 Connections.

 Hits per seconds.

 Throughput.

 Error per second.

 Response time.

Merging: We can merge the graph in 3 ways.

Overlay Graph

Tile graph

Correlate graph

Scenario1: Relation between Hits per second and throughput.

Both should be directly proportional, if not

Cause1: That could be a network bandwidth issue.

Cause2: Web server might have issue.

Cause3: Application itself having the issue.

Note: Hits are increasing and throughputs are not increasing due to the application issues. We are receiving exception page which impacts high hits low throughput.

Scenario2: Relation between running users and hits per second?

Both should be directly propositional, if not application itself having a problem (or) application is not responding well.

Scenario3: Relation between throughput and response time.

Both should be inversely proportional.

Note: As per the market standard both should be inversely proportional based on boundaries (if you are testing pages).

Scenario4: Relation between running users and connections

Both should be directly proportional, if not

Cause1: Connection limit issues in the web server.

Cause2: Number of treads limit reached threshold point in the web server.

Controller output message for above issue:

1. Users permanently or prematurely shutdown

2. Web server log max client error.

WEB PAGE DIAGNOSTICS:

Using Web page diagnostics graph we drill down the issues related to component, network, and server level issues (break down drill).

Component Break down graph:

Which will allow you to analyze component level issue any one of the component getting delay to download which will reported as an issue.

Note: After this we have to move to server side analysis.