Web Vital Metrics for Single Page Applications

[hbpatel142]

In React Single page Application(SPA), First Input Delay and Largest Contentful Paint are only measured once on Initial Load. Additionally, Cumulative Layout Shift does not reset to 0 throughout the session. This means CLS could reach to very high value , if user continues to navigate though logical pages like homepage -> search -> Product Listing -> Product Page -> Basket -> Checkout and so on.

Based on current implementation, pageshow event resets CLS to 0 and it also captures FID and LCP for subsequent page loads.

In React Single Page Application, Could we consider route change event for the new logical page load and reset CLS to 0. This would also enable us to capture FID and LCP on every logical page of the application.

If Web Vital Metrics would be considered for page ranking, the proposed implementation would give React SPA fair comparison.

[arpowers]

Had the same question, the docs need some context for SPAs (or any app with history-based navigation)

For example, there should be a way to manually reset the values based on a trigger or event.

[fraser-m-hurley-LTK]

I had wondered whether subsequent page loads with an SPA are even (or should be) considered wrt web-vitals? Either way I'd be interested in seeing some guidance on how to handle web-vital measurement for SPAs

[philipwalton]

Unfortunately, accounting for SPA route transitions in Core Web Vitals metrics is not currently possible. There are a few primary reasons for this, both technical reasons and practical reasons.

The technical reason is that the Web APIs that measure page load specific Core Web Vitals metrics (LCP and FID) do not re-emit entries after a SPA route change occurs. For FID we could use the same polyfill we use in the case of a bfcache restore, but for LCP we could not, since route changes typically involve loading additional content, and polyfilling LCP to handle those cases would be near impossible (and it would certainly affect performance).

Also, as you point out, in the case of CLS we could reset the metric value to 0 (as we do for a bfcache restore), but this is where the practical issues come into play: what counts as an SPA route change?

• Should every call to history.pushState() be considered a route change?
• What about history.replaceState()?
• What about apps that still use hash URLs for SPAs? (A lot of those still exist.)

While I understand it's probably quite easy for you to determine what should be considered a "logical page load" for your specific app. Making that determination for any given web page is pretty much impossible.

Finally, and perhaps the most challenging of the practical issues is that both Google Chrome and Google Search are creating incentives around these metrics, which means it's absolutely critical that they can't be easily gamed.

If we consider every call to history.pushState() to be a new page load, then developers would have a strong incentive to use that API, even in cases where a user wouldn't consider it a "logical page load".

For example, you could easily imagine some code like this:

// Create a new "page load" any time CLS gets close to crossing the 0.1 threshold...
If (cls > 0.09) {
  history.pushState({...}, document.title, location += '&addendum=1)
}

Similarly, developers might try calling history.pushState() during idle periods to increase the likelihood of LCP and FID being super fast.

---

Hopefully this helps explain why Core Web Vitals metrics currently don't consider SPA route transitions. But rest assured we are aware of this problem and looking into solutions. Here are two concrete examples:

• We plan to update CLS in the near future to be more fair to long-lived pages (including SPAs).
• We're working to spec a new version of the history API that might enable us to more accurately identify SPA route changes in the future.

[hbpatel142]

Thanks for the quick response!

Above is really good explanation on why current route change identification (within SPA) alone is not sufficient for the web vitals that must not be gamed, but at the same time very critical that it's measured accurately, since this would impact page ranking in May 2021 unless the timeline is changed.

It is really great that the team is actively looking for the solution and the official documentations around SPA have started to surface recently.

[arpowers]

Thanks for the response! I would just add that or part of that to the docs for the package.

Even if vitals don't apply, there are natural questions that get asked: "how does this apply to SPAs?" A few sentences would answer that cleanly.

[philipwalton]

FYI: we're working on some content related to SPAs for web.dev/vitals. Once that's published we can link to it from this repo.

[richardscarrott]

Wow, I've spent months pondering why google search console flags so many of our SPA's pages as having poor CLS but lab data (lighthouse) and performance traces (Chrome dev tools) suggest it's very good.

On first load we generally see web-vitals report 0, but with each SPA navigation we see our CLS creep up and up which is why we're seeing such crazy (and unfair?) values; all we're really garnering from CLS is how long somebody is on the site for 🤦🏻‍♂️

I think the layout shifts which are being accumulated across SPA navigations are those caused by a successful network response after navigation because, like many SPAs, on click we show a blank screen with a loading indicator while fetching the data, and then when the data arrives we render it to screen causing a layout -- if the page data being navigated to is already in memory then I've observed the CLS isn't reported, I guess because the layout is the direct result of a click handler -- https://www.paradeworld.com/

In the meantime we're going to only report the first CLS value reported by web-vitals, but it's terrifying to think google search is going to factor in CLS over the entire session and penalise SPAs offering a decent user experience?

[philipwalton]

Hey @richardscarrott, see the post on how we plan to update CLS that I mentioned above to address your concern about how the value just keeps increasing the longer the user is on the page.

As for the the technique of showing a loading spinner and then filling in the content once the network request completes, this may still be counted as layout shifts—if it's the case that elements on the page are shifting as new content is being added.

I'd recommend updating your SPA transition logic to either:

• Reserve the required space for all new content (if the dimensions are known) ahead of time, or
• hide the content as it's loading (via using dipslay:none, visibility:hidden , or opacity:0) and then only show it once it's all available.

[richardscarrott]

Hi @philipwalton thanks for the advice.

I had a bit of a think about your last point re: hiding the content while it's loading and realised I had initially thought the layout shift was merely counting the layout of the new content rendered to screen but of course it's our footer which get's shifted further down the page.

It wasn't immediately obvious to me because we do render the footer offscreen while loading by reserving the height of the viewport; this was done specifically to prevent the footer flashing into view. e.g.

And I guess, although unlikely imo, a user could scroll the footer into view during the loading period and then genuinely experience a layout shift. It seems layout shifts don't discriminate against things inside vs outside the viewport 🤔.

I tested with the footer hidden while loading and as you've suggested this solves the issue so we're seeing almost 0 CLS reports during the page lifecycle.

Of course, we still have the issue of the now rarer and slight layout shifts accumulating over the SPA session but I'll give that article another read and look forward to hearing about improvements on this.

UPDATE: So I had a proper read of the CLS docs and of course it does attempt to only consider layout shifts which are in the viewport, however it seems to get this wrong with our footer. Adding margin-top: 21px to our footer (20px doesn't quite cut it on all viewport sizes I tested 🤷‍♂️) prevents the CLS event from firing on SPA navigations; obv we're then betting on the user not scrolling the footer into view while loading, but will see how this goes (Side note, I feel like I'm gaming the metric a little here).

UPDATE2: So there obviously had to be a reason it was 20px specifically and I think it's because we have a negative margin on a child element in our footer to compensate for some third party styles, so although visually it didn't appear to be in the viewport it's bounding box did creep in by 20px.

[Midhun-Carousell]

I am just getting started with measuring of CLS and LCP for my React based SPA and came across web vitals module and this thread.
I just played around with the api getCLS and getLCP for my SPA by including a call in one of my pages when the page component is loaded by JS.But I do not see CLS score or LCP score printed on console.LCP gets printed once after I interact with the page, like a simple click on the UI and no amount of route changes prints it again. CLS never gets logged at all.
Is the conclusion of this particular thread that for SPAs, web-vitals module may not work as expected?Are there any steps I can perform on my SPA to have getLCP and getCLS work properly?

[philipwalton]

@Midhun-Carousell

LCP gets printed once after I interact with the page, like a simple click on the UI and no amount of route changes prints it again.

This is expected. LCP is only measured at page load, and this is intentional for the reasons I mentioned above. Also, the reason you're seeing LCP logged to the console after you interact is because that is the point when LCP observation stop waiting to see if a larger element gets added to the DOM (we can't log the value before that point).

CLS never gets logged at all.

CLS is only logged when the page is backgrounded or unloaded, so if you switch tabs you should see it logged. You'll also see it logged if you check the preserve log option in devtools and reload the page (it will log CLS for the previous page).

For both LCP and CLS, if you want to log the metric value every time it changes, you can do that with the reportAllChanges option.

Is the conclusion of this particular thread that for SPAs, web-vitals module may not work as expected?

I suppose it depends on what you consider "expected", but based on what you've described, it sounds like it's working exactly as intended.

If you were expecting all the Web Vitals metrics to re-emit after a route change in an SPA, that is not expected to happen.

[philipwalton]

@richardscarrott thanks for the update.

UPDATE2: So there obviously had to be a reason it was 20px specifically and I think it's because we have a negative margin on a child element in our footer to compensate for some third party styles, so although visually it didn't appear to be in the viewport it's bounding box did creep in by 20px.

This library is just collecting what the underlying Layout Instability API is reporting. If you think this behavior is confusing or wrong, I'd recommend filing an issue on the spec highlighting your use case, and it will be discussed there.

[AdrianMuntean]

@philipwalton even after the new update I can still see the same page id when I navigate btw pages in a SPA. This means that the cumulative CLS is summed to the initial page.

On a flow: search page => category page all the CLSs have the same id. Is this expected?

[philipwalton]

Is this expected?

Yes, this is expected. Until we have more reliable ways to detect user-initiated SPA transitions (or a dedicated web APIs to measure them) then Core Web Vitals metrics will need to be attributed to the URL was that present at the time the page was loaded.

We recognize that this makes debugging quite awkward in cases like the one you described: where the problematic layout shifts occur after an SPA transition to a new URL.

If you're measuring your Core Web Vitals with an analytics tool, we recommend collecting both the URL at the time of the shift and the URL that the page was originally loaded at for debugging purposes.