Selection of Smoothness Metrics for Baidu App: Scenarios, Thresholds, and Calculation Methods

In the first part of the series, the necessity of smoothness monitoring and industry metrics were introduced. This second part focuses on the selection of smoothness indicators for the Baidu App.

1. Unsmooth Scenarios and Weight Considerations

Testing on Baidu App web‑browsing reveals two types of unsmooth issues: "jitter/frame drop" and "stutter". An illustrative pointer‑movement example shows how ideal 16.6 ms frames translate into observable jitter or stutter.

1.1 Jitter/Frame Drop

The frame‑length sequence is two ideal frames (16.6 ms) followed by three frames each covering two ideal frames (33.2 ms). The pointer moves as 0,1,1,2,2,4,4,6, which feels like a brief pause (frame drop) that manifests as page jitter during scrolling.

1.2 Stutter

The frame‑length sequence is two ideal frames (16.6 ms) followed by one frame covering six ideal frames (99.6 ms). The pointer moves as 0,1,1,1,1,1,2, giving the impression of a sudden halt (stutter) followed by a jump.

Both issues affect user experience equally in duration, so the monitoring system aims for a fair recall of both.

2. Threshold Selection for Stutter Detection

Based on long‑term testing, two thresholds were proposed:

30 ms (≈1 dropped frame) – produces mild jitter; a 1 s frame‑length series of [33,33,33,…] is not visibly jarring but causes overall page shake during animations or manual scrolling.

70 ms (≈3 dropped frames) – produces noticeable short‑term stutter; a series like [16.6,16.6,16.6,…,70,80,90] makes the last three frames feel paused then resumed.

Demo experiments showed that five consecutive 30 ms frames are clearly felt as jitter, while a single 70 ms frame is clearly felt as a pause.

Consequently, the final monitoring thresholds are set at 30 ms and 70 ms, defined respectively as “jank” (>30 ms) and “major jank” (>70 ms). These thresholds allow separate focus on mild jitter and severe stutter while maintaining fair recall.

Reference is made to Zhu Shaomin’s research on response delay and completion delay for more precise threshold derivation.

3. Selection of Smoothness Metric – Per‑Second Converted Jank Rate

Excluding FPS due to its drawbacks, several candidate metrics were evaluated. Assuming a 30 ms jank threshold, the following definitions were used:

Long frame = jank

Jank time = sum of long‑frame durations within 1 s

Converted jank frames = jank time / 16.6 ms

Per‑second converted jank rate = converted jank frames / 60 = jank time / 1000 ms

Comparative tables (shown in the original figures) demonstrated that this metric yields values bounded between 0 % and 100 %, facilitating intuitive interpretation.

Thus, the “per‑second converted jank rate” (jank time in ms per second divided by 1000) was selected.

4. Stage‑Based Smoothness Metric – Stage Converted Jank Rate

To align with monitoring recommendations of separating scenes and stages, a stage‑level metric was defined:

Stage converted jank rate = stage jank time / stage total time = (stage jank time / 1000 ms) / (stage duration in seconds) = average of per‑second converted jank rates within the stage.

Practical considerations (incomplete 1‑second intervals, need for zero‑value uploads) led to adopting the stage‑converted jank rate as the final metric for Baidu App.

Reference Materials

Tencent PerfDog: Performance monitoring documentation.

Zhu Shaomin: “How to Obtain Real Quality of Smart Terminals” – research on response and completion delays.