Why would you add { passive: true } to a scroll or touchstart listener, and what problem does it solve for scroll performance?

Q: Why would you add { passive: true } to a scroll or touchstart listener, and what problem does it solve for scroll performance?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The core "does preventDefault() do anything in a passive listener" claim below was actually run and checked, not assumed. ## 1. Why This Even Matters — A Story First A crossing guard who must wait for every single car in a long line to individually confirm "I am not turning here" before letting pedestrians cross creates real, noticeable delay — even if every single driver genuinely had no intention of turning. Telling the guard in advance "none of these cars will ever turn here" lets pedestrians cross immediately, with the guard no longer needing to wait and check each one. `{ passive: true }` is that advance promise, letting the browser start scrolling immediately instead of waiting to see if any listener will cancel it. ## 2. The Core Idea 📌 **Interview

Tricky JavaScript Scenario #33: Passive event listener scroll enhancements

The problem

Question presented to candidate: "You add a touchstart listener to track gesture analytics. Users report scrolling feels janky on mobile after you added it, even though your listener does almost nothing. Why, and how would you fix it?"

What a strong answer should cover:

📌 Interview term: the real, direct answer to the prompt — by default, the browser genuinely cannot start scrolling in response to a touch gesture until it has first RUN every registered touchstart/touchmove listener to completion, because any one of them COULD call .preventDefault() to cancel the scroll — even an empty or near-empty listener genuinely introduces a real, measurable delay before scrolling can begin.
📌 Interview term: { passive: true } — a real, third-argument option to addEventListener that tells the browser, in advance, "this listener will never call preventDefault()" — letting the browser genuinely start scrolling immediately, in parallel, without waiting for the listener to finish running at all.
📌 Interview term: the real, verified consequence of the promise — verified directly: calling .preventDefault() INSIDE a listener registered with { passive: true } genuinely does NOT throw — the browser silently ignores the call — but it genuinely has ZERO effect, confirmed directly (event.defaultPrevented stayed false even after the call) — the browser is trusting the passive promise was kept, and does not even check.
📌 Interview term: the real fix for the prompt's exact scenario — a precise answer names that adding { passive: true } to the touchstart listener (since the analytics tracking genuinely never needs to cancel the gesture) genuinely removes the real, measurable scroll-blocking delay — the browser can start scrolling the instant the touch begins, running the analytics listener in parallel rather than beforehand.
A precise answer names that several browsers have made touchstart/touchmove listeners genuinely default to { passive: true } UNLESS explicitly marked { passive: false } — a real, deliberate platform-level mitigation for exactly this common performance footgun — but relying on that default rather than being explicit is a real, honest gap in guaranteed cross-browser behavior worth naming.

Clarifying questions expected:

None — this is a definitional/practical question; directly diagnosing the prompt's own reported jank with real, verified proof is the strong signal.

Code / implementation expected: Yes — a real, direct demonstration that calling preventDefault() inside a { passive: true } listener neither throws nor has any effect.

rendering
tricky
real-world

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The core "does preventDefault() do anything in a passive listener" claim below was actually run and checked, not assumed.

1. Why This Even Matters — A Story First

A crossing guard who must wait for every single car in a long line to individually confirm "I am not turning here" before letting pedestrians cross creates real, noticeable delay — even if every single driver genuinely had no intention of turning. Telling the guard in advance "none of these cars will ever turn here" lets pedestrians cross immediately, with the guard no longer needing to wait and check each one. { passive: true } is that advance promise, letting the browser start scrolling immediately instead

The solution is hidden so you can try first

6 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: calling preventDefault() inside a { passive: true } listener genuinely neither throws nor has any effect — verified directly