Should Document Load Time be lower or higher than Total Load Time in UEM?
My UEM captured the four types of User Actions currently: load, click, touch, scroll
Page Load, or _load_, is the page opened from address box in browser. Its Total Load Time is higher than Document Load Time. Page can be opened either by manual input in browser address bar or by click on email ink in email and google search result page.
click, touch, scroll, are the real user actions. Currently I observed and long term trend chart show that Total Load Time is lower than Document Load Time in click and touch, scroll document load time does not show clear patten as click and touch but still intermittently exceed total load time .
Should Document Load Time be lower or higher than Total Load Time in UEM? According to the definition in UEM document, document load time should be lower than total load time. hence I am confused by the scenario and come up the weird question.
We need to choose a metric in UEM to measurement user action performance. In this scenario above, which metric, total load time or document load time, could be right metric to measurement user action performance?
Could anyone advise or share your experience?
Snapshots above are page load, click, touch, scroll, scroll with higher document load time, in sequence. dark blue line is user action count line, red line is total load time, dark yellow line is document load time
Hi. Are your Touch, Scroll and Click events always loading a new page? Or is it possible that some of these actions only do something in the browser (e.g: javascript that maybe loads an additional resource)? If that is the case the average value across all these user actions probably gives you a wrong picture. Why? Consider that some of your Click events REALLY load a new page -> here you have doc load time and full load time where full load time is probably higher than doc load time. But if you also have some other Click Events that do not open a fresh page you will get skewed results if you chart them all as Click Events. I think you need to differentiate between Clicks, Touches, ... that really load a new page and those user actions that are doing something different
I hope this makes sense
Thanks, Andreas
This is definition quoted from dynatrace document
"A user action contains all client activity during the transition from one state to another. Every user action contains at least one web request. For example, when a user navigates to a page, this causes the browser to download many resources and call the JavaScript onload handler, which in turn might perform XHR requests, etc."
By the definition, every user action contains at least one web request. Hence I derived that UEM captured Click or Touch or Scroll which triggered web request only, and those user actions which didn't trigger web request and are just native actions would not be captured/discarded, am I right?
Now that these manual actions are all web requests, UEM should report their performance metrics as usual, because loading such web requests are the same as loading their parent page. Since some elements are loaded up and cached in parent page, the manual actions should be faster than parent page loading, and we should see both its document load time and Total load time conform to the regular pattern, where total load time = unloading DOM time + document load time + load time(rendering content in browser).
If my reasoning is not right, there must be something wrong with the formula above, where total load time might not include document load time in click? But this is less likely happen because such scenario will shake the whole foundation of the UEM measurement.
hence there must be something else here which so far is not revealed yet.
If native action is not excluded in UEM, and "some of these actions only do something in the browser", and these actions are definitely faster than loading a new page. I wonder how these native action speed/time is measurement. This might be the key to the myth.
To measure native action, does UEM apply the same techniques as page load time or different one? or has some built-in if-else deposition? please address this concern.I come up the following two scenarios to explain that different deposition could produce very different measurement, one of the scenario could explain why document load time is higher than total load time
Suppose native action measurement are the same as regular page load and UEM timing do includes native action, and in 100 user actions, 80 of them are native action, its total load time and document load time still conform to regular timing trend (total load time > document load time), 500ms and 400ms respectively; 20 of them are page load action which could be click or touch or scroll, its total load time and document load time are 5000ms and 4000ms. Average for the total load time would be 1400ms, and document load time would be 1120.
Still use the example, but suppose native action does not measure document load time, its total load time would be only 100ms per action henceforth, and average for total load time of 100 samples is 1080ms, and average for document load time of 20 sample still be 4000ms. In this scenario, document load time is higher than total load time.
| Scenario 1: Native action has document load time | 80 native load avg ms | 20 web request avg ms | total average ms |
|---|---|---|---|
| document load time | 400 | 4000 | 1120 |
| total load time | 500 | 5000 | 1400 |
| Scenario 2: Native action skip document load time | |||
| document load time | 0 | 4000 | 4000 |
| total load time | 100 | 5000 | 1080 |
If scenario 2 is true or false, it needs designer to evaluate. if false, "there must be something else here which so far is not revealed yet", as I said above. if true, it does not conform to the user action definition as quotes in the beginning.
I think that not all user actions should derive to a web request. Just imagine a click action that simply opens a popup window on the browser using JavaScript: why does this has to do with a web request?
Second, Total Load Time should me measuring something that not always contents the document rendering (I suppose Document Load Time is the JavaScript execution when struggling with the HTML content and HTML objects around). Example: JavaScript causes to reload the full page. How much time took JS to run? about nothing. And how much the browser to run? well, it can be a huge image, with no JavaScript at all around it, as example. And what about a JavaScript code running a presentation just based in moving images already loaded and cached via CSS at the unique page request at the beginning? Render time can be huge if the animation is not well done, but what is the Total Load Time here? Nothing.
So, if Document Load Time is well measured, I think Total Load TIme is something bad named because it should be measuring a time that would be overlapping totally or partially or nothing (depending on the case) the Document Load Time. So Total Load Time should be reviewed and redefined to really content the Document Load Time as expected.
Nice reasoning, Herman. I think what you described is consistent with what I pointed out. Both total load time and document load time are working in different scenarios and generate different measurement, and don't have to be parent-child related. If this is true, UEM measurement metrics need to be re-categorized
1. total time for actions triggering web request, containing document load time, but not contains onLoad time where onload load additional contents for the parent page
2. total time for native actions. currently I couldn't find such metric in UEM
3. total time for onLoad event where onload load additional contents for the parent page. this was my enhancement request and accepted by UEM DEV team already and open for vote. like you endorse my proposal there.
4. load time or render time, corresponding to load event in W3C chart. Not "load time" in current UEM
The formula below need to be revised and can not be universal one
total load time = unloading DOM time + document load time + load time(rendering content in browser).
And the document I quoted above need to be revised according
All of our discussion are just reasoning, analysis, and I am likely missing something and going on wrong ways. you are welcome to hammer on it
Thanks, Juwei. Now we need to turn this into an RFE.
