What is scroll depth?

‍

How is scroll depth calculated?

The standard formula is the bottom edge of the viewport relative to total document height:

scroll depth % = (scrollY + viewportHeight) / documentHeight × 100



Three terms in that formula cause most of the confusion around the metric.

documentHeight is not fixed. Lazy-loaded images, embeds resolving late, and content injected after load all change it. A percentage computed early in the session measures against a different denominator than one computed late.

viewportHeight differs enormously across devices. The same content produces different percentages on a phone and a desktop, because the numerator includes the viewport.

Maximum, not cumulative. Correct implementations record the deepest point reached per session. Implementations that sum scroll activity produce values above 100% and are measuring something else.

Why does percentage-based scroll depth mislead?

Percentage flattens pages of wildly different lengths into the same scale, which makes cross-page comparison actively wrong.

On a 2,000 pixel page, 50% depth means the visitor traveled 1,000 pixels. On a 20,000 pixel page, 50% means 10,000 pixels, ten times the reading effort for the identical metric value. Comparing "50% scroll depth" across those two pages compares nothing.

Worse, on very long pages the percentage compresses the region where decisions happen. The first three screenfuls, where most attention concentrates, may occupy only the first 15% of a long article, so the entire high-attention zone collapses into a narrow band of the metric.

Two corrections:

• Use pixel depth for cross-page comparison, or better, screenful depth, which normalizes against the viewport.
• Use percentage only within a single page over time, where the denominator is stable.

Key takeaway: percentage scroll depth is a within-page metric. Treating it as a cross-page metric produces confident nonsense.

How do you instrument scroll depth?

Three approaches, increasing in fidelity.

Threshold events. Fire an event at 25%, 50%, 75%, and 90%. GA4 ships a scroll event by default that fires once per page at 90% depth, which is a single coarse signal rather than a curve. Adding the other thresholds requires custom configuration.

Element visibility. Rather than page percentage, fire an event when a specific element enters the viewport, using an IntersectionObserver. This is materially more useful than percentage thresholds, because "did they see the pricing table" is a real question and "did they reach 75%" is not.

Continuous capture. Behavioral analytics tools record maximum depth per session and build the distribution, which is what a scroll map renders.

For most Webflow sites, element visibility on three or four decisive elements beats percentage thresholds on everything.

Is scroll depth a useful engagement metric?

Partly, and it is routinely over-trusted.

What it genuinely supports:

• Confirming whether a specific section was ever visible to a meaningful share of visitors
• Detecting a false bottom, where depth collapses at a specific point
• Qualifying an audience segment, since visitors who scroll deep on a technical page are usually higher intent

What it does not support:

Reaching is not reading. Pixels entering a viewport is not comprehension, or even attention. Fast scrolling to the bottom registers as 100%.

It is easily gamed by design. Shortening a page raises average scroll depth without improving anything. Any metric improvable by deleting content is a poor optimization target.

It correlates weakly with conversion on short pages. On a landing page where the form sits above the fold, deep scrolling may indicate hesitation rather than engagement.

Use it as a diagnostic input, not as a KPI. A team optimizing for scroll depth will eventually make pages shorter and worse.

How does scroll depth behave on Webflow?

Lazy loading destabilizes the denominator. Webflow lazy-loads images by default, so on image-heavy pages documentHeight grows while the visitor scrolls and early percentages are computed against an undercounted total. Set critical above-fold images to eager loading, and expect noise on long image-heavy templates.

CMS collection lists produce variable page heights. One template rendering 6 items on one page and 40 on another gives you two very different denominators under one URL pattern. Segment by item count, or instrument element visibility instead.

Sticky navigation inflates the numerator. A sticky header occupies part of viewportHeight at every scroll position, so the formula counts pixels the visitor cannot see and depth slightly overstates what was visible.

100vh sections shift depth by device. A hero sized to the viewport is a different share of total page height on a phone than on a desktop, which moves every downstream percentage.

Custom code goes in Site Settings, Custom Code, Head Code, and does not execute in the Designer canvas or preview mode. Publish before testing any scroll instrumentation.

Related terms

Scroll map · Above the fold · Website heatmap · Event tracking · Time on page

Service: Conversion Rate Optimization.

FAQ

What is a good average scroll depth?

No cross-site benchmark is meaningful, because the number depends on page length, page type, and device mix. Compare a page against its own history and against pages of similar length on your own site.

Does GA4 track scroll depth automatically?

GA4 fires a single scroll event when a visitor reaches 90% of page height, once per page. Anything more granular requires custom configuration through Google Tag Manager or custom code.

Is scroll depth the same as a scroll map?

No. Scroll depth is the per-session metric. A scroll map is the visualization built by aggregating that metric across many sessions and rendering it as a color gradient over the page.

Does scroll depth affect SEO?

Not directly. Search engines do not measure it. It relates indirectly, since the things producing shallow scroll depth, such as slow loading and layout instability, are measured by Core Web Vitals, which does influence ranking.