Domain Dictionary · Measurement
Core Web Vitals are measured per origin
Two forms of your name look like one site to you and like two separate records to the measurement.
The short answer
Core Web Vitals are the three things Google measures about a page's experience — loading, measured as LCP, responsiveness, measured as INP, and visual stability, measured as CLS — collected from real visitors and fed into ranking. The detail that matters if you own names is the unit of collection: field data is grouped by origin, which is scheme plus hostname plus port, so https://example.com and https://www.example.com are two separate records, and so is every subdomain.
Which turns canonical-hostname discipline from a tidiness preference into a measurement decision.
By the Hosting & Domains team · Reviewed 18 August 2026
0
Undefined jargon per entry
100+
Entries linked to each other
Real
Zones behind the examples
Free
Always, and no gate
LCP times the arrival of the main content, with the target at roughly 2.5 seconds. INP measures how promptly the page reacts when somebody interacts with it. CLS measures whether the layout holds still rather than shifting under a reader's thumb. Rankings are fed by field data from real Chrome users rather than by a lab score.
Responsibility divides along a clean seam. The foundation belongs to hosting, because LCP has TTFB underneath it and TTFB has a DNS lookup underneath that. Everything above the foundation belongs to the page: disciplined images, script weight kept down, and space reserved so nothing jumps about.
Split traffic, split data
If both www and the bare domain serve your site rather than one redirecting to the other, your visitors are being divided between two origins and so is your field data. Neither record sees the whole picture, and either can sit below a reporting threshold and simply show nothing at all.
The remedy is the same one that helps everything else: choose a canonical hostname, redirect the other form to it in a single hop, and let the data accumulate in one place. Subdomains are a separate matter — a shop on shop.example.com is genuinely its own origin and will always report separately, which is worth knowing before you go looking for a number that was never going to be there.
What a domain change does to your history
Move to a new name and, as far as this measurement is concerned, you are a new site. The new origin starts with no field data and has to gather a fresh collection period before anything shows, which means a window where the report is empty and you cannot tell whether the move helped or hurt.
So plan around it. Get the vitals into good shape before the move rather than after, keep the redirects from the old name in place and keep that registration renewed for as long as anything points at it, and expect the reporting gap rather than being alarmed by it.
The layer underneath LCP
LCP cannot start until the first byte arrives, and the first byte cannot arrive until the name has resolved and a connection has been made. So the chain runs: resolution, connection, TLS, server, then render. A redirect chain inserts an entire extra round of the first three, which is why the www-versus-apex decision shows up in the loading metric and not only in the analytics.
One worked example. A cached TTFB and a hero image cut to a sensible size take a retailer's LCP from 4 seconds to 2.1: a single metric in two halves, each owned by a different layer, and one afternoon to settle both.
Where to look, and how much to care
Two places show you real visitors: the Core Web Vitals report in Search Console, and the field data panel in PageSpeed Insights — both grouped by origin, both needing enough traffic to register. Treat lab scores as a diagnostic and field scores as the verdict.
As for weight: they count among a great many other inputs and decide nothing on their own. Relevance still leads, vitals settle close calls, and bad ones drag on everything. Strong vitals lift a handicap rather than winning a race, and that is the honest size of it.
Desk answers, tidied up and published
A term nobody explained is a ticket waiting to happen, so we wrote the explanations down and put them where a search engine can hand them over for us.
Where the ending allows it, a transfer stacks a year on the term you already hold, which is why moving a name early wastes nothing.
- The timer named wherever a term has one
- Panel screens named rather than described
- About two minutes a term, start to finish
- Examples taken from zones that really look like that
Why Hosting & Domains
Standard on every plan
This term, pinned down
Core Web Vitals defined, placed in the layer that owns it, and shown going wrong — recognise-level after one read.
Cross-referenced, never a cul-de-sac
Neighbouring entries are linked at the foot of the page, so one lookup tends to leave you holding three terms instead of one.
Failure modes, not only definitions
Each entry names the way the thing goes wrong, on the grounds that a fault is usually what sent you looking it up.
One idea to an entry
No entry tries to be a manual. It defines the term, shows it doing its job, and points at the term you will need next.
Registry and registrar kept apart
Every entry says which company owns the thing being described, because that is the difference between fixing it yourself and reporting it to somebody else.
The clock named, wherever there is one
Where a term has a timer behind it — a TTL, a grace period, a sixty-day registry hold — the entry tells you how long it runs.
Quick Start
Order placed to site online
- 1
Check it from outside your own machine
Ask a public resolver rather than trusting the browser in front of you, so what you see is what a visitor sees rather than what your cache remembers.
- 2
Look at the clock
Find the TTL on the record, or the expiry date on the name. Both are plain numbers, and between them they decide how long a mistake gets to last.
- 3
Note down what each record is for
One line beside the zone — this TXT verifies Google, that CNAME serves the newsletter — is what stops a tidy-up killing a working integration.
Built In
Fitted to every plan
- LiteSpeed caching in the server rather than bolted on by plugin
- WebP image optimisation built in, at no extra charge
- cPanel, the panel most of the industry already runs
- PHP versions set per site from the control panel
- DNS records you edit yourself, in cPanel's Zone Editor
- NVMe storage on every tier, not only the dear ones
- 99.9% uptime as the target, watched around the clock
- Upgrades applied in place, with no migration when the plan changes
- People on the support desk at every hour of the day
- No set-up fee, and nothing charged for joining
Frequently Asked
Questions we field again and again
Why does my vitals report look empty when the site gets traffic?
Check which origin you are looking at. Field data is grouped by scheme plus hostname, so if both www and the bare domain serve the site your visitors are split across two records and either one can fall below the reporting threshold. Pick a canonical hostname, redirect the other in one hop, and the data will accumulate in a single place.
We are moving to a new domain. What happens to our vitals history?
It stays with the old origin, and the new one begins with nothing. There will be a period where the report has no field data for the new name and you cannot tell from it whether the move helped. Get the numbers healthy before the move, keep the redirects from the old name running, keep that old registration renewed while anything still points at it, and expect the gap.
Do subdomains share a vitals record with the main site?
No. An origin is scheme plus hostname plus port, so shop.example.com and example.com report entirely separately, however alike they look to you. That cuts both ways: a slow subdomain does not drag the main site's numbers down, and a fast main site does nothing to rescue the subdomain's.
Which part of LCP is mine as a name owner rather than a site builder?
The bottom of the chain. LCP cannot begin before the first byte, the first byte cannot arrive before the connection, and the connection cannot open before the name resolves. So the DNS lookup, the number of redirect hops between the name somebody typed and the page that finally serves, and whether the certificate covers both forms of the name are all yours. The image sizes are somebody else's.
Keep reading
Web Hosting
cPanel hosting on NVMe drives, with SSL, the migration and year one of the name included.
PHP Hosting
The PHP version set per site, on quick NVMe hardware.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
Move the name without dropping the site.
500+ endings to search, the renewal rate shown before you buy, and the auth code released the moment you ask.
View Web Hosting plans