Web Smoothness

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