The three metrics and what people experience
Core Web Vitals measure different aspects of page experience. Largest Contentful Paint, or LCP, concerns when the main visible content is rendered. Interaction to Next Paint, or INP, concerns responsiveness to interactions. Cumulative Layout Shift, or CLS, concerns unexpected movement of visible content.
The official Web Vitals guidance identifies the good thresholds as LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, assessed at the 75th percentile of page visits for the relevant field evaluation.
| Metric | A visitor might notice | Start investigating |
|---|---|---|
| LCP | The main image or headline takes too long to appear. | Server response, resource discovery and the main content asset. |
| INP | A menu, button or input feels slow to respond. | Long tasks, event handlers and rendering work. |
| CLS | Text or controls jump while the page loads. | Missing dimensions, late inserts and changing layout. |
These are diagnostic categories, not three interchangeable speed scores. A page can load its main content quickly while feeling slow when a visitor opens a menu.
Separate field data from lab tests
Field data reflects real visits across devices, networks and user behavior. Lab tests run under a chosen simulated or controlled configuration. Both are useful, but they answer different questions.
A lab test is good for investigating a change: same URL, same device profile, same connection settings, before and after. Field data is better for understanding the experience actually observed by visitors, subject to the available sample and reporting window.
A new or low-traffic site may not have enough field data for a page-level report. That is not a pass or a failure. Use careful lab diagnosis and real device checks while the site develops a meaningful sample.
Do not compare an empty test theme on one host with a production page full of tracking scripts on another and call it a hosting benchmark. Keep the workload comparable.
Fix LCP by finding the actual main element
Identify the element contributing to LCP on the page you are testing. It may be a hero image, a block of text or another large visible element. Then ask what prevented it from appearing earlier.
If the server response is slow, inspect application work, caching and geographic distance. If the response is quick but the image arrives late, check discovery and resource priority. If the file is large, serve an appropriately sized compressed image rather than sending a full-resolution original to a small viewport.
Do not lazy-load the primary image that should appear immediately in the first viewport. Reserve lazy loading for appropriate below-the-fold assets. Set image dimensions so the layout can be calculated before the file finishes loading.
For text-based LCP, examine font loading and render-blocking styles. A custom font is a design choice with a loading cost; a well-selected system font can avoid that dependency. Test with the cache state your visitors are likely to encounter.
Fix INP by reducing work around the interaction
A slow interaction can result from work already blocking the main thread, a heavy event handler or expensive rendering after the handler. Diagnose the interaction that actually feels delayed instead of assuming every script contributes equally.
Open the menu, type into search, expand a filter and submit a form. Observe whether the interface responds immediately and whether feedback remains clear while work continues. A button that appears inert can lead people to click repeatedly.
Reduce unnecessary JavaScript and avoid rebuilding large portions of the page for a small state change. Break up work where appropriate, keep event handlers focused and defer nonessential tasks. Third-party scripts deserve the same scrutiny as your own code.
Test on a modest device profile. A fast development computer can conceal long tasks that become obvious on a phone. The practical aim is a responsive journey, not simply a smaller script file.
Fix CLS by reserving space and controlling inserts
Unexpected movement is especially frustrating when a visitor is about to tap a link or read a paragraph. Common causes include images without dimensions, late-loading embeds, banners inserted above existing content and font changes that alter line wrapping.
Reserve the expected space for images and embedded media. If an element has variable height, design the loading and final states deliberately. Do not insert a late promotional strip at the top of a page and let the entire article jump downward.
Check font fallbacks and text wrapping at different widths. A layout that is stable on desktop may shift on mobile because the content occupies more lines. Test the actual text rather than a short placeholder.
Some movement follows a user action and is expected; other movement happens without warning. Use the measurement tools to identify the sources and confirm that your fix addresses the unexpected shift.
Use a repeatable before-and-after worksheet
| Record | Why it matters |
|---|---|
| URL and page type | The homepage may behave differently from an article or checkout. |
| Device and network profile | Results depend heavily on the test environment. |
| Cache state | A returning visitor can receive a different loading path. |
| Metric and contributing element | Keeps the fix tied to an observed cause. |
| Single change made | Prevents several edits from hiding which one helped. |
| Functional checks | A faster page still needs working forms, navigation and content. |
Run a few consistent measurements and look for a repeatable improvement. Keep the raw results or notes, especially if the change will be used to support a public performance claim.
After a successful lab fix, watch the field trend when sufficient data becomes available. Do not expect a historical reporting window to change instantly after a deployment.
When a hosting upgrade helps, and when it does not
Hosting can affect server response and the ability to handle application work. If the account is resource-constrained or the server is far from the audience, a better-fitting plan or location may help.
A more expensive host will not automatically remove oversized images, layout shifts from missing dimensions or a slow third-party widget. Diagnose those problems directly. Similarly, caching may help a public article while doing less for a personalized checkout.
Before migrating, verify whether the bottleneck is actually at the hosting layer. Read how to choose hosting and compare the same representative workload. If a move is justified, use a rollback-aware migration plan.
Keep performance aligned with the reader’s task
Do not remove useful information or break a needed integration merely to improve a score without considering the effect on visitors. A product comparison still needs readable tables. A business site still needs a working enquiry path.
Prefer simpler implementation where it serves the task: fewer third-party dependencies, appropriately sized images, clear navigation and focused interactions. Recheck important pages when templates or shared scripts change.
Core Web Vitals are part of a broader page experience. They do not guarantee search rankings, conversions or business success. Pair the technical work with accurate content and a website people can use confidently.
Frequently asked questions
What are good Core Web Vitals values?
The cited guidance gives LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, evaluated at the relevant 75th-percentile field level.
Why is my lab score different from field data?
Lab and field measurements use different conditions and samples. Lab results are useful for diagnosis; field data reflects real visits over a reporting period.
Will faster hosting fix every performance issue?
No. Hosting may help server response, but images, scripts, layout and application behavior can require separate fixes.
Sources & editorial notes
Sources checked on September 6, 2026. Product details can change by country, platform and billing term. Prices shown are snapshots, not live quotes.
- web.dev: Core Web Vitals and field thresholds
- web.dev: how thresholds are defined
- Google Search Central: broader site experience and SEO
This guide combines published documentation with our editorial analysis. We have not measured provider performance or conducted an independent security audit. Read our methodology. Report a correction.

