Chrome on Android Smoother Scrolling: How Google Cut Jank by 48%

Chrome on Android scrolls nearly half as janky as it did three years ago. Google today published its most detailed account of how that happened, and the headline figure is specific: janky scroll frequency dropped 48% between 2023 and 2026, according to the Google Chromium blog. That metric measures how often Chrome fails to update the display before the screen refreshes a narrow, concrete definition, not a general claim about the browser feeling faster.

The improvement didn't come from a single release or a performance tuning pass. Google framed the work as an architectural overhaul: moving scrolling off legacy main-thread paths and onto lower-latency compositor and GPU-side handling. The changes took three years and multiple iterations to accumulate.

One caveat up front: the 48% figure is self-reported by Google's engineering team. Google did not publish an independent benchmark alongside the post. The technical specificity is unusually high for a blog post and the methodology is coherent, but it remains Google's own measurement until external verification exists.

Why browser scrolling is harder than app scrolling and how Google learned to see the problem

A native Android app typically handles input on its main thread, giving it a direct, predictable path from finger to screen. Chrome can't do that. Its scroll path is a multi-process pipeline: touch input arrives from hardware, travels through Android OS threads, crosses process boundaries, passes through browser and renderer processes, and eventually reaches the GPU. Each handoff is a potential delay.

On a 60 Hz display, the entire frame budget is 16.7 milliseconds. Miss that deadline and Chrome is forced to show a stale scroll position for a full refresh cycle enough time for a user's finger to visibly outpace the page, per the Google Chromium blog. A delay at any single stage cascades through every subsequent step.

Google's first move wasn't to fix anything. It was to instrument every stage of the pipeline, from hardware input generation to GPU buffer presentation, using Perfetto trace events. Manual trace review didn't scale, so the team built a library of PerfettoSQL queries that automatically extracted pipeline data for each scroll update and applied heuristics to tag the likely cause of jank frame by frame. Any pipeline stage that consumed more than one full refresh cycle got flagged as a likely culprit.

That tooling is what made three years of iterative improvement possible. Google's 2023 public commitment was to eliminate root causes rather than patch symptoms and what followed was, by Google's own description, several iterations before arriving at the result announced today.

How Google reduced scroll jank in Chrome on Android: five architectural changes

With frame-level visibility into the pipeline, Google could pinpoint where the structural bottlenecks actually sat. Five changes make up the core of the redesign.

Input Vizard addressed the most fundamental problem. Chrome was receiving input events on the browser's main thread, where any long-running task could cause delays. The fix moved both input events and VSync signals to the Viz compositor thread inside the GPU process, per Google. Chrome now handles the two things it needs most urgently during a scroll knowing where the finger is and knowing when the screen refreshes in a place that's much harder to preempt. Google described this as bringing Chrome one step closer to the single-thread input handling model used by a standard Android app.

Direct2Thread removed a different category of overhead. Cross-process communication in Chrome had historically required messages to hop through intermediate IO threads before reaching their destination. Google eliminated that routing requirement on the scroll's critical path, cutting both the latency and the unpredictability between an input event arriving and its effect appearing on screen, the blog post explains.

Android OS thread priority took the fix outside Chrome entirely. Google found that OS threads responsible for delivering hardware input to Chrome were sometimes being preempted by lower-priority background work, meaning input never reached Chrome on time regardless of what the browser itself was doing. Google worked with the Android team to raise those threads' priority an improvement that required coordination at the OS level rather than within the browser.

Browser Controls in Viz shifted responsibility for synchronizing toolbar and webpage movement during scrolling from the browser's main process to the GPU process, removing a coordination delay that could cause the two to drift out of sync.

Input Framer and input prediction address a different class of problem: jank that originates in the OS rather than inside Chrome. Input Framer modified Chrome's renderer to wait up to one-third of the refresh cycle after a VSync signal before generating a frame, giving late-arriving input events time to show up. Without it, Chrome would produce a frame with no scroll update visually indistinguishable from jank even though nothing inside Chrome was slow.

When even that grace period isn't enough, input prediction takes over. If the OS hasn't delivered any input by the deadline, Chrome generates a synthetic scroll update, estimating the page position based on the scroll trajectory it has observed so far, rather than displaying the last known position, according to Google. A slightly wrong position is less disruptive than a visible freeze.

Google's description of Android web performance as "a game of milliseconds" is precise rather than promotional. These timing decisions are calibrated to fractions of a 16 ms window.

What this means, and what Google still hasn't said

Chrome on Android scrolls more smoothly today because Google changed where scrolling lives inside the browser not because it pushed a performance flag or tuned a parameter. Google framed the work as an architectural overhaul rather than a tuning pass, and the five named changes support that characterization.

The work sits inside a broader pattern. Four months ago, Google claimed Android had become the fastest mobile platform for web browsing, citing gains achieved through deep vertical integration across silicon, the Android OS, and Chrome in concert, per the Chromium blog. The OS thread-priority fix in the scroll pipeline is a direct expression of that same approach: improvements that required Chrome and Android teams to coordinate beyond any single product boundary. Speedometer benchmark scores carry a strong negative correlation of -0.8 with 99th-percentile interaction latency in real-world field data, the same post notes, suggesting Chrome's broader performance gains translate into the fluid experience users actually feel.

What Google didn't disclose: The post doesn't specify which Chrome versions shipped each of the five named improvements, or how the gains distribute across mid-range and older Android devices versus current flagships. There's no breakdown of which individual change contributed most to the 48% reduction, and no discussion of whether the architectural changes carry tradeoffs in battery draw, memory consumption, or thermal behavior. Google published a top-line gain and a methodology; it did not publish a per-version rollout schedule or a per-device impact analysis. For most users, the practical question whether their phone has actually benefited remains unanswered.