Google today detailed how it reduced scroll jank in Chrome for Android by 48% between 2023 and 2026.

Scroll jank refers to sudden page stutters or jumps. It occurs when a “device fails to present a frame containing an updated scroll offset on time.” This effort to tackle “one of the biggest disruptors of a great mobile web experience” started in 2023.

Smooth scroll (left) vs. janky scroll (right)

Chrome has a strict deadline to deliver each frame before the screen refreshes. If a delay pushes the processing of a frame past this deadline, the screen is forced to display a stale scroll offset for an entire refresh cycle—roughly 16.7 milliseconds on a 60 Hz display. The human eye perceives this missed frame as a jarring, jerky stutter. 

Change in frequency of janky scrolls in Chrome on Android between 2023 and 2026

To avoid this, Chrome’s input-to-frame delivery must be consistent, or “every scroll update must take the same time to be presented on screen.” Compared to a regular Android app, Chrome has separate browser, renderer, and GPU processes that improve stability, security, and performance, but exacerbate scroll jank.

When the user touches the screen in Chrome, the hardware generates an input event, which doesn’t just go to one thread or even one process. It first arrives in the browser process for hit testing and gets forwarded to the renderer process to calculate the new scroll offset. VSync signals follow a different path, also across multiple processes. They arrive on the Viz compositor thread in the GPU process and get forwarded to the renderer process, which matches them with input events to draw a new frame. The frame is then sent to the GPU process to produce pixels in a GPU buffer, which the OS finally displays on the screen. To make things even more complicated, Chrome consumes unbuffered input directly from the hardware. This means that input events arrive in Chrome at irregular intervals, often multiple times per refresh cycle.

Given the multi-process pipeline, Google started several projects to reduce scroll jank across “automated heuristics, targeted optimizations, and deep architectural shifts.” Efforts include:

• Input prediction: An input event from the OS can sometimes be so delayed that even Input Framer’s grace period isn’t enough. Extending the grace period even further isn’t an option because it would increase the risk that Chrome wouldn’t be able to produce the frame on time. Instead, if the OS hasn’t delivered any input events by the deadline, Chrome creates its own synthetic scroll update and predicts the future scroll position based on the scroll curve that it has observed so far.
• Browser controls in Viz: When a user starts scrolling down a website on Android, the browser controls slide out of the viewport in lockstep with the website that’s being scrolled. The synchronized movement of the two surfaces used to involve the browser main thread in every single frame, so there were plenty of opportunities for visual hiccups. We changed the architecture so that the GPU process could apply each frame’s scroll offset to the screenshot of the browser controls without talking to the browser main thread.

• Priority of Android input threads: A chain is only as strong as its weakest link. A pipeline is only as fast as the dependency with the lowest priority. We found that input events sometimes took too long to reach Chrome because the relevant OS threads were preempted by other, lower-priority work. We worked with Android to make sure that all threads responsible for delivering hardware input to Chrome have a sufficiently high priority.