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
