- From: Herminio Vazquez <hvazquez@planittesting.com>
- Date: Wed, 9 Sep 2015 06:01:51 +0000
- To: "'public-web-perf@w3.org'" <public-web-perf@w3.org>
- Message-ID: <SINPR01MB25150CFFCCA061F57299E28D3520@SINPR01MB251.apcprd01.prod.exchangelabs.c>
Dear Group, I read the Navigation Timing 2 Working Draft and I am very excited to see this work materialising in the Web Browser industry. My area of interest or the comments that I have are the following: I have spent the last 15 years of my professional career conducting Performance Testing in small and large enterprise applications, and I have had the chance to evidence how the industry has evolved to more efficient ways of monitoring performance of a multitude of applications, including those in thin-clients like a browser. Based on that I have come across with the theory that testing efforts are likely to be duplicated when doing functional testing and performance testing, because both areas will have to tackle the same challenges of simulating the interactions between end users with the browser. The main difference is that performance test engineers when appropriate will use protocol level technologies to perform the simulations as opposed to functional automation engineers that will most likely use tools that scan and interact with the DOM. Nowadays with the ability to scale environments and launch things in the Cloud the idea of having a unified test script that covers functional and performance aspects is becoming more and more evident, and various groups and individuals around the world are starting to apply this logic into their automation efforts for Functional and Non-Functional purposes. With this in the background the only limitation today to fully move into that direction, is the ability to capture performance metrics from the functional point of view. That is the reason why now with the Navigation Timing interface I got so excited, especially with the latest addition of the transfer sizes of body and headers which means that all the information that could be obtained through the protocol transmission of information can now be collected from the browser itself which hopefully will help to finally arrive to a sort of "silver-bullet" solution that can benefit the entire testing community, and in favour of increasing the quality footprint of all applications developed using web technologies. Now, my opinion is that there is one more thing that could be interesting to have in the Navigation Timing, and that is the markers that define the different states in the DOM, which will effectively help to group the number of resources loaded as result of a user interaction. For applications developed with the one-page pattern, where the events triggered modify the DOM and just load external resources like data encoded in JSON format or XMLs, then is difficult to track through the Navigation Timing API the result of those interactions. They will be added to the array of entries accessible through the performance.getEntries() but it will not show which interaction triggered them, or the different states of the DOM before and after the resources were requested and loaded. In this scenario, the timings for each resource also increase and increase because there is no new DOM loaded and the durations are calculated according to the initial request start time of the web page. Perhaps if there is a mechanism to understand the events that trigger or change the DOM the counters can be reset or marked to that specific point in time, or added to the history or other object in the DOM that understand the end user interactions keeping track only of the performance measurements without any other information so that the security or other aspects around it are not impacted. It will be ideal to have this sort of functionality so that the collection of performance test information can be grouped by individual transactions that reflect the interactions made by the end user with the web page, and therefore be represented in the same way information is grouped when working with protocol level calls. I am happy to share the examples and information around the cases I am exposing above, and I will be interested to know how can I contribute and if possible up to my abilities or as a supportive role for the specifications in the future. Thank you very much for your time. Best Regards. Herminio Vazquez Principal Technical Consultant Planit Main: +61 8 6109 3800 Dir: +61 8 6109 3811 Mob: +61 424 242 512 Email: hvazquez@planittesting.com<mailto:hvazquez@planittesting.com> Web: www.planittesting.com<http://www.planittesting.com> Suite 1.5, 9 Havelock Street, West Perth, WA, 6005
Received on Thursday, 10 September 2015 21:37:43 UTC