Track scroll depth: Intersection Observer vs scroll events
efficient scroll-depth tracking.
place sentinels at depth thresholds and fire once via Intersection Observer, off the main thread; scroll listeners fire constantly and need throttling.
What's really being asked
It evaluates whether you know the modern, performant way to detect scroll depth and can articulate concretely why it beats raw scroll listeners.
The full answer
Place lightweight sentinel markers in the DOM at the depth thresholds you care about, the twenty-five, fifty, seventy-five, and hundred percent points of the article. Register them with an Intersection Observer, which the browser evaluates asynchronously and off the main thread, invoking your callback only when a sentinel enters the viewport. Mark each milestone as fired once so you do not double-count, and record the deepest depth reached. For reporting, accumulate the reached milestones and send them in a batch using navigator.sendBeacon or a single request on pagehide rather than a network call per milestone, which keeps the system efficient across many concurrent clients.
The comparison
Scroll event listeners fire very frequently, many times per second during a flick, so you must throttle or debounce them, and inside the handler you typically read scrollTop and element offsets, which forces synchronous layout and can cause jank and battery drain if done carelessly. Intersection Observer inverts this: you declare what to watch and the thresholds, the browser does the geometry efficiently and notifies you only at crossings, with no throttling needed, no layout thrash, and simpler code overall.
What usually comes next
How does Intersection Observer avoid layout thrashing under the hood. How do you ensure each milestone fires exactly once. How do you handle content that loads or resizes dynamically after the observer is set up. How do you batch and send the collected events efficiently.
A concrete example
For a long article you inject four invisible divs at twenty-five, fifty, seventy-five, and hundred percent. An Intersection Observer watches them; as the reader scrolls past the halfway div it fires once, you record 'fifty percent reached,' and on pagehide a single beacon sends all reached milestones together, all without a single throttled scroll handler running on the main thread.
Interview question
Why is the Intersection Observer API generally more efficient than scroll event listeners for tracking scroll depth?
- a.It runs on a faster network connection
- b.It automatically sends data to analytics without code
- c.The browser computes intersections asynchronously, avoiding per-event layout readsCorrect
- d.It works only on mobile devices where scrolling is rarer
Why? this is the answer
Intersection Observer lets the browser handle geometry off the main thread and notify only at threshold crossings, avoiding the throttling and forced layout reads of scroll handlers. It does not send data on its own or depend on network speed.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #scroll-tracking
- #intersection-observer
- #web-performance
- #analytics
- #javascript
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles