Core Web Vitals are three Google metrics that measure loading speed, responsiveness to actions, and visual stability of a page. Google uses them as a ranking signal and shows the result in Search Console and PageSpeed Insights. This article covers which part of the metrics hosting controls, and which part comes down to the WordPress theme and plugins.
The three metrics and their thresholds
LCP (Largest Contentful Paint) measures the time until the largest visible element renders — usually the main image or heading. INP (Interaction to Next Paint) measures the delay between a visitor's action (click, tap, key press) and the screen updating in response; this metric replaced FID in March 2024. CLS (Cumulative Layout Shift) counts how much page elements move after the first render.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | up to 2.5 s | 2.5 to 4.0 s | over 4.0 s |
| INP | up to 200 ms | 200 to 500 ms | over 500 ms |
| CLS | up to 0.1 | 0.1 to 0.25 | over 0.25 |
Google treats a page as passing Core Web Vitals when at least 75% of visits fall within the "good" threshold — data from mobile and desktop devices is assessed separately, and a site can pass on desktop and fail on mobile.
Where to see the real numbers
PageSpeed Insights shows two sets of numbers: Lab Data — a single measurement under controlled conditions, and Field Data — aggregated data from real visitors over 28 days (Chrome User Experience Report). For judging whether the threshold is met, Field Data is what matters; Lab Data is for diagnosing the cause.
In Search Console, the "Core Web Vitals" section groups pages by real visitor data and shows which metric is failing a group of URLs — that is faster than checking pages one by one.
What hosting fixes: TTFB and compression
LCP depends directly on how fast the server delivers the first byte of HTML (TTFB) — the later the browser gets the document, the later the main image starts loading. Enabled response compression reduces the size of HTML, CSS, and JS that need to be downloaded before rendering starts; the detailed setup is covered in the article about Gzip and Brotli in Nginx.
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com/If TTFB is above a few hundred milliseconds already on an empty page with no plugins, the problem is not the metrics but an overloaded plan or a slow disk — no caching plugin will fix that part of LCP.
Caching and CDN: when they help LCP, and when they do not
A page cache and a CDN speed up repeat visits and static files specifically — images, fonts, CSS. A selection of techniques from real WordPress speedup practice:
- Turn on page caching and make sure the HTML page is served from cache rather than generated by PHP on every visit.
- Serve images in modern formats and at the right size — a large image shrunk only with CSS still downloads at full weight and slows down LCP.
- Add preconnect to the CDN and font domains so the browser opens the connection ahead of time instead of at the moment its turn comes.
- Defer loading of non-critical CSS and JS that are not needed to render the first screen, but leave alone the scripts that build the top block of the page.
- Do not cache pages with personal content (cart, account) wholesale — that will not speed up LCP for them, and it will show another visitor's data instead.
These techniques are covered in more detail in the article about speeding up WordPress; start there instead of manually tweaking a specific metric.
What hosting cannot fix
INP almost always depends on the amount and weight of JavaScript that runs in the visitor's browser — heavy page builders, extra widgets, and analytics scripts block the main thread while a click is being processed. Hosting does not execute JS on the visitor's behalf and cannot speed up a theme's or a plugin's code.
CLS is most often ruined by images without width and height attributes set, web fonts that swap text after loading, and ad blocks that appear with a delay and push the content around. A static resource cache and the right setup of a caching plugin solve part of this — for example, the way it is done in the article about LiteSpeed Cache for WordPress — but the theme's underlying markup still needs to be fixed at the code level.
Frequently asked questions
Can hosting guarantee passing Core Web Vitals?
No, hosting is responsible for TTFB, response compression, and cache availability, but the final metrics are made up of the theme's code, the number of plugins, and their JavaScript — on the very same server, one site passes the threshold and another with a heavy theme does not.
Why does PageSpeed Insights show a good LCP while Search Console shows a bad one?
PageSpeed Insights in Lab Data mode runs a single measurement under controlled conditions, often on a fast connection, while Search Console shows Field Data over 28 days from real visitor devices and networks, including slow mobile internet — the mismatch is normal and means Field Data is what to look at.
What to do if CLS is good in Lab Data but bad for real visitors?
Check blocks that load with a delay only for part of the visitors — cookie-consent banners, chat widgets, delayed ads — in the controlled PageSpeed Insights measurement they often do not have time to appear and do not hurt the score, while for real visitors they do have time.