Current time: 09-24-2019, 06:21 AM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
measuring specific times via end-conditions
10-11-2011, 02:47 AM
Post: #1
measuring specific times via end-conditions
Hi,
I have the follwing questions concerning the possibilities of measuring specific times in the loading process of a site through the use of end-conditions in scripted tests:

1)
The recorded time of tests scripted with the command setDOMElement is saved in file "1_report.txt": e.g. Time to DOM Element(id'myIdValue). Where is the time of tests scripted with the command setDOMRequest saved?
2)
The "Time to DOM Element" seems to be integrated in WPT Monitor (DOM Time). The time measured via setDOMRequest can't be shown in monitor out of the box?
3)
Does the script-command "requiredRequests" records the time when the listed requests are fired (or their responses returned) like the commands setDOMElement and setDOMRequest do?
If not:
* Is it possible to measure the time when more than one specific DOM-Tree-Elements are loaded?
* Which time isn't recorded before the listed requests send their responses: Time to Document loaded, Time to fully loaded?
* If one of the required requests can't be loaded the test/measurement reaches timeout?
4)
In my sripted tests using end-conditions often the time to start of rendering isn't taken correctly (0.000 seconds). Any ideas why that?

In generally:
I want to measure specific times in the loading process of a site like the following example: images x, y and z are loaded, DOM-Tree-Element x is rendered and another element, e.g a select is usable.
Do you think adapting WPT for measuring souch specific times is a good idea? How would you assess the effort from 0 (nearly possible out-of-the box) to 10 (complete redesign of the browser-plugins for IE, Chrome and FF)?

Many thanks in advance for any suggestions/informations, Nils
Find all posts by this user
Quote this message in a reply
10-11-2011, 03:01 AM
Post: #2
RE: measuring specific times via end-conditions
(10-11-2011 02:47 AM)nilskuhn Wrote:  1)
The recorded time of tests scripted with the command setDOMElement is saved in file "1_report.txt": e.g. Time to DOM Element(id'myIdValue). Where is the time of tests scripted with the command setDOMRequest saved?
It overloads the DOM Element field and the time is recorded there (you can't have both).
Quote:2)
The "Time to DOM Element" seems to be integrated in WPT Monitor (DOM Time). The time measured via setDOMRequest can't be shown in monitor out of the box?
It should since it is written to the same field.
Quote:3)
Does the script-command "requiredRequests" records the time when the listed requests are fired (or their responses returned) like the commands setDOMElement and setDOMRequest do?
No, it does not record the times.
Quote:If not:
* Is it possible to measure the time when more than one specific DOM-Tree-Elements are loaded?
* Which time isn't recorded before the listed requests send their responses: Time to Document loaded, Time to fully loaded?
* If one of the required requests can't be loaded the test/measurement reaches timeout?
No, you can only record a single custom time in the current implementation. The test will report as a timeout error if the specified element isn't recorded (and I'm not sure but some of the times might be zero'd out, depending on the version of software).
Quote:4)
In my sripted tests using end-conditions often the time to start of rendering isn't taken correctly (0.000 seconds). Any ideas why that?
Render start is generally only measured for the first step of a navigation (when the screen is non-white). It can't (currently) measure the first visual change from a screen that has already been drawn.
Quote:In generally:
I want to measure specific times in the loading process of a site like the following example: images x, y and z are loaded, DOM-Tree-Element x is rendered and another element, e.g a select is usable.
Do you think adapting WPT for measuring souch specific times is a good idea? How would you assess the effort from 0 (nearly possible out-of-the box) to 10 (complete redesign of the browser-plugins for IE, Chrome and FF)?
You generally want to be REALLY careful over-instrumenting the DOM events because it generally has to poll the DOM looking for something so the granularity isn't great (100ms generally) and it can have a significant impact on the actual times (depending on how complex the DOM is). It's not hard to extend the current code (maybe a 3-4 effort just to cascade multiple times through the system) but other solutions might be better. If you control the page being measured then you might be better off instrumenting the page itself (onload handlers on the items you care about).
Visit this user's website Find all posts by this user
Quote this message in a reply
10-11-2011, 09:04 AM
Post: #3
RE: measuring specific times via end-conditions
concerning your last comment If you control the page being measured then you might be better off instrumenting the page itself (onload handlers on the items you care about).: Could you specify that: Should I be able to get the time of some onload-events via js-related WPT-script-commands or do you think of a measurement implemented without WPT at all?

Generelly I conclude that it isn't on your nearer focus to implement a possibility to measure the time when a group of specific DOM-tree-elements is loaded/rendered via scripted tests?
Find all posts by this user
Quote this message in a reply
10-12-2011, 12:24 AM
Post: #4
RE: measuring specific times via end-conditions
It's not on my near-term todo list (i.e. this year) but it is something that I want to add at some point.

As far as work-arounds go, you can use the webpagetest DOM interface from code to send status messages which are timestamped: http://www.webpagetest.org/forums/showth...hp?tid=461

It is only supported on IE right now but it lets you send trace statements from code to webpagetest and they will be displayed on the screen shot page with the rest of the browser messages.
Visit this user's website Find all posts by this user
Quote this message in a reply
10-12-2011, 07:04 PM
Post: #5
RE: measuring specific times via end-conditions
Thanks for the hint, that's great!

My plan was to get the time to measure in loading process via JS and inducing WPT to measure that time through loading a pixel or something (which I can catch with setDOMElement). I will compare the times the different approaches provide.
Find all posts by this user
Quote this message in a reply
10-19-2011, 06:25 AM
Post: #6
RE: measuring specific times via end-conditions
Hi,

I tried the following approaches a, b and c to measure a specific time in the loading process of a site:

a) and b)
I set an img-object as a beacon via Javascript. To measure that time I used the following srcipts:
a)
Code:
setDOMElement    id="beacon"
navigate    http://TheUrlToTheResourceToMeasure
b)
Code:
setDOMRequest    UrlToTheBeaconImage.gif    START
navigate    http://TheUrlToTheResourceToMeasure
c) Instead of setting an beacon-image I use the wpt-javascript-API and call window.webpagetest.done().
Code:
waitForJSDone
navigate    http://TheUrlToTheResourceToMeasure

Approach a doesn't measure any DOM-time. I assume the dynamically added img-object isn't noticed because wpt just searches the initially obtained markup of the site?

Approach b measures a DOM-time. That works and is my solution so far.

Approach c doesn't measure a DOM-time. Any idea why not?
Find all posts by this user
Quote this message in a reply
10-19-2011, 07:10 AM
Post: #7
RE: measuring specific times via end-conditions
(a) should work (get rid of the quotes though). WebPagetest polls the live browser DOM.

For © I don't think the jsdone is hooked up to the DOM time - it is just there to use as an overall end marker (though I can see about wiring it up). The status messages should also work but extracting the data is harder - that will let you timestamp multiple events in the load.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)