Re: Input Delay Metric proposal

>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 i

Re: Input Delay Metric proposal

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 don

Re: Input Delay Metric proposal

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

Re: Input Delay Metric proposal

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

Re: Input Delay Metric proposal

Hi Randell, The last part of your email where you suggested this metric could be proposed for the Performance API WG confused me a bit about its goals. It seemed to me from the description earlier that the goal behind MID is to provide a metric useful for browser engineers who would like to measu

Re: Input Delay Metric proposal

[cc+ Heather for perceived performance] Hi Randell, I think I like this and I'm glad you are thinking about it. Measuring time between TTI and FCP seems useful to me. You touched on a bunch of my questions in the Issues section and I don't have answers but others might? :) Cheers, David On We