Pageview type
A pageview is a request for a specific website page. Important to know is that the type of pageview will usually dictate the user experience. When filtering and analyzing your RUM data, we have the following pageview types:
- unique
- successive
- returning
RUMvision pageview types
Unique pageview
A unique pageview is the first pagehit in a new session within the tracked domain. In other words, a unique pageview indicated when (and where when you combine this bucket with the page URL filter) users started their journey. This could be the result of navigating to a page directly, from their bookmarks or clicking on a link from a different site (which includes Google's search engine results pages).
The first request to your domain often involves more tasks, as domain lookup has to happen and (render blocking) resources will not have been cached yet. We differentiate unique pageview types from the rest to prevent you from drawing incorrect conclusions.
Successive pageview
Any follow-up request since the first unique request are considered successive pageview types. So, when clicking from the destination page (where users started their journey) to any other page within the same origin is considered a successive pageview. Especially when looking at the First Contentful Paint metric, the experience during a successive pageview is expected to be way better than unique pagehits. Simply because most (domain lookup) work and (render blocking) resources will be cached already by the browser.
Returning pageview
There is one other pageview type group, and that's returning visitors. When users did visit your domain before, but are starting a new session later on, then their first pagehit within that new session is considered a returning pageview. This even applies when a user is visiting a page that they visited in a previous session.
Technical nuances
To differentiate the type of pageview, RUMvision primarily uses the following techniques:
- localStorage
When there is a localStorage, we assume the user visited the site before. We do this as localStorage persists through browser sessions. We do this to differentiate returning from unique visitors. - sessionStorage
When there is a sessionStorage, we assume it's a pageview within the same session. We do this to differentiate a successive from non-successive page navigation.
This technique will break when users are opening pages in new tabs or windows (as the above applies per tab), when explicitly deleted by the user. Some browsers -like Safari- will automatically erase localStorage frequently when not used during a certain time (7 days at time of writing).
You can configure our snippet to not use localStorage & sessionStorage. In that case, we use non-storage related methods to differentiate these three pageview types, which does come with less waterproof outcomes.
Use the navigation type filter to differentiate reloads from non-reloads, bfcache, prefetched pages and normal navigations.
Use-case
A successive pageview will always give a better experience than a unique pageview. When these are too close together, several things may be going on.
- A/B testing that causes the successive to be relatively not much better.
- Lots of async third parties which, in the case of a successive pageview, usually leads to relatively higher FCP than hoped for.
- All CSS inlined (critical), but still forgetting a render-blocking file in this process.
Difference with Core Web Vitals
Do note that public Core Web Vitals data will not differentiate the different pageview types when showing you FCP or LCP data. This will introduce blindspots and prevents you from doing proper debugging as Core Web Vitals will just show an overall number. In the case of the screenshot below, it would be 1.1 seconds. Which is very healthy. But looking at individual buckets, we can clearly see that in reality, there are huge gaps per pageview type.
The ability to segment and filter on pageview type level will give your guidance when analyzing data and directly see during which conditions either FCP or LCP challenges are happening.
Example
The screenshot demonstrates what happens 9 times out of 10 times. The unique value is much higher than the successive and returning values. During a returning pageview, a new DNS lookup will typically happen again. As a result, a returning pageview will yield a worse experience than succesive pageviews, but due to resources being cached already, it is expected to perform better than a fully unique pageview.
To get a green score for this, the First Contentful Paint (FCP) must be under 1.8 seconds according to Google. In the screenshot below, a site owner uses 1.5 seconds as the next threshold from a good to moderate FCP. When looking at the FCP of unique pageviews, you might be able to draw the conclusion that you should want to optimize that as well.
