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:
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?
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
It overloads the DOM Element field and the time is recorded there (you can’t have both).
It should since it is written to the same field.
No, it does not record the times.
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).
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.
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).
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?
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.
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.
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?
(a) should work (get rid of the quotes though). WebPagetest polls the live browser DOM.
For (c) 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.