Chrome began publishing experimental Core Web Vitals data in October 2026 that covers page changes inside single-page websites. If your site loads content without a full page refresh, your speed data may soon look more complete. If your site loads a fresh page on every click, you can mostly relax.
This matters because single-page sites were hard to measure fairly. Owners often saw one score for a whole visit, even when visitors clicked through many screens. The new approach aims to fix that gap.
What Changed
The web.dev article on single-page architectures and Core Web Vitals states that Chrome 151 released new APIs for measuring Core Web Vitals on single-page sites. It also says Chrome started publishing experimental versions of these metrics in the Chrome User Experience Report, known as CrUX, from October 2026. The plan is to graduate them from experimental status in May 2027.
CrUX is the public dataset built from real Chrome visitors. Tools that show field data for your site draw on it, so this change can show up in the reports your web team already uses.
What a Single-Page Site Is, in Plain Words
On a traditional site, each click loads a new page from the server. The browser treats that as a fresh start and measures speed again. This has always worked well with Core Web Vitals.
A single-page site loads once and then swaps content in place. The address bar changes and the screen updates, but the browser does not reload everything. Many booking tools, online stores, member portals and dashboards work this way.
Web.dev calls these in-site page changes soft navigations. In its description, a soft navigation happens when a visitor action leads to both a paint and a URL change. Chrome can now treat each of those as its own measured page change.
Why Owners Should Care
Core Web Vitals are three measures of real visitor experience. According to web.dev, they cover loading speed, responsiveness and visual stability. Google lists them as Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.
On a single-page site, the first load can look fast while later screens feel slow. Before this change, those slow screens were often hidden inside one average. Better measurement can reveal which routes frustrate visitors.
That is useful news, not bad news. You cannot fix a slow checkout step if your data only describes the home page.
Who Is Affected
- Likely affected: sites built as single-page apps, such as portals, booking flows, quote tools and some online stores.
- Possibly affected: standard sites that add a single-page section, such as a cart drawer or a filtered product list.
- Likely not affected: simple brochure sites and blogs where each click loads a full page.
Your web team or agency can tell you in a few minutes which group you are in. Ask them directly, and ask them to answer in writing.
A Short Plan for the Next 30 Days
- Confirm how your site is built. Ask whether the public pages load as a single-page app, a standard multi-page site or a mix of both.
- List your money routes. Write down the three or four screens that bring in leads or sales, such as a service page, a quote form and a checkout step.
- Ask for route-level speed numbers. The source advises single-page developers to use the new APIs to measure performance by route and to debug issues. Request a short report for your money routes.
- Check Chrome DevTools. Web.dev notes that Chrome DevTools supports soft navigation inspection in its performance panel. Your developer can use it to find the slow step in a specific screen change.
- Set a simple target. Web.dev lists good scores as loading under 2.5 seconds, responsiveness under 200 milliseconds and layout shift under 0.1. Use those targets as your starting goal.
- Review again in the spring. The metrics are experimental until the planned graduation in May 2027. Schedule a second check once that date passes.
What Not to Do
Do not rebuild your whole site because of this announcement. The web.dev guidance advises against switching from a single-page app to a multi-page site only to improve Core Web Vitals scores. A rebuild costs real money and may not fix the actual slow step.
Do not treat the experimental numbers as final either. The data may change before it graduates. Use it to find problems, not to judge your developer or your site.
Also avoid chasing a perfect score on every screen. Focus first on the routes where a slow response costs you a customer.
Questions to Ask Your Web Team
- Is any part of our public site a single-page app?
- Which routes are slowest for real visitors, not just in lab tests?
- Are we using the web-vitals library or another tool that supports the new Chrome 151 measurements?
- What is the single biggest fix for our most important route?
Good answers are specific. A team that names a route, a number and a fix is paying attention. A vague answer is a sign to ask for more detail.
How This Fits Your Wider Site Health
Speed is one part of a healthy site, along with security, accessibility and clear content. A faster screen change helps visitors on older phones and slow connections most. Those visitors often walk away without telling you.
If your site is a standard multi-page build, keep doing what works. Check your key pages in your speed reports each quarter and fix anything that turns red.
If your site is a single-page build, this is a good moment to learn which screens need work. The tools to measure them now exist inside the browser most of your visitors already use.
The Bottom Line
Chrome now offers better measurement for single-page sites, and the first experimental data began appearing in October 2026. Confirm how your site is built, measure your key routes and fix the slowest one first. Then check again after the May 2027 graduation date.
Sources
Want a second pair of eyes on this for your own site? Contact us or schedule a call.
Tags
Frequently Asked Questions
Do I need to act if my website is not a single-page app?
Probably not. Standard sites that load a new page on each click are already measured page by page. Ask your web team if you are unsure how your site is built.
Will this change my Google rankings right away?
The source describes the new numbers as experimental, with plans to graduate them in May 2027. Treat them as a diagnostic tool for now, not as a ranking promise.
Should I rebuild my site as a traditional multi-page site?
No. The web.dev guidance advises against switching from a single-page app to a multi-page site only to improve Core Web Vitals scores. Measure first, then fix the slow routes.
Enjoyed this article?
Share it with your network
