Using onload from chrome to measure pageload doesn't measure the right thing

[Boris Zbarsky]

Our current test framework for talos
(layout/tools/pageloader/pageloader.js) uses the load event to decide
when the page load is done.  It uses a capturing handler, because the
load event doesn't bubble (even to the chrome event handler) and isn't
redispatched on the frameElement if the frameElement is chrome.  See bug
390263.

This means that the talos end-of-pageload timing ends before the onload
handlers on the page, if any, fire.

We could fix that by fixing bug 390263 and then changing to a bubbling
listener, but that would still leave a significant problem.  If pageload
takes less than 250ms, then we fire the load event before unsuppressing
painting.  This makes sense, because the load event could trigger
invalidates, and we want to ignore them if we're about to invalidate the
whole viewport anyway.  That said, removing paint suppression shows the
document viewer, which runs a fair amount of bfcache-related code.  In
particular, it currenly performs bfcache eviction and freezing of the
previous page for bfcache purposes.  These tasks take on the order of
20-30ms on some of our Talos pageset pages; a lot less on others.  The
time it takes to perform these tasks is thus not included in the
pageload time by talos... but only if the pageload of the _curent_ takes
less than 250ms.  Otherwise it is.  Note that this means that the order
of pages in the pageset can affect the timing significantly.

The key issue here is that from the user's point of view the new page
hasn't loaded until we've unsuppressed painting.  Until then, we're
showing the previous page.  So for quick pageloads what talos is
measuring has little bearing on what we want to be measuring.

The question is what we want to do about this, if anything.  It's pretty
easy to add an event that we fire at the chrome event handler in those
cases when we fire onload.  We could fire this event after onload and
pageshow, and after painting has been unsuppressed.  Talos could then
listen to this event and use it as its end-of-load indicator.
Alternately, talos could fire load end from a timer (not setTimeout, but
nsITimer) it sets in onload or an event it posts to the event queue in
onload.  Both of these load end shifting approaches have issues if the
event queue is full at that point, of course, and the issues with
nsITimer not working that great for small timer delays (under 16ms on
Windows, last I checked).  Both using a new event and using an
nsIRunnable on the main thread event queue would let us include the time
taken to process whatever events the invalidate posted.  Not sure
whether we want to include this in our Tp time, of course.  It might
also be possible for talos to flush painting before taking its timings;
roc would know more about this.

I'd welcome any thoughts on this matter.

-Boris
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance