Do Core Web Vitals apply to subdomains or just the main domain?

What do we actually mean by 'origin' in the context of Core Web Vitals?

In the world of browsers and web security, origin is defined by three components: the protocol (http or https), the full hostname (including the subdomain), and the port. For Core Web Vitals, Google strictly applies this logic through the Chrome User Experience Report (CrUX).

This means that https://www.example.com, https://blog.example.com, and https://shop.example.com are three distinct origins. Each collects its own user experience metrics, independently of the others. This separation is not a decision made by Google — it is a technical constraint of the web security model.

Why is there granularity at the subdomain level instead of the root domain?

The CrUX collects real user data from Chrome users worldwide. This data is aggregated by origin to comply with privacy standards and the segmentation logic of browsers. Google did not build CrUX specifically for SEO — it is primarily a generic user experience measurement tool.

As a result, each subdomain inherits its own technical stack, sometimes its own hosting, and therefore may have potentially very different performances. A WordPress blog hosted on a modest VPS and a React application on a premium CDN cannot be judged with the same metrics. Granularity by origin reflects this technical reality.

How does this separation affect Google search rankings?

Google uses CrUX data as a ranking signal within the "Page Experience" framework. Each origin is evaluated separately, so one subdomain can receive a ranking boost related to Core Web Vitals while another subdomain within the same root domain does not benefit from this.

Let’s be honest: this is not a dominant signal. However, in competitive contexts where other factors are equivalent, this difference can tip the scales of a position. A high-performing subdomain does not compensate for a lagging main subdomain if the majority of SEO traffic goes through the latter.

• Each subdomain is measured as a distinct entity for Core Web Vitals
• The protocol (http vs https) also matters — two different origins
• CrUX data is never aggregated at the root domain level
• A subdomain without sufficient Chrome traffic will not have actionable CrUX data
• This logic applies to both desktop and mobile, with separate datasets

Is this statement consistent with what’s observed on the ground?

Yes, and it's easily verifiable. If you query the CrUX API or check the PageSpeed Insights report for different subdomains of the same site, you will find totally independent metrics. One subdomain may show "Good" for LCP while another is "Needs Improvement" — and this is the case across thousands of e-commerce sites where the blog is on a separate subdomain.

What’s less clear is the actual impact on ranking. Google remains very vague about the exact weight of the Page Experience signal. In my audits, I have seen sites with catastrophic Core Web Vitals on their main subdomain continue to rank well due to other strong signals (authority, content, backlinks). The boost exists, but it’s not miraculous. [To be confirmed]: Google has never published numerical data on the exact weighting of this signal.

What nuances should we add to this rule?

First point: if a subdomain does not receive enough Chrome traffic, it simply will not have CrUX data. Google requires a minimum threshold of data collected over a rolling 28 days. In this case, the subdomain is neither penalized nor favored — it’s just absent from the dataset.

Second nuance: individual pages can also have their own CrUX data if they generate enough traffic. However, the ranking signal generally applies at the origin level. If your origin is “Poor,” an isolated page with good performance does not suffice to overturn the trend for the entire subdomain.

When does this logic pose problems?

For multi-subdomain architectures, it’s a headache. Imagine an e-commerce site with www for the catalog, account for customer space, blog for editorial content, and m for mobile. Each has its own stack, its own hosting, and its own third-party scripts. The result: heterogeneous performances that translate into fragmented ranking signals.

This is where it gets tricky: you cannot compensate for a slow origin with a fast origin. If 80% of your SEO traffic comes through www and that subdomain is failing on Core Web Vitals, the fact that your blog is impeccable won’t save you. Each origin needs to be treated as a distinct optimization project.

What should be done practically to optimize Core Web Vitals by subdomain?

Start by mapping your origins. List all subdomains that receive significant SEO traffic. For each one, query the CrUX API or use PageSpeed Insights to retrieve actual metrics. Focus first on the subdomains generating the most organic page views — that’s where the impact will be most direct.

Then, treat each origin as a distinct technical project. A slow WordPress blog requires specific optimizations (lazy loading, server cache, CDN for images). A React application on another subdomain will need code-splitting, strategic preloading, and JavaScript optimization. Do not look for a one-size-fits-all solution — each stack has its own bottlenecks.

What mistakes should be avoided in this context?

A classic mistake: blindly optimizing the wrong subdomain. I’ve seen teams spend weeks improving a staging subdomain or an old abandoned blog that receives no traffic, while the main subdomain remained catastrophic. Always check the distribution of organic traffic before prioritizing your efforts.

Another pitfall: believing that a good Lighthouse score is sufficient. Lighthouse tests in a controlled environment — Core Web Vitals are measured with real-world CrUX data. A site can score 95/100 on Lighthouse and be "Poor" in CrUX if real users have slow connections, weak devices, or interact with heavy elements that Lighthouse does not test.

How to ensure each subdomain is optimally configured?

Use the Search Console — it aggregates CrUX data by origin and shows you which URLs are "Good", "Needs Improvement", or "Poor". This is your prioritization dashboard. For each failing origin, identify the problematic metrics (LCP, INP, CLS) and their root causes through tools like WebPageTest or Chrome DevTools in throttling mode.

Also monitor trends over 28 days. Core Web Vitals are rolling averages — an improvement is not reflected instantly. If you deploy a fix, wait at least 2-3 weeks before judging its effectiveness in CrUX. And keep an eye on regressions: a third-party script added by marketing can ruin your efforts in 24 hours.

• Map all subdomains receiving significant organic traffic
• Query the CrUX API or PageSpeed Insights for each distinct origin
• Prioritize optimizations based on organic traffic volume by subdomain
• Treat each technical stack separately — no one-size-fits-all multi-origin solution
• Monitor the Search Console for origin-level regressions
• Wait 28 days after a deployment to assess real impact in CrUX