Chrome Cut Android Scroll Jank 48%: What to Check on Your Site

A client scrolls a product page on Android and the page hitches, but they blame the phone, the network, or "Chrome is slow." In July 2026 the Chromium team published how they reduced the frequency of janky scrolls in Chrome on Android by about 48% between 2023 and 2026. That work is real, but it still does not remove the cost of your JavaScript on the main thread, your scroll listeners, or UI that shifts while the finger is moving.

Scroll jank is a missed frame during scroll: the screen shows a stale scroll offset for a refresh cycle (about 16.7 ms on a 60 Hz display). Chrome's post focuses on consistent input-to-frame delivery inside a multi-process browser, but your site owns a different slice of the same problem: work that runs while Chrome is trying to produce the next frame. The sections below are a practical checklist for web teams, not a rehash of Input Vizard or Direct2Thread.

What Chrome fixed on Android scroll jank (and what it did not)

Petr Čermák's Chromium write-up describes instrumentation across the input-to-presentation pipeline, then a series of architectural projects: routing input away from a busy browser main thread, waiting briefly for late input after VSync, predicting scroll when input is delayed, cutting cross-process hops, moving browser-controls sync into Viz, and raising priority on Android input threads. The theme is consistency, so raw peak speed is not enough if one stage occasionally spikes and the frame deadline is missed.

None of that rewrites your page, so Chrome still has to run your scripts, apply your styles, and paint your DOM. If a scroll handler forces layout, if a third-party tag runs a long task mid-gesture, or if a sticky bar and an infinite-scroll feed fight for space, users still feel stutter on the same phone that benefits from Chrome's pipeline work. Treat the 48% figure as a browser-side win, but treat residual jank after a Chrome update as a site audit signal.

What is scroll jank on a website?

Scroll jank on a site shows up as hitching, rubber-banding that feels wrong, or content that jumps while the user is still dragging. It is related to, but not identical to, Core Web Vitals. Interaction to Next Paint (INP) measures responsiveness after interactions; Cumulative Layout Shift (CLS) measures unexpected layout movement. Heavy main-thread work during scroll can worsen both, and long tasks that block scrolling also show up as elevated Total Blocking Time (TBT) in lab runs. For metric definitions, see LCP, INP, and CLS explained and Understanding INP.

When a stakeholder says "scrolling feels bad on mobile," separate three causes before you open a hosting ticket:

1. Browser frame delivery (Chrome's domain; improving on Android).
2. Site main-thread and style work during scroll (your domain).
3. Layout that shifts while scrolling (your domain; often CLS).

Only the second and third belong on your sprint board after a Chrome release note.

How to reduce scroll jank: free the main thread during scroll

Chrome's post is blunt that a busy main thread was a major source of non-deterministic delay on the critical path of a scroll. On the web side, the same idea applies, so keep the main thread free while the user is scrolling, or the browser's smoother pipeline still waits on your work.

Long tasks and scroll handlers

Search the codebase for addEventListener('scroll', onscroll, touchmove, and libraries that attach scroll spies by default (analytics "scroll depth," sticky-header kits, parallax, lazy-load managers). For each listener, ask whether the work must run on every frame. Reading offsetWidth, writing styles, and querying layout in the same turn forces synchronous layout and burns the frame budget. Prefer reading positions in one pass, writing in another, or moving visual follow effects to CSS (position: sticky, transform) so the compositor can keep up.

If you only observe scroll position for analytics or lazy loading, register the listener with { passive: true } so the browser does not wait for your handler before continuing the scroll. If you must call preventDefault, you cannot be passive, so keep that handler tiny and defer expensive work with requestAnimationFrame or a short idle callback.

Long tasks from other sources still hitch scroll even when your scroll listener is clean. Third-party tags, hydration bursts, and theme scripts that parse large JSON on the main thread compete for the same thread Chrome needs for input. Our third-party scripts guide covers how to find the worst offenders; for lab blocking time, see FCP and TBT as supporting metrics.

Compositor-friendly motion

Animations and transitions that change top, left, width, or height on scroll tend to force layout and paint. Prefer transform and opacity for scroll-linked effects when you need motion at all. Many "scroll reveal" patterns are nicer as one-shot Intersection Observer callbacks than as continuous scroll math. If a design requires parallax, gate it behind a reduced-motion preference and test on mid-range Android devices, rather than only on a fast laptop with DevTools device mode.

Mobile scroll performance: sticky UI, infinite scroll, and late injection

Mobile scroll performance fails in patterns that look fine in a quiet desktop lab. Sticky headers that resize on scroll, cookie banners that inject after first paint, chat widgets that open over content, and infinite-scroll lists that insert rows without reserved space all create layout work and CLS while the finger is moving. CLS deep-dive covers sizing and late injection, so the scroll-specific rule is simple: do not change layout geometry in response to scroll if you can help it.

Infinite scroll deserves its own check. Each batch of cards should reserve height (skeletons or aspect-ratio boxes) before images and ads arrive. Intersection Observer is usually enough to trigger fetches; a continuous scroll listener that measures every card on every frame is not. After a theme or tag change, re-test the primary feed URL on a real phone or a throttled mobile lab profile, because desktop CrUX can hide the hitch.

Form factor splits matter for monitoring too. Schedule and report mobile separately from desktop, as in mobile versus desktop Core Web Vitals. Chrome's Android work improves one side of the field; your desktop Safari or Chrome desktop users still see whatever your handlers do.

What to check on your site after Chrome's scroll jank fixes

Use this as a pull-request and release gate, not as a one-off audit PDF.

1. List every scroll / touchmove / wheel listener on priority templates (homepage, PDP, article, category feed).
2. Mark each as passive observe, must preventDefault, or removable.
3. Remove or rewrite handlers that force layout (getBoundingClientRect loops, style writes) on every event.
4. Move scroll-linked visuals to CSS sticky / transform where possible.
5. Reserve space for lazy images, embeds, and infinite-scroll rows before they load.
6. Audit third-party tags for long tasks during the first scroll gesture after load.
7. Respect prefers-reduced-motion for decorative scroll effects.
8. Re-run mobile lab (PageSpeed Insights or Lighthouse) on the URLs you changed; store the before/after.
9. Watch INP and CLS field bands on those URLs for the following weeks; do not expect overnight CrUX flips (why field lags lab).

One green Lighthouse paste after a Chrome update is not proof the portfolio is smooth, because spot checks miss the template you did not open. That gap is why PageSpeed Insights versus automated monitoring exists for multi-site teams.

How to monitor mobile scroll performance across a client portfolio

Agencies cannot feel every client's feed on every phone after every plugin update. Put the money URLs (feeds, PDPs, long articles) on a mobile schedule, set budgets on LCP, INP, and CLS, and alert when a release regresses lab vitals even if scroll "feels" fine in the office. Match frequency to risk using how to schedule PageSpeed monitoring.

Apogee Watcher runs scheduled PageSpeed Insights-backed tests across many sites, keeps mobile and desktop as separate strategies, and stores history so you can show before/after when a sticky header or tag manager change lands. We do not claim a dedicated "scroll jank" metric in-product, but we give you the Core Web Vitals and supporting lab timings that move when main-thread and layout cost during scroll get worse, across the portfolio without pasting PageSpeed Insights links into a spreadsheet. Layer Watcher beside RUM or session replay when you need gesture-level proof on a single flagship site.

FAQ

Did Chrome fix scroll jank so sites no longer need to care?

No. Chrome reduced how often its own pipeline misses frame deadlines on Android, but your scroll handlers, long tasks, and layout shifts during scroll still run on the page. Browser gains and site work stack; they do not replace each other.

Is scroll jank the same as poor INP or CLS?

Not exactly: scroll jank is missed frames during scroll, while INP scores interaction latency and CLS scores unexpected layout shift. The same main-thread and layout habits often drive all three, so fixing scroll handlers and reserved space usually helps the vitals you already report.

How do I find scroll listeners that hurt mobile scroll performance?

Search the bundle and third-party tags for scroll and touch listeners, then profile a mid-range Android device (or a throttled lab profile) while scrolling the money URL and watch for long tasks and forced layout in Performance traces. Start with themes, sticky headers, analytics scroll depth, and infinite-scroll libraries.

Should we re-test after every Chrome release?

Re-test after your own releases first; when Chrome announces scroll or input pipeline changes, spot-check one or two mid-range Android devices on a priority URL, then rely on scheduled mobile monitoring for the rest of the portfolio rather than a manual PageSpeed Insights day.

---

On Monday, pick one client feed or article URL that drew a "scrolling feels bad" comment. Open the Performance panel, scroll for ten seconds on a mobile profile, and list every long task and layout shift during that gesture. Fix or remove one handler, reserve space for one late-loading block, then store a mobile lab run. If you manage many sites and need that history on a schedule, start a free trial of Apogee Watcher or run a free domain PageSpeed check on the URL that complains most on phones.