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
