Core Web Vitals are the three Google metrics that measure how quickly a page loads its main content, how quickly it responds to input, and how stable its layout stays, as real users experience it. This article covers what Core Web Vitals measure, the Core Web Vitals thresholds, how Core Web Vitals affect rankings, how page speed affects conversion, the heaviest causes on WordPress sites, and field data versus lab data. It then shows Core Web Vitals on holisticradar.com, connects them to web development services, and closes with CDNs, themes, and page builders.
What Core Web Vitals measure
Core Web Vitals measure three parts of page experience: Largest Contentful Paint measures loading, Interaction to Next Paint measures responsiveness, and Cumulative Layout Shift measures visual stability. Google defines them on web.dev as the subset of Web Vitals that apply to every web page, and all three are currently in the stable stage of the metric lifecycle.
Largest Contentful Paint (LCP) is the time from the start of navigation until the largest image or text block in the viewport is rendered. It stands in for the moment a visitor sees the content they came for, which is usually a hero image, a headline, or the first paragraph.
Interaction to Next Paint (INP) is the latency between a user interaction, such as a click, a tap, or a key press, and the next frame the browser paints in response. It observes every interaction during the visit and reports a value near the slowest, so one sluggish menu or form field sets the score for the page.
Cumulative Layout Shift (CLS) is a unitless score for how much visible content moves unexpectedly while the page is in use. It measures the largest burst of shifts during the visit, weighted by how much of the viewport moved and how far.
The three metrics describe the three ways a page fails a visitor: it is slow to show the content, slow to react to the visitor, or moves under the visitor’s hand. Each needs a different fix, which is why a single speed score hides more than it shows.
Core Web Vitals thresholds
The Core Web Vitals thresholds for a good experience are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, each assessed at the 75th percentile of page loads. web.dev recommends segmenting that percentile by mobile and desktop, so a page passes only when at least three in four visits on each device type meet the threshold.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| Largest Contentful Paint | 2.5 s or less | More than 2.5 s, up to 4 s | More than 4 s |
| Interaction to Next Paint | 200 ms or less | More than 200 ms, up to 500 ms | More than 500 ms |
| Cumulative Layout Shift | 0.1 or less | More than 0.1, up to 0.25 | More than 0.25 |
INP replaced First Input Delay (FID) as the responsiveness metric on March 12, 2024. FID measured only the delay before the browser began handling the first interaction on a page. INP measures the full latency of every interaction, including the time spent running event handlers and painting the result, which makes it a far stricter test of pages that run heavy scripts after they load.
The 75th percentile is the reason averages mislead. A page whose median visit passes can still fail, because the slowest quarter of visits, usually on older phones and slower networks, decides the result. Search Console applies a further rule to URL groups: a group’s status is the status of its poorest metric, so two good metrics do not offset one poor one.
How Core Web Vitals affect rankings
Core Web Vitals affect rankings as one part of the page experience that Google’s core ranking systems reward, and they act as a tie-breaker among pages of similar relevance rather than a substitute for relevance. Google’s page experience documentation states that Search seeks to “show the most relevant content, even if the page experience is sub-par.”
The mechanism follows from that statement. Google’s documentation also says there is no single page experience signal: Core Web Vitals are used by the ranking systems alongside other signals that align with page experience, such as HTTPS and the absence of intrusive interstitials. Where one page answers a query far better than the rest, a poor LCP does not displace it. Where many pages answer a query about equally well, the experience of using them becomes one of the differences the systems can act on.
Three consequences follow for prioritization:
- Improving Core Web Vitals on a page that does not answer its query does not make it rank. Relevance and coverage come first.
- Improving them matters most on competitive queries, where the top results are close in relevance and small differences decide order.
- The ranking effect is assessed on field data from real users, so a lab score that improves while field data stays poor changes nothing in Search.
Google’s 2025 guidance on its AI experiences in Search lists page experience among its top recommendations as well, so the same metrics apply to pages that aim to be cited in AI Overviews and AI Mode.
How page speed affects conversion
Page speed affects conversion through three mechanisms that map to the three metrics: visitors leave before the content appears, interactions feel broken when the page is slow to respond, and shifting layouts cause wrong taps and lost trust. Each mechanism removes visitors at a different point in the journey, so each shows up in a different part of the funnel.
| Metric | What the visitor experiences | Where conversion is lost |
|---|---|---|
| LCP | A blank or half-built page while the main content loads | Before the visit starts: the visitor returns to the results or the ad and never sees the offer |
| INP | A tap on a button, a menu, or a form field that seems to do nothing | During the task: repeated taps, abandoned forms, and duplicate submissions at checkout or enquiry |
| CLS | Text that jumps while reading, and a button that moves as it is tapped | At the decision: misclicks on the wrong element and a page that reads as unreliable |
The losses compound across a journey. A purchase or an enquiry usually takes several page loads, from landing page to product or service page to form, and every load is another chance for the slowest quarter of visitors to leave. A delay that costs a small share of visitors on one page costs that share again on each following page.
Paid traffic pays the cost twice. Google Ads assesses landing page experience as part of Quality Score, and its guidance asks for landing pages that load quickly, so a slow page lowers the return on every click a campaign has already paid for.
The effect on a specific site is measured, not assumed. Real-user monitoring that records each visit’s LCP, INP, and CLS next to its conversion events shows the conversion rate of fast visits against slow ones on that site’s own traffic, which is the only figure worth citing in a business case.
The heaviest causes on WordPress sites
The heaviest Core Web Vitals causes on WordPress sites are oversized images, render-blocking stylesheets and scripts loaded by themes and plugins, page builder markup, uncached server responses, and fonts or embeds that arrive late. Most of them are added by components rather than written by the site owner, which is why they return after every new plugin.
| Cause | Metric it hurts | Fix |
|---|---|---|
| Large hero images in PNG or JPEG at full resolution | LCP | Serve WebP or AVIF at display size, set explicit width and height, and never lazy-load the LCP image |
| Several stylesheets from the theme and each plugin | LCP | Combine into one file and remove rules no template uses |
| Core block library CSS loaded on pages that use no blocks | LCP | Load it only on templates that render blocks |
| Sliders, chat widgets, pop-ups, and tag manager containers | INP | Defer them, load them on first interaction, or remove them |
| Deeply nested page builder markup | INP and LCP | Disable unused modules and keep templates shallow |
| Pages built by PHP on every request | LCP | Serve from a full-page cache, with a CDN for static assets |
| Web fonts that swap in late | CLS and LCP | Preload the main font, use font-display swap, and match fallback metrics |
| Images, ads, and embeds without reserved space | CLS | Set dimensions or an aspect ratio so space is held before they load |
The first three fixes change how files are delivered, not how the site looks, so they can ship without a design change.
Field data vs lab data
Field data is measured from real Chrome users through the Chrome User Experience Report over a rolling 28-day window, while lab data is measured from a single simulated page load by Lighthouse. Google uses field data for Search, and lab data exists to find the cause of what field data reports.
| Property | Field data | Lab data |
|---|---|---|
| Source | Real visits by opted-in Chrome users | One load in a controlled, throttled environment |
| Period | Rolling 28 days | The moment of the test |
| Measures INP | Yes, from real interactions | No; Total Blocking Time is the lab proxy |
| Used for Search | Yes | No |
| Where to see it | Search Console Core Web Vitals report; PageSpeed Insights field section | Lighthouse; PageSpeed Insights diagnostics; Chrome DevTools |
| Best use | Deciding whether a template passes | Finding why it fails and testing a fix before release |
The 28-day window explains a common frustration: a fix shows in Lighthouse the same day, while field data moves over the following four weeks as old visits leave the window. Pages with too little traffic to have their own field data are grouped with similar URLs in Search Console, which is another reason fixes are made in templates.
Core Web Vitals on holisticradar.com
Holistic Radar’s site, holisticradar.com, scores 91 for mobile PageSpeed performance, with a Total Blocking Time of 0 ms, a Cumulative Layout Shift of 0, and a First Contentful Paint of 2.7 seconds, measured in September 2026 with Lighthouse 13.5 on slow 4G. These are lab figures, and they describe the pages every visitor and crawler receives while field data accumulates.
Three fixes produced the result, each aimed at bytes that had to arrive before the first paint:
- Logo. The header logo was a PNG of 31 to 39 KB. It is now a 6 KB WebP, which removes most of the weight of an image that appears on every page.
- Stylesheets. Three stylesheets were combined into one. Each render-blocking request on a throttled mobile connection costs a round trip before the browser can paint, so two fewer requests is two fewer waits.
- Unused block CSS. About 17 KB of core block CSS that the homepage and the listing templates never used was removed from them, so the browser downloads and parses less CSS before it renders.
The 0 ms Total Blocking Time comes from the same discipline applied to scripts: the theme loads few of them, and those it loads are deferred. The CLS of 0 means nothing on the page moves after it is painted. First Contentful Paint is the figure with the most room left: the slow 4G profile adds latency to every request, so each request that still has to finish before the first paint shows directly in that number.
Core Web Vitals in web development services
Core Web Vitals are decided in web development, because the build sets the conditions every page inherits. The image formats, the number of stylesheets, the scripts that load on each template, and whether pages are cached are all choices made in the theme and the build, and they hold for every page created afterwards.
That is why fixing Core Web Vitals page by page does not last. A template that ships with a performance budget keeps passing as content grows, while a site whose speed was tuned after launch loses it with the next plugin, widget, or tracking script.
A reader who now knows which metric fails, and why, needs templates built to pass all three on mobile from the first release.
→ Web development services: how Holistic Radar builds every template to pass Core Web Vitals on mobile.
Core Web Vitals with CDNs, themes, and page builders
Does a CDN fix Core Web Vitals?
A CDN improves LCP by serving files from locations near the visitor and lowering response times, but it does not fix INP or CLS, which are caused by the page’s own code and layout. A CDN that also caches full HTML pages helps most, because server response time is the first part of every LCP measurement.
Which WordPress themes pass Core Web Vitals?
WordPress themes that pass Core Web Vitals ship little CSS and JavaScript, print content as HTML, and load features only on the templates that use them. A theme demo is not evidence, because demos run without the plugins, tracking scripts, and real images a live site adds, so the test is made on the site’s own templates with its own plugins active.
Do page builders fail Core Web Vitals?
Page builders do not fail Core Web Vitals by default, but they add nested markup and per-widget CSS and JavaScript that make passing harder. Builders that load assets only for widgets on the page, with unused modules disabled and pages served from a cache, can pass all three metrics on mobile.
Can a caching or optimization plugin fix Core Web Vitals on its own?
A caching or optimization plugin fixes server response time and can defer scripts or combine files, but it cannot remove weight that the theme and other plugins add. It improves LCP on most sites and helps INP when it delays scripts, yet a heavy template still fails once its scripts run.