Re: Web Smoothness

Just a +1 on this proposal. Developers have long been requesting a means of
collecting accurate rendering performance details from the field. Our
coverage on network these days is great but the rendering side is a
complete black box after you've deployed.  The conversations at EdgeConf in
particular always end up asking where our APIs for collecting rendering
perf stats are.



FWIW, viewable demos of the four links above:
https://rawgit.com/GoogleChrome/websmoothness/master/examples/css_anim.html
https://rawgit.com/GoogleChrome/websmoothness/master/examples/coordinated_anim.html
https://rawgit.com/GoogleChrome/websmoothness/master/examples/scroll.html
https://rawgit.com/GoogleChrome/websmoothness/master/examples/time_to_first_frame.html


On Thu, Sep 18, 2014 at 7:24 PM, Michael Blain <mpb@google.com> wrote:

> Hi all,
>
> Some Chrome folk and I are interested in monitoring the smoothness of web
> pages in the wild. Rendering smoothness is hard to measure with polyfill
> today because most browsers do off-main-thread animations and scrolling.
> Here are some examples of content for which we'd like to get accurate
> rendering smoothness information:
>
>
>    -
>
>    CSS animation with jank checkbox:
>    -
>
>       [
>       https://github.com/GoogleChrome/websmoothness/blob/master/examples/css_anim.html
>       ]
>
>
>    -
>
>       What we want to measure here is FPS of the animation :)
>       -
>
>    Two coordinated animation strategies - CSS and RAF:
>    -
>
>       [
>       https://github.com/GoogleChrome/websmoothness/blob/master/examples/coordinated_anim.html
>       ]
>       -
>
>       What we want to measure here is FPS of the animations :)
>       -
>
>       If the browser is lightly loaded, these two animations should be in
>       sync.
>       -
>
>    Scrollable page with jank checkbox:
>    -
>
>       [
>       https://github.com/GoogleChrome/websmoothness/blob/master/examples/scroll.html
>       ]
>       -
>
>       What we want to measure here is smoothness when a user scrolls :)
>       -
>
>    Click button with a very long time to first frame:
>    -
>
>       [
>       https://github.com/GoogleChrome/websmoothness/blob/master/examples/time_to_first_frame.html
>       ]
>       -
>
>       What we want to measure here is time to first frame.
>       -
>
>       RAF gets us AN answer, but not necessarily the most accurate one.
>
>
> We've found that its very hard to agree on a definition of smoothness
> without knowing a lot about the context and the intent of the web
> developer. By recording events when frames are committed on the main thread
> to the compositor, and then later when they are drawn by the compositor to
> the screen, we don’t have to assume what the developer is intending.
> Instead, we can record the raw data into a timeline, and then let the
> ecosystem create javascript libraries on top that refine the data into
> domain-specific metrics.
> Our initial thought was that the performance timeline would be a great
> place for such information [http://www.w3.org/TR/performance-timeline/
> <http://www.w3.org/TR/performance-timeline/#sec-PerformanceEntry-interface>
> ].
> window.performance.getEntries() returns the ‘mark’ and ‘resource’ timing
> events currently collected by the browser. We could add a
> PerformanceSmoothnessEntry that records each time the compositor updates
> the screen or the main frame sends a change to the compositor. What do
> folks think? Anyone interested in helping us move this forward?
> Thanks!
> Michael Blain
> mpb@google..com <mpb@google.com>
>