For in-the-wild input delay not specifically during pageload we also measure INPUT_EVENT_RESPONSE_DELAY_MS[1] and (from Firefox 53-60 and then resuscitated in 64) INPUT_EVENT_RESPONSE_COALESCED_MS[2] which record[3] from the time the OS created the input event until the time when the process is done with the event.
So, for content processes it measures the time from when the OS creates the input event, then the length of time it remained undelivered with the OS, then the length of time it remained unhandled in the parent process, then ipc time, then the length of time it remained unhandled on the content process, and then the length of time it took to be processed by the content process (which, IIRC, includes synchronous JS event handlers). It didn't attempt to measure how long our style and layout engines would take to manipulate structure and presentation and how long our rendering and compositing machinery would take to raster it to the screen so a user could see any visible results, but it was the closest thing to a holistic "how long between the user trying to do something have we actually completed doing that something?" measurement we had at the time (around the more-modern e10s timeframe (Firefox 44) and, for the COALESCED variant, around the Quantum timeframe) (The COALESCED variant is trying to capture a more relevant sampling of jank magnitude with the idea that multiple input events during a time when input events are just queueing isn't a good unit of user frustration with responsiveness. It coalesces any overlapping input events so that an OS serving us 20 keypresses during a sync GC or other jank incident counts as a single sample instead of 20 of them. In practice this results in an order of magnitude fewer samples in the histogram.) (There were also variants for measuring user-experienced jank during and after application startup, but they weren't used as much) Adding a variant that is only recorded between FCP and TTI would give us yet another number we could consider... but something tells me that having more numbers isn't necessarily a solution at this point :) :chutten [1]: https://mzl.la/2N0ECHy [2]: https://mzl.la/2N2QMiT [3]: https://telemetry.mozilla.org/probe-dictionary/?search=INPUT_EVENT_RESPONSE On Fri, Sep 21, 2018 at 11:30 AM <tdres...@chromium.org> wrote: > On Chrome, we've played around some with TTI-FCP. > > Another metric we've experimented a bit with is the length of the longest > long task between FCP and TTI. You can think of this a bit like the "Max > FID" - if someone tapped at the worst possible time, what would the FID be. > > We've also played some with Expected Queueing Time ( > https://docs.google.com/document/d/1Vgu7-R84Ym3lbfTRi98vpdspRr1UwORB4UV-p9K1FF0/) > between FCP & TTI, which sounds similar to the MID proposal above. > > For delays during page load, I think focusing more on the worst case makes > sense, so I lean towards something along the lines of the longest long task > between FCP & TTI. > > We did a correlation study between FID, TTI and the longest long task > between FCP & TTI. The longest long task approach correlated very slightly > better with FID than TTI. We haven't run the correlation study on EQT > between FCP & TTI, but I'm pretty confident it won't perform as well. > > Tim > > On Thursday, September 20, 2018 at 10:42:55 AM UTC-4, Ted Mielczarek wrote: > > On Wed, Sep 19, 2018, at 2:42 PM, Randell Jesup wrote: > > > Problem: > > > Various measures have been tried to capture user frustration with > having > > > to wait to interact with a site they're loading (or to see the site > > > data). This includes: > > > > > > FID - First Input Delay -- > > > https://developers.google.com/web/updates/2018/05/first-input-delay > > > TTI - Time To Interactive -- > > > > https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics#time_to_interactive > > > related to: FCP - First Contentful Paint and FMP - First Meaningful > > > Paint -- > > > > https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics#first_paint_and_first_contentful_paint > > > TTVC (Time To Visually Complete), etc. > > > > > > None of these do a great job capturing the reality around pageload and > > > interactivity. FID is the latest suggestion, but it's very much based > > > on watching user actions and reporting on them, and thus depends on how > > > much they think the page is ready to interact with, and dozens of other > > > things. It's only good for field measurements in bulk of a specific > > > site, by the site author. In particular, FID cannot reasonably be used > > > in automation (or before wide deployment). > > > > > > Proposal: > > > > > > We should define a new measure based on FID name MID, for Median Input > > > Delay, which is measurable in automation and captures the expected > delay > > > a user experiences during a load. We can run this in automation > against > > > a set of captured pages, while also measuring related values like FCP > > > and TTI, and dump this into a set of per-page graphs (perhaps on > > > "areweinteractiveyet.com" :-) ). > > > > > > While FID depends on measuring the delay when the user *happens* to > > > click, MID would measure the median (etc) delay that would be > > > experienced at any point between (suggestion) FCP and TTI. I.e. it > > > would be based on "if a user input event were generated this > > > millisecond, how long would it be before it ran?" This would measure > > > delay in the input event queue (probably 0 for this case) plus the time > > > remaining until he current-running event for the mainthread finishes. > > > > FWIW, this sounds very similar to the responsiveness metric I > implemented years ago that was intended to be used for the (original) e10s > work: > > > https://dxr.mozilla.org/mozilla-central/rev/ac9f1219d11bf1a56ec1ace8e3ba9ff113b5cacb/toolkit/xre/EventTracer.cpp#5 > > > > We still run this code in Talos as "tp5o responsiveness": > > > https://treeherder.mozilla.org/perf.html#/graphs?series=mozilla-central,1538194,1,1&series=mozilla-central,1538732,1,1 > > > > The summary metric is a little complicated as we're combining a bunch of > samples, but it does measure the delay from when input events are generated > until they are serviced in the event loop. > > > > -Ted > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
