On Friday, March 31, 2017 at 1:38:25 PM UTC-7, Josh Matthews wrote: > Oh, and as for how I expect they'll be implemented: > > Time to interaction sounds straightforward to me - on a > per-script-thread basis, track the start of the last 10s window that did > not contain a task that took longer than 50ms to execute. Whenever at > least 10s has gone by since the start of this window, scan the set of > contained documents that have not yet had a timestamp recorded. If any > of them have dispatched the DOMContentLoaded event, mark their TTI > timestamp as max(DOMContentLoaded time, start of 10s window). If a task > takes longer than 50ms, reset the start of the window to the current > timestamp. > > The painting ones are interesting, because the spec text is roughly > equivalent to the creation of display list items for the things we care > about. However, since that happens in parallel with returning control to > the script thread, it's not totally clear where to stop measuring. An > easy place to start is to send a message to the profiler directly from > the layout thread after notable display list items are created. However, > the spec is concerned about when control returns to the script thread > event loop, and I have not been able to come up with a good mechanism to > report that timestamp while allowing the layout thread to continue > creating display lists in parallel. > > Cheers, > Josh > > On 2017-03-31 4:18 PM, Josh Matthews wrote: > > Back in September, Till shared an update [1] from dev-platform about the > > Progressive Web Metrics that the Blink team is championing. I've been > > looking into how that effort is going in Firefox and Blink, and whether > > we should be adopting some of them. > > > > Overview: > > We should implement the Time to First Paint, Time to First Contentful > > Paint, and Time to Interactive measurements, focusing on integrating > > them with fitzgen's graphical profiler tool. The specifications make use > > of the PerformanceObserver web API which we don't implement yet; if > > we're keen on using these measurements to compare testcases against > > other browsers, we should rectify that. It will not make it easier to > > compare measurements for arbitrary web content, however. > > > > Long form: > > In brief, some of the measurements have pretty clear definitions and > > would be worth integrating into Servo in Q2. Others are still being > > hashed out and wouldn't clearly provide value to us at the moment. > > > > Time to First Paint and Time to First Contentful Paint [2] are > > conceptually straightforward. Respectively, they measure the number of > > milliseconds before the browser paints anything that is not the default > > white background, and the time before the browser paints any text, > > image, non-white canvas, or SVG. > > > > Firefox has already implemented Time to First Paint [3]. I think we'll > > get the most value out of this measurement by focusing on the > > interaction with our graphical profiler timeline tool, rather than the > > integration with the new PerformanceObserver API [4]. > > > > Time to Interactive takes a different path. It attempts to measure the > > amount of time before a page is ready for interaction, and has low > > enough latency for meaningful interaction to occur. It tracks 10 second > > windows in which no script thread task takes longer than 50ms to > > complete. If a task takes longer, then the window is reset. To determine > > readiness, the official write-up [5] uses the Time to First Meaningful > > Paint metric (not discussed here), but there have also been experiments > > using the DOMContentLoaded event for this purpose (ie. the page has > > finished parsing). I propose implementing an initial version of this > > metric in Servo using DOMContentLoaded as the signal. > > > > Together, these metrics will give us information on the graphical > > timeline showing: > > * how long after a page was requested before the first visual change > > occurred > > * how long after that before the first nontrivial visual content appeared > > * how long after the page was requested before it was in a state that > > could respond to user input with low latency > > > > If there are no objections, I intend to make implementing these part of > > our Q2 goals. > > > > Cheers, > > Josh > > > > [1] > > https://groups.google.com/d/msg/mozilla.dev.platform/Ot43qpeWyos/x20WdRnxBAAJ > > > > [2] https://github.com/WICG/paint-timing#definition > > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1307242 > > [4] https://w3c.github.io/performance-timeline/#dom-performanceobserver > > [5] https://github.com/tdresser/time-to-interactive
Excited to see PWMs moving forward in Servo! I am advocating for the these metrics for Quantum and we'll use them to measure progress as much as we can for the MVP release and definitely more after that. What is definitely missing from the list is Meaningful Paint [1], which is in flight for Firefox [2] and used as reference for TTI. TTI got backlogged but I have high hopes for it [7]. Chrome team published some interesting manual tests [3] on different algorithms. Expected Queueing Time [4] was planned to be used for TTI to measure how available the event queue is. Frame Throughput [5] is a bit further out as it seemed very Blink specific to some. Firefox took a different approach for now [6]. Feel free to reach out if I can help anything else around these metrics, as I spend some time already wrapping my head around them. /Harald [1]: https://docs.google.com/document/d/1BR94tJdZLsin5poeet0XoTW60M0SjvOJQttKT-JK8HI/view# [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1299117 [3]: https://groups.google.com/a/chromium.org/forum/#!topic/progressive-web-metrics/G83qR5CR1kg [4]: https://docs.google.com/document/d/1b9slyaB9yho91YTOkAQfpCdULFkZM9LqsipcX3t7He8/edit# [5]: https://docs.google.com/document/d/1Bot91txCWZUstt32_BBLo-_HUsvOVn_L5yaI5xre2M0/edit [6]: https://bugzilla.mozilla.org/show_bug.cgi?id=1338347 [7]: https://bugzilla.mozilla.org/show_bug.cgi?id=1299118 _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
