Time on Page is the elapsed time a user spends on a specific page within a session. In practice, analytics systems compute it by taking the timestamp of the page view and subtracting it from the timestamp of the next hit (another page view or an interaction event). If there is no next hit—e.g., the visit ends on that page—time on that page is typically unknown and may be stored as 0 or excluded from averages. That nuance is why Time on Page should be read together with Bounce Rate, Exit Rate, and Average Session Duration.
How is Time on Page calculated?
Formula:time_on_page(i) = timestamp(next_hit) – timestamp(current_pageview_i)
Mini example:
| Timestamp | Hit | Page | Time on Page |
|---|---|---|---|
| 10:00:00 | Pageview | /a | — |
| 10:01:20 | Click (event) | /a | 80s (if events count) |
| 10:03:00 | Pageview | /b | 180s (if only pageviews count) |
| 10:05:10 | Exit (no next hit on /b) | /b | 0s or unknown |
Different tools either (a) use the next hit of any type or (b) only the next pageview. Know which rule your stack follows before comparing numbers across properties or vendors.
Why it matters (and common pitfalls)
- Content quality signal: Long Time on Page can indicate depth of engagement, especially for articles, docs, and guides. Pair it with Scroll Depth and Event Count to confirm that users actually interacted, not just idled in a tab.
- Skew from exits and bounces: Single-page sessions often record 0s, dragging down averages. Consider segmenting by non-bounce sessions or combining with Engagement Rate.
- Not equal to dwell time: Time on Page is page-level within your site; Session duration and user-journey metrics answer different questions.
Practical tips
- Report both average and median Time on Page to reduce the impact of outliers.
- Build lightweight interaction events (e.g., 45s reader ping, link clicks) to capture a “next hit” and reduce the 0s problem—without inflating Pages per Session or Conversion Rate.
- When benchmarking pages, keep comparisons within the same content type and intent.