Chrome Halved Android Scroll Jank, but Rivals Can’t Follow

Chrome on Android now stutters 48% less than it did in 2023, the result of three years spent rewiring how the browser talks to Android itself. Google detailed the work in a July 23 Chromium engineering blog post, tracing six separate fixes built between 2023 and 2026.

Two of those six fixes did not touch Chrome’s code at all. They changed Android’s own operating system, something only Google can do for its own browser. Samsung Internet, Firefox for Android and Microsoft Edge run on the same phones and the same version of Android, with no announced way to get the same treatment.

The 16.7-Millisecond Deadline

Scroll jank has a precise technical definition. It happens when a phone fails to display an updated scroll position before the screen’s next refresh. On a standard 60 Hz display, that refresh happens roughly every 16.7 milliseconds. Miss it, and the screen shows a frozen frame for an entire extra cycle. The eye reads that freeze as a jerky stutter.

Every scroll animation needs two ingredients: input events that report where a finger is touching the screen, and VSync, the timing pulse Android sends once per refresh cycle to tell an app it is time to draw the next frame. A typical Android app gets both on a single thread in a single process, then draws.

Chrome cannot do that. It runs separate browser, renderer and GPU processes, a design built for security and stability. A touch event has to travel from the browser process, which checks where on the page it landed, to the renderer process, which calculates the new scroll offset. VSync signals arrive on a different thread in the GPU process and have to be matched up with those input events before a frame can be drawn. Chrome also takes input straight from the hardware, unbuffered, so events land at irregular intervals rather than neatly once per cycle.

Any hop in that chain can run long. Google’s engineers put it plainly in the post: raw speed was never the hard part. Consistency was.

How Chrome Rebuilt the Path From Finger to Pixel

To find where the pipeline was actually breaking, Chrome’s team instrumented every stage of it, from the moment hardware generates a touch event to the moment pixels leave the GPU buffer, using Perfetto trace events. They built a library of PerfettoSQL queries that turn each scroll update into a single row of data, then wrote heuristics to automatically tag frames with likely causes of jank.

That visibility fed a repeating loop: find a cause in the traces, build a fix, launch it as an A/B experiment, and roll out whatever worked. Six projects came out of that loop.

Most of this shipped with no settings toggle for anyone to find, the same quiet approach Chrome took when it folded a four gigabyte AI model into desktop installs. Users simply got a version of Chrome that stutters less.

Why Did Android Itself Have to Change?

Two of Chrome’s six scroll fixes changed Android’s own code, beyond the browser’s code alone. Chrome’s engineers asked Android’s platform team to reroute input events around the browser’s busiest thread and to raise the priority of the operating system threads that carry touch data to Chrome.

We worked closely with Android to allow routing input events to another process.

Google’s Chrome team wrote that describing Input Vizard, the project that pulled input handling off the browser’s main thread entirely. The team used almost identical language for the thread-priority fix, saying it worked with Android to make sure every thread responsible for delivering hardware input to Chrome runs at sufficiently high priority.

Both changes required cooperation from the people who build Android, not just the people who build Chrome. At Google, those happen to be the same company.

Left Out on the Same Phones

Chrome is not the only browser running on Android hardware. It is simply the only one whose maker also builds the operating system underneath it.

• Samsung Internet – the largest non-default mobile browser worldwide, holding a 2.81% share of global mobile browsing per Statcounter data, preloaded on every Galaxy phone but outside this specific Android partnership.
• Firefox for Android – runs Mozilla’s own Gecko engine rather than Chrome’s, so it never shared this architecture in the first place.
• Microsoft Edge – built on the open-source Chromium project, the same code Chrome itself is built on, yet still outside the Android-side changes Google made.
• Opera – another Chromium-based browser on Android, dependent on whatever input handling Android exposes to ordinary apps rather than to Chrome specifically.

That last distinction matters. Edge and Opera share Chrome’s open-source rendering code, so renderer-side fixes like Input Framer or Input Prediction could eventually reach them if Google upstreams that code for anyone to use. The Android-side changes are different. Thread priority and input routing are properties of the operating system itself, and nothing in Google’s post says whether any app besides Chrome gets the same treatment.

Google has drawn a similar line elsewhere on Android. Its device management platform recently limited Headwind MDM’s self-hosted Android pitch, another case where an outside company ran into how much control Google leaves available on its own platform.

Google Solved a Version of This in 2012

Google has fought jank before, at a bigger scale. Android 4.1, known as Jelly Bean, arrived at Google I/O in 2012 carrying an update called Project Butter. It used touch anticipation, triple buffering and extended VSync timing to make the entire operating system feel smoother, not one app at a time.

The difference is who got to keep the fix. Project Butter was a platform change that lifted every app running on Jelly Bean, including whatever browser a user had installed. The 2023 to 2026 push is a platform change too, but one built specifically to solve Chrome’s own multi-process bottleneck. It is not a general capability sitting in Android for any developer to call. It is plumbing built for one browser, by the company that owns the pipes.

Google Built One of Its Own Yardsticks

In March 2026, Google announced that Android and Chrome had set new records for mobile web performance, a claim reported at the time by 9to5Google as resting on two tests, Speedometer and LoadLine.

Speedometer simulates real-world actions like typing and scrolling to measure interaction latency, and it is used by every major browser engine, not just Chrome’s. LoadLine is newer and less widely adopted. Phandroid noted at the time that Google ran the tests itself, and that one of the two benchmarks behind the claim is Google’s own creation.

Google’s broader interest in interaction speed shows up elsewhere too. Interaction to Next Paint, a metric measuring how fast a page responds to a tap or keypress, became a stable Core Web Vital in the Search ranking program Google runs for the entire web, not just its own browser.

Here is what that leaves settled and unsettled about the 48% figure and the record that followed it.

What We Know

• Google measured the 48% drop in janky scrolls itself, using its own Perfetto-based instrumentation across the 2023 to 2026 period.
• The March 2026 speed record rests on Speedometer, a cross-industry test, and LoadLine, a newer benchmark.
• Two of the six fixes required changes to Android’s operating system code, not just to Chrome.

What’s Unconfirmed

• Whether an independent lab using only Speedometer, without LoadLine, would rank Android and Chrome the same way.
• Whether Samsung Internet, Firefox or Edge on Android will ever receive the same input-routing or thread-priority changes.

The fix and the record both came from measurements Google ran on its own phones, its own browser and its own test.

Frequently Asked Questions

Is scroll jank the same as a low frame rate?

No. A phone can average a high frame rate overall and still jank, because jank is about timing consistency for a single frame, not the average speed across many frames. Google’s own definition ties jank to one missed deadline at a time, when a device fails to present an updated scroll position before a specific refresh.

Does this fix reach Chrome on iPhone too?

No. The projects described in Google’s post, including Input Vizard and the Android thread-priority change, target Android specifically. Chrome on iPhone runs on a different technical foundation tied to Apple’s own rendering engine requirements, separate from the multi-process Android pipeline described here.

Do I need to update Chrome to get the smoother scrolling?

Most of it should already be present on a reasonably current version of Chrome for Android. Google’s post describes rolling each fix out gradually as an A/B experiment before launching it to 100% of users, so the improvements arrived in stages over 2023 to 2026 rather than in one single update.

What is Perfetto?

Perfetto is the tracing tool Chrome’s engineers used to record every stage of the scroll pipeline, from the hardware generating a touch event to pixels leaving the GPU buffer. It let the team build automated heuristics that tag individual frames with their likely cause of jank instead of reviewing traces by hand.

Could other Android browsers eventually get the same fixes?

Partly, maybe. Chromium-based browsers like Edge and Opera share Chrome’s open-source rendering code, so renderer-side work such as Input Framer could reach them if Google upstreams it. The Android operating system changes, thread priority and input routing among them, are a different matter, since those depend on cooperation with Android’s platform team that Google has not described extending beyond Chrome.