Answers to common questions about SPAs, Core Web Vitals, and how Core Web Vitals treats these.
Published: September 14, 2021, Last updated: August 11, 2026
Since first introducing the Web Vitals initiative in May of 2020, we on the Chrome team have received a lot of great questions and feedback about the program.
Perhaps the topic we've received the most questions about, which is also probably the hardest question to answer, is how to measure Core Web Vitals in a single-page application (SPA), as well as how SPA architectures affect Core Web Vitals scores.
These questions are hard to answer because the problem is quite nuanced, so in this post we're going to do our best to answer the most common questions, providing as much detail and context as we can.
Before getting into specifics, though, it's important to state that Google does not have any preference as to what architecture or technology is used to build a site. We believe that SPAs and multi-page applications (MPAs) are both capable of delivering high quality experiences to users, and our intention with the Web Vitals initiative is to provide metrics that measure the experience independent of the technology.
Frequently asked questions
The following are some of the most common questions we get on this subject. We are happy to take feedback to add to this FAQ at our feedback group or by raising an issue.
Do Core Web Vitals metrics include SPA route transitions?
When first introduced, each of the Core Web Vitals metrics was measured relative to the current, top-level page navigation. If a page dynamically loaded new content and updated the URL of the page in the address bar, it would have no effect on how the Core Web Vitals metrics are measured.
Metric values were not reset, and the URL associated with each metric measurement is the URL the user navigated to that initiated the page load.
Chrome 151 introduced new APIs that allow measurement of Core Web Vitals across SPA route transitions. At the time of writing (August 2026), these APIs are just starting to be used in measurement libraries like web-vitals, RUM solutions, and tooling like Chrome DevTools. Chrome has not yet published timeframes of integrating these into the Chrome User Experience Report (CrUX). Additionally, other browser engines don't yet support these new APIs and so Core Web Vitals can only be measured across full page loads for those browsers.
Why was this a hard problem to solve?
There is no standardized way of building an SPA today, and even among the popular SPA and routing libraries, the user experience can be quite different from app to app:
- Some SPAs update the URL only when loading new "full page" content, whereas other sites update the URL for tiny content changes or even just UI state changes.
- Some SPAs update the URL using the History API, whereas others use hash changes in order to support older browsers (and others don't update the URL at all).
- Some SPAs load content and then update the URL, whereas others update the URL before loading content.
- Some SPAs load content all at once, synchronously, in a single JavaScript task, whereas others transition content in, asynchronously, across multiple tasks (with no clear transition end event).
- Some SPAs always load content from the network, whereas others preload all content upfront so that route changes load instantly from memory.
These differences make defining and identifying what constitutes an SPA route change, or even an SPA itself, very difficult to do at scale.
In some cases an SPA route change is logically identical to an MPA page load, and in such cases it would be great if the existing Core Web Vitals metrics could be applied.
However, without solid heuristics to reliably identify "real" route changes from all other URL changes—as well as clear signals marking the beginning and end of such transitions—reporting Core Web Vitals metrics in these cases would muddy the data and make it less useful or representative of the real user experience on the site.
The Soft Navigation work has provided a solution to this with two new performance APIs:
PerformanceSoftNavigationwhich measures when a user interaction leads to both a paint and a URL change. The combination of these three things provides a standardized definition of a "soft navigation" regardless of the framework used and some of the differences mentioned previously. This allows splitting the performance timeline into separate "navigations", allowing CLS and INP to be measured for each navigation.InteractionContentfulPaintwhich measures "contentful paints" after an interaction, allowing FCP and LCP to be measured for these soft navigations.
The combination of these two APIs allow Core Web Vitals to be measured across both full page loads and soft navigations.
Are SPA route changes the same as full page loads for Core Web Vitals?
No, there are still many differences between these types of navigations, which can result in different Core Web Vital metrics.
A soft navigation has content on the page and is updating some or all of that content to display the new "page." In many ways this is similar to the difference between an uncached full page load versus a page load when some or all of the page resources are cached, but to an even more extreme state as some content may stay rendered.
In theory the main difference will be the potential for soft navigations to be much faster. But there are other, more subtle differences.
The new soft navigation APIs only consider new content. So a page that updates the <h1> and text content, but leaves the same hero image between pages, won't consider the hero image as an LCP candidate if it did not re-paint. This will lead to differences in which elements are used to calculate the LCP time based on whether the same page is loaded as a full page load, or as a soft navigation from another existing page.
Similarly, INP may be less for soft navigations since a lot of JavaScript needed to run the site will already be loaded. In the same way, a soft navigation may have less (or more!) CLS if the same content causes CLS on a full page load but does not need to be loaded or re-rendered on a soft navigation.
There are also slight differences in when the measurements are taken from in full page loads (measured from after the navigation interaction processing) versus soft navigations (measured from the interaction start time).
As previously stated, many of these differences are similar to uncached versus cached pages, and the concept of what Core Web Vitals attempts to measure still applies. However, it's worthwhile understanding these subtleties when investigating Core Web Vital issues.
Is it harder for SPAs to do well on Core Web Vitals than MPAs?
There is nothing inherent in the SPA architecture that would prevent a page in an SPA from loading just as quickly—and scoring just as well on all of the Core Web Vitals metrics—as a similar page in an MPA.
However, properly optimized MPAs do have some advantages in meeting the Core Web Vitals thresholds that SPAs don't. This has largely been mitigated with the soft navigations work discussed previously, but it may still be the case when these new APIs are not yet used. The reason is because with the MPA architecture, each "page" is loaded as a full-page navigation (rather than dynamically fetching content and inserting it into the existing page), which means users who visit an MPA are more likely to load more than one page from the site, which in turn means that a larger percentage of the distribution of all page loads for an MPA will involve some or all of the sub-resources being cached.
Granted, for an MPA to perform better on the Core Web Vitals metrics than an SPA requires a few things to be true:
- The MPA needs to have optimized sub-resource caching in order to ensure same-origin page loads are indeed faster than cross-origin page loads at the 75th percentile.
- Users who visit MPAs need to visit multiple pages in order for the site to receive the caching benefits that result in faster page loads.
Since Core Web Vitals assessments consider the 75th percentile of page visits, having more, well-performing page visits in the dataset will increase the likelihood that the visit at the 75th percentile of the distribution will be within the recommended thresholds.
Note that an important thing to consider when comparing Core Web Vitals scores is how the data is aggregated—that is, whether the dataset in the distribution includes all pages from your site or origin, or just page loads for a particular page URL.
When aggregating the scores of all pages in an origin, individual fast pages can improve the 75th percentile for the origin as a whole. However, when aggregating by individual pages, the scores of one page won't affect the scores of the next. In other words, when aggregating the scores of an MPA by page, fast cache loads seen on the checkout page will not improve the scores of slow initial loads experienced on the site's landing page.
You can check your site's score for different aggregation methods using PageSpeed Insights or the Chrome User Experience Report API, which reports scores for both individual page URLs and the entire origin.
Another way the SPA architecture can affect Core Web Vitals scores is for metrics that consider the full lifespan of a page. Since users visiting SPAs tend to stay on the same "page" for the entire session, metrics that accumulate over time can be harsher on SPAs than MPAs.
With the soft navigations work, we believe that there should be no disadvantages to SPAs in terms of how Core Web Vitals can be measured. However, full integration of these APIs across all tooling and reporting solutions will take time.
If SPA architectures improve the user experience, shouldn't that improvement be reflected in the metrics?
Yes, it should. Quantifying just how much the experience has improved was difficult to do at scale, given all the different ways SPAs are implemented on the web today. We now have a solution to the measurement problem, and when these new APIs are used, any improvements from moving to SPAs should be reflected in the metrics.
The truth is the web performance industry (Google included) has historically not invested nearly as much time and effort into developing user-centric metrics for the post-load performance of a page as it has for the page load itself. This isn't because post-load performance isn't important, it's because post-load UX and interactions are so much more varied and less well-defined—making it hard to design metrics for them.
But even now that we have more post-load metrics to measure SPA performance, we wouldn't want to ignore the load experience just because the post load experience got better.
One of the goals of the Web Vitals initiative is to promote and incentivize good user experiences across as many aspects of loading and using a web page as possible. We don't want to encourage scenarios where bad experiences are justified if you can have enough good experiences to make up for them. Users want pages to load fast and transition to new content fast, and we've tried to design metrics that favor those types of experiences.
We switched our site from an MPA to an SPA and our scores regressed. Is that expected?
It depends. There are a number of reasons why your scores could change after a major architecture migration, but a decrease in the number of warm cache loads could account for some of the change.
A quick way to check would be to test both an MPA and SPA version of one of your landing pages with Lighthouse. If the Lighthouse score is lower on any of the Core Web Vitals metric for the SPA version, then it's likely that the load experience did get worse after the update.
Should I switch my site from an SPA to an MPA to score better on Core Web Vitals?
Probably not. You should only switch from an SPA to an MPA if you are not happy with your SPA stack and you have reason to believe an MPA will provide a better user experience.
With the soft navigations work, we believe we have addressed the measurement issues so moving for that reason alone does not make sense.
However, if you have reason to show that performance will improve, rather than just measurements improving, then that may be reason to move from SPA to MPA (or vice versa!).
If Core Web Vitals scores are only reported for an SPA's landing pages, how can I debug issues that occur on "pages" after a route transition?
Google tools that report field data for the Core Web Vitals metric (like Search Console and PageSpeed Insights) get their data from the Chrome User Experience Report (CrUX). And CrUX aggregates data either by origin or by page URL (that is, the page URL at load time).
We are working on allowing CrUX to include data by SPA route in its aggregated data. However, as a site owner you can now use the new APIs to measure Core Web Vitals by SPA route in advance of this to understand how your scores may change.
For more details and best practices on this, see: Measuring soft navigations.
What is Google doing to ensure MPAs don't have an unfair advantage compared to SPAs?
As mentioned previously, with the soft navigations work, we believe that the work we have undertaken now means there should be no disadvantages to SPAs in this regard, though full integration across all tooling and reporting solutions will take time.
Assess cross-origin and same-origin page visits separately
Today the Core Web Vitals metrics aggregate all page visits into a single bucket—they don't differentiate between new versus returning visits or landing pages versus checkout pages or any other aggregation type where cache state could have an effect on performance.
One way to normalize the differences between SPA and MPA performance would be to apply different weighting to different types of visits, potentially even with completely different threshold recommendations.
While we definitely do want to reward effective cache implementations, we don't want fast intra-site navigations to be able to cover up for slow landing page loads. We also don't want to incentivize sites to break up long pages into a collection of shorter pages just for the sake of improving metric scores.
By separately assessing cross-origin and same-origin page visits we can help ensure that both types of experiences are important without letting the relative popularity of one type on a given site skew the distribution of any particular metric.
Final thoughts
Google is deeply committed to improving the Web Vitals metrics, and ensuring they measure and incentivize high-quality experiences that are important to users. That being said, we do acknowledge that measurement gaps exist today. The metrics are now able to cover SPA route transitions which addresses on of the main gaps.
We also believe these new APIs (particularly InteractionContentfulPaint) have further uses and potential benefits beyond Core Web Vitals measurement for soft navigations. We are very excited to continue to build on these now that the main reason for their introduction has been addressed.
I hope this post has helped shed some light on this complex and nuanced subject. As always, if you have feedback on the current or future Web Vitals metrics, email web-vitals-feedback@googlegroups.com.