Audit: Content scrolls at 60fps

[paulirish]

What we want:

• Ability to scroll/fling the page as similar to a mobile scroll/fling as possible
• Gather data from trace and compute a Frame Throughput (crbug) or other similar smoothness metric

A very nice PR from @surma was put up in https://github.com/GoogleChrome/lighthouse/pull/469 Since this PR, we've done a lot of work internally to handle gathering a second trace and passing it off correctly, so we're in better shape now.

[tdresser]

If you're looking for a scroll specific metric, are you wanting latency, or throughput?

You can scroll at 60fps with 500ms of lag.

If you're focused on scroll currently, I think looking at latency first might make more sense, and then if you want to cover animations in general, you can follow up with Frame Throughput (and hopefully we'll have a FT metric you can use by then).

For simulation, ideally you'd use the incredibly poorly named "GPU benchmarking extension", by passing the --enable-gpu-benchmarking flag. That isn't going to be possible though, is it?

If not, any thought on how you're going to simulate the input?

[paulirish]

For reference -- the current Frame Throughput metric proposal: LatencyInfo Based Frame Metrics

[paulirish]

The Graphics.Smoothness.PercentDroppedFrames.AllSequences UMA metric is pretty interesting.

Tracks the percent of dropped frames for a particular sequence of frames. This metric is reported for all animations and all interactions.

PercentDroppedFrames is measured by tracking the number of frames which were not displayed on screen out of the total number of frames expected to be produced and displayed. In other words, the lower this number is, the smoother experience.

Note that this metric is reported only when there are sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until there are enough frames to produce the metric.

(more active crbug around this)

[paulirish]

A trace event indicating a dropped frame is now available: https://chromium-review.googlesource.com/c/chromium/src/+/2169848

Here's the related design doc for the devtools perf panel feature: Dropped Frames: Chromium DevTools Design Doc

[connorjclark]

UMA for Graphics.Smoothness.PercentDroppedFrames.ScrollingThread.TouchScroll (dropped frames) https://uma.googleplex.com/p/chrome/timeline_v2?sid=662b79caed1281e61b292c5c48d9bea2

Bug tracking attribution: https://bugs.chromium.org/p/chromium/issues/detail?id=1086974

The "Frame Throughput" metric will wait until after TTI to begin measurement. Would it make sense to do the same here for dropped frames? Wait to simulate scrolling until after TTI. but don't actually filter the dropped frames events, as we should include any dropped frames caused by the page scrolling by itself (idk seems like a thing a site might do).