I'm practicing along with my colleague Chidambara, on Web Client Performance Testing (WCPT). While we practice together, we are learning, how to assess the current capability of the web page and then how to interpret the same. Why I say this, because when I test, I will make a report; that test report as to help one to decide and assist in taking the necessary action if it has to be taken. If not, the purpose of the test report might just bound to know what did I test and what is my interpretation. For this, I need not write the test report. The same with automation as well, isn't it? We will get the report on running the test suite and this report will be used further to decide what to do based on our interpretation of it. Coming back to WCPT, I happened to learn it this way and sharing my learning with my fellow tester.
I picked a Google India search page and monitored its requests and response. At time of testing, I used Firefox in private mode. I noticed total of 16 requests were fired and close to 1.4 MB data were transferred. Overall it took 4.62 seconds on 100 Mbps bandwidth internet line. Below picture reads the requests fired and its timeline.
I notice, first two redirection taking total of 294 ms, and then 484 ms to load the html document. In total, to load the html document, 778 ms is used. This is close to a second. If I had to make it to round figure, say 1 second to load the html document. Without html document, the web page will not get loaded and for this reason html document will be the first content to get downloaded on client i..e on the browser. Notice that there are two redirects with HTTP status code 302.
Moving ahead, I see other 3 seconds are used to download the images, stylesheet (CSS) and scripts. This tells, more time is taken to download these elements of the page then the html document. When looked into other web's webpages the same is observed during time of testing. With that, I learn, these elements are the time consumers if not handled well thereby showing the slow response time. Slower the response time is, i.e. the more time is taken to load the functional webpage.
The 'capability' i.e. performance attribute of the webpage will be -- "how quickly it loaded on the client i.e. what is its response time".
Note that, the expectation is, it should be functional and the experience of using it should be pleasant to the user; these are the implicit expectations with the words 'capability' and 'response time'.
If this is just for one webpage of a website, how many webpages do the product I'm testing, have? Now I understand very much better than ever that, like functionality is coded into the product, the performance as well should be designed and coded in equal importance. I derive my tests with such thought process as it serves me to be the base in building the tests and for sampling the variation and interpretation of test observations.
What did I learn here?
These are key learning when I happened to interpret the Web Client's performance
It is important to know what is HTTP and how the web communicates. So that we understand the influence of bandwidth and latency on the response time. In next post, I will share what I have understood for the same. Later in subsequent will share, how I and Chidambara progressed in learning and practicing of this.
I picked a Google India search page and monitored its requests and response. At time of testing, I used Firefox in private mode. I noticed total of 16 requests were fired and close to 1.4 MB data were transferred. Overall it took 4.62 seconds on 100 Mbps bandwidth internet line. Below picture reads the requests fired and its timeline.
 |
| HTTP requests fired from Google Search India page |
I notice, first two redirection taking total of 294 ms, and then 484 ms to load the html document. In total, to load the html document, 778 ms is used. This is close to a second. If I had to make it to round figure, say 1 second to load the html document. Without html document, the web page will not get loaded and for this reason html document will be the first content to get downloaded on client i..e on the browser. Notice that there are two redirects with HTTP status code 302.
I will walk through in a blog post how the redirects affects the web client performance potentially. I and Chidambara, practiced the same few days back.
Moving ahead, I see other 3 seconds are used to download the images, stylesheet (CSS) and scripts. This tells, more time is taken to download these elements of the page then the html document. When looked into other web's webpages the same is observed during time of testing. With that, I learn, these elements are the time consumers if not handled well thereby showing the slow response time. Slower the response time is, i.e. the more time is taken to load the functional webpage.
Now you see, while carrying out the functional test you also test partially for the performance of it, and vice versa.
The 'capability' i.e. performance attribute of the webpage will be -- "how quickly it loaded on the client i.e. what is its response time".
Note that, the expectation is, it should be functional and the experience of using it should be pleasant to the user; these are the implicit expectations with the words 'capability' and 'response time'.
In above picture, the total time for receiving the html document is 778 ms. But, the event DOMContentLoaded is fired after 1 second and somewhere it looks near to the mark of 1.2 second. Where did the 442 ms go then? On my network bandwidth of 100 Mbps and machine configuration with 8 GB RAM, still this is a question to me. Then what will be in other network bandwidth and client's machine configuration? Why DOM parsing took time?
I see there is JS being received i.e. in 8th request. I'm not sure if is synchronous or asynchronous. Technically where there is no dependencies between the scripts or any other page elements, keeping it as asynchronous helps.
Then there is a CSS being received in last second request. If the CSS isn't received well before, then page loading has to wait for it as the style cannot be defined for the parsed DOM of loaded html document. It is a thumb rule to keep CSS in the top requests while receiving from the server. But context of the website's design can change this thumb rule.If this gets tested, can the response time of the Google India search page can come close to 3.3 to 3.5 seconds?
If this is just for one webpage of a website, how many webpages do the product I'm testing, have? Now I understand very much better than ever that, like functionality is coded into the product, the performance as well should be designed and coded in equal importance. I derive my tests with such thought process as it serves me to be the base in building the tests and for sampling the variation and interpretation of test observations.
What did I learn here?
These are key learning when I happened to interpret the Web Client's performance
- More the number of HTTP requests, the response time increases for the webpage
- Lesser the number of HTTP requests, it is good from point view of webpage's response time and performance
- The html document takes minimal share in the total load time of the web page and rest of the time is taken by the webpage's element
- Handling and optimizing this is important for better performance of web client
- More the page weight, more the response time for webpage
- Need to test and figure out is there any way the page weight can be optimized, so the response time for webpage will be fast
- If said, 15% of time is for html document of the webpage and then other 85% is for the webpage's element, then the problem area is evident with respect to response time
- If fine tuned the client for better performance, the experience for targeted user should still be pleasing with better response time
- Upon this, if server performance is optimized, then do targeted user say, "it is just like this, so fast"? I do not know; but as a practicing tester I see, fine tuning the performance of web client is possible for a tester while she or he tests the website for functionality or any other quality criteria. In parallel, if taken care of server performance based on contextual learning from the tests observation, it will be very much useful.
- Know this when looked at webpage
- Number of HTTP requests fired;
- time taken by each requests;
- what each requests carries from client and back from server to client;
- size of the HTTP request transaction;
- page weight and contribution by each elements in the webpage;
- know when did DOMContentLoad event got fired in the timeline;
- in above picture it is marked with blue line in the timeline
- it is fired when the html document is completely parsed and loaded without waiting for other elements of the webpage i.e. css, js, images etc.
- know when did Load event got fired in the timeline;
- in above picture it is marked with red line in the timeline
- it is fired when the page elements are loaded and finished loading
- overall response time for the webpage;
- understand what each page element is and why it is needed;
- it is very much important from aspect of testing to know is it actually needed for the webpage or website
- if it is not needed, then as a tester I should be in position to advocate my observations out of tests
- if it is needed, then as a tester I should be in position to advocate my observations out of tests and how it can be tuned and optimized
It is important to know what is HTTP and how the web communicates. So that we understand the influence of bandwidth and latency on the response time. In next post, I will share what I have understood for the same. Later in subsequent will share, how I and Chidambara progressed in learning and practicing of this.
