Core Web Vitals: a fast, stable site
A slow page loses users before anything else.
Web performance is not only a technical topic: it is a business factor. Every fraction of a second of loading delay reduces the chance that the user stays, and every sudden layout shift — a button that moves just as you are about to click — creates frustration and abandonment. On an e-commerce this translates directly into lost sales; on a services site, into lost contacts. I treat performance as a project constraint in website creation and as a specific intervention on existing sites, often starting from an audit.
The three metricsWhat the Core Web Vitals measure
Core Web Vitals are the three metrics with which Google measures a page’s loading experience, interactivity and visual stability: LCP (Largest Contentful Paint, how long the main element takes to appear), INP (Interaction to Next Paint, how quickly the page responds to the user’s actions) and CLS (Cumulative Layout Shift, how much the content shifts during loading). The reference documentation is web.dev on Web Vitals. They are part of the page experience signals and affect ranking and, above all, conversion: a slow or unstable page loses users before anything else.
LCP measures the time from the start of loading to the appearance of the largest visible content element: usually a hero image or a block of text. A good LCP is within 2.5 seconds. INP measures the overall latency of the user’s interactions with the page — clicks, taps, typing — and reflects how much the page “responds”: a good value is within 200 milliseconds. CLS quantifies how much elements shift unexpectedly during loading; a good value is below 0.1.
THE THREE METRICS AND THE “GOOD” THRESHOLDS
FIELD DATA (REAL USERS, USED BY GOOGLE) · LAB DATA (CONTROLLED TESTS, FOR DIAGNOSING)
The metrics are read on two types of data. The field data come from real users and are the ones Google uses for the assessment: they are found in the Page Experience report of Google Search Console and in the Chrome UX Report. The lab data come from controlled tests such as Lighthouse and PageSpeed Insights: they serve to diagnose and simulate, but don’t replace real data, which can differ depending on devices, connections and the behavior of the specific audience.
Performance, ranking and conversions
On the ranking side, the Core Web Vitals are one of the experience signals: at equal relevance and authority, a page with a better experience is favored. It is not a dominant factor — content and authority weigh more — but on competitive queries it can make the difference, and poor performance can limit the potential of an otherwise strong page.
On the conversion side the effect is more direct and measurable. A site that loads quickly and stays stable retains more visitors, reduces bounce rate, increases pages viewed and form and checkout completions. On an e-commerce, the link between product page speed and conversion rate is clear. That is why I consider performance a lever for return, not a technical formality.
The most common causes of poor performance
What worsens LCP
Images that are too heavy or not sized for the space they appear in, fonts loaded in a blocking way, critical resources served late, hosting slow to respond.
What worsens INP
The page runs too much browser-side code, often from third-party resources — tracking tags, widgets, chat, ads — that occupy the main thread and delay the response to the user’s actions.
What worsens CLS
Images and iframes without declared dimensions, content inserted dynamically above what is already visible (banners, notices), fonts that change the text footprint on load.
On WordPress and PrestaShop a recurring structural cause is added: the accumulation of plugins or modules installed over time, each of which loads its own CSS and code on every page, even where not needed. It is the reason a disciplined installation starts with an advantage.
How I intervene on performance
Survey
Field data from Search Console and Chrome UX Report, lab data from PageSpeed Insights, for LCP, INP and CLS on typical pages (home, service, article, category, product).
Diagnosis
Identifying the LCP element and what delays it, the tasks blocking the main thread, the elements causing shifts.
Image optimization
Modern formats, correct sizing, deferred loading for what is below the fold, priority to the LCP element.
CSS and browser-side code management
Removing the unused, deferring the non-critical, reducing and controlling third-party resources.
Layout stability
Explicit dimensions for media and dynamic content, reserved space for banners and notices, font loading management.
Environment
Server-side cache, updated runtime version, CDN where useful.
Verification
New tests and waiting for updated field data, which consolidate over a few weeks.
Optimizing for the score and not for theexperience produces good numbers and dissatisfied users.— Andrea Viggiano, approach to web performance
Performance within threshold at launch or to be recovered afterwards
| Site born with performance as a constraint | Site to optimize afterwards | |
|---|---|---|
| Theme and components | Chosen lightweight, justified one by one | Layered over time, hard to remove |
| Images | Optimization pipeline from the start | To be reworked in bulk |
| Third-party resources | Minimum number, controlled loading | Accumulated, often with no inventory |
| CLS | Prevented at the development stage | To be fixed element by element |
| Cost of the intervention | Included in the project | Higher, with risks on an indexed site |
The role of third-party resources
Third-party resources are often the single factor that most degrades INP and weighs down loading. Every analytics tag, advertising pixel, social widget, chat, embedded map or testing tool adds code that runs in the user’s browser. The solution is not always to eliminate them — some are needed — but to govern them: keep an inventory of what is loaded and why, load deferred what isn’t needed right away, evaluate lighter alternatives, and periodically review the list, removing what is no longer used. On many sites, a targeted intervention on these resources alone brings INP back within threshold.
Performance and perceived experience
The Core Web Vitals are an approximation of real experience, not the experience itself. It is worth also looking at what the user perceives: how quickly something useful appears on screen, whether scrolling is smooth, whether typing in a field is responsive, whether the page “jumps” during loading. Optimizing only for the score, without verifying the experience on a modest device and an average connection — the real conditions of a good part of the audience — leads to good numbers and still-dissatisfied users. I always check both.
Performance for e-commerce
On an e-commerce performance must be measured where revenue is generated: category pages and product pages, not just the home. What counts is the speed of the first product page viewed, the responsiveness of filters, the smoothness of cart and checkout, and resilience under load in peak periods. An optimization that improves the home but leaves product pages slow doesn’t move sales. This is the link with PrestaShop e-commerce development.
Measurement tools
For the Google Core Web Vitals I cross-check Google PageSpeed Insights, the Page Experience report in Google Search Console and the Chrome User Experience Report, that is the Chrome User Experience database (CrUX) based on real data. Searches also call these tools Google Web Vitals or web vitals: the point is not the name, but distinguishing field data from lab simulations. PageSpeed Insights and Lighthouse help reproduce loading conditions and isolate the LCP element, the code that delays interaction and the causes of instability; Search Console and CrUX instead show how groups of URLs behave for real users.
Optimizing for ranking
Optimizing the Core Web Vitals doesn’t mean chasing an isolated score: it means connecting technical optimization to the pages that need to gain visibility. I analyze resource loading, images, CSS, browser-side code and third-party resources, then define what to monitor to maintain performance over time. The work starts from ranking and business goals: I intervene first on the pages that bring traffic, contacts or revenue and verify the effect on field data.
Ranking and user experience
In Google search the Core Web Vitals are an experience signal, inside an algorithm that also considers relevance, content and authority. They are not the only ranking factor and don’t make up for a weak strategy, but a slow or unstable page can reduce the quality of the experience, trust and the likelihood of conversion. That is why I assess ranking, user experience and commercial results together.
How to read the terms
In reports and searches you may see phrases like Google Core Vitals, Google Web Vitals, web vitals or CLS Vitals. These are different ways in which users describe the monitoring of experience metrics: the official name remains Core Web Vitals, with LCP, INP and CLS. When I analyze a site, I translate these terms into verifiable actions and technical priorities the team can understand.
How performance work is measured
The indicators are the three Core Web Vitals on field data, by group of pages, with the goal of bringing and keeping the share of “good” URLs toward 100% in the Page Experience report of Search Console. Alongside these are the downstream effects: change in bounce rate and pages per session, form and checkout completion rate, and — where measurable with controlled tests — the impact on conversion rate. Performance is assessed over time, because field data consolidate over a period of a few weeks after the intervention.
Frequently asked questions about performance and Core Web Vitals
What is meant by web?+
In the context of this service, the web is the set of pages, resources, browsers, devices and connections through which a person uses a site. It is not enough for a page to be online: it must be accessible, readable and responsive in the audience’s real conditions. It is on this complete experience that I measure performance, stability and conversions.
What is Core Web Vitals optimization?+
It is the process with which I improve LCP, INP and CLS starting from field data, identify the technical causes and verify the result after the intervention. It includes images, code, third-party resources, fonts, layout and hosting environment; the goal is not just a better score, but a faster, more stable site that is more useful for SEO, user experience and conversions.
Is a good Lighthouse score enough?+
No: Lighthouse gives lab data useful for diagnosing, but Google evaluates field data, collected from real users. The two can differ: the goal is to improve field data, not just the score of a test.
Are Core Web Vitals a strong ranking factor?+
They are one of the experience signals, not among the most decisive: content and authority weigh more. But on competitive queries they make the difference, and poor performance limits a page’s potential.
How long does it take to see the effects of an optimization?+
The effects on experience and conversions are immediate for users; field data in Search Console update over a span of a few weeks, because they are a moving average of real traffic.
Does a cache plugin solve everything?+
It helps, but it isn’t enough: a cache doesn’t reduce the weight of images, doesn’t eliminate superfluous third-party resources and doesn’t prevent layout shifts. You need work on the causes, not only on page delivery.
Can I improve performance without rebuilding the site?+
Often yes: image optimization, CSS and browser-side code management, control of third-party resources and CLS correction can be applied to an existing site. A rebuild is considered only if the problems are structural in the theme or the framework.
Is it a standalone service or part of site creation?+
In site creation it is an included project constraint; on existing sites it is a specific intervention, which can be part of an audit or requested on its own.
Does the mobile version have different metrics from desktop?+
Yes, and Google mainly evaluates the mobile experience. A site that does well on desktop can have LCP and INP out of threshold on mid-range smartphones with a less-than-ideal connection, which is the real condition of much of the audience. Optimization starts from mobile.
Why does my score change with every test?+
Lab tests simulate conditions that vary slightly with each run (network, server load, cache). That is why you look at several measurements and, above all, at field data, which are an average of real traffic and much more stable.
Do ads and cookie banners worsen Core Web Vitals?+
Often yes: ads load heavy resources and can shift the layout; consent banners inserted above the content are a classic cause of CLS. They are mitigated by reserving the space, loading in a controlled way and choosing lighter implementations.
Does improving performance also help AI answer engines?+
Indirectly yes: fast pages served cleanly are easier to retrieve and read for the crawlers feeding AI Overviews and assistants. Speed is not the main factor for being cited, but a slow, unstable site starts at a disadvantage.
Request an intervention on performance and Core Web Vitals
I measure your site’s Core Web Vitals on real data, identify the causes of slowness and instability and intervene on images, code, third-party resources and environment, verifying the effect on experience and conversions.
To learn more about website creation
Blog guides on the topic of this page.
How fast is your site?
An assessment of current performance on real data, no commitment.
Request a first analysis