PERFORMANCE
Core Web Vitals are worth improving when they reveal a real user problem: the main content takes too long to appear, interactions feel delayed or the layout shifts while someone is trying to use the page. They are not a reason to rebuild half a website just to move a PageSpeed Insights score from 93 to 100.
Short answer
In 2026, Google’s three Core Web Vitals are LCP, INP and CLS. A “good” result is LCP up to 2.5 seconds, INP up to 200 ms and CLS up to 0.1. The Core Web Vitals assessment is based on real-user experience and uses the 75th percentile rather than one test on your own computer.
What are Core Web Vitals?
| Metric | What it measures | Good result |
|---|---|---|
| LCP — Largest Contentful Paint | how quickly the main visible content appears | ≤ 2.5 s |
| INP — Interaction to Next Paint | how quickly the page responds to user interaction | ≤ 200 ms |
| CLS — Cumulative Layout Shift | visual stability while the page loads and changes | ≤ 0.1 |
Do Core Web Vitals affect SEO?
They are part of the overall page experience, but they are not a shortcut to rankings. A page with 100/100 in PageSpeed does not automatically outrank a more relevant and helpful page scoring 85.
Performance matters because it affects real usability and can contribute to how well a page works as a whole. It should be improved alongside content, architecture, internal linking and technical SEO rather than treated as a separate competition for a perfect score.
First, understand which data you are looking at
Real-user data — CrUX
The field-data section in PageSpeed Insights uses Chrome UX Report (CrUX) data. It reflects actual visits by Chrome users under different devices, connections and conditions.
Laboratory test — Lighthouse
PageSpeed Insights also runs a controlled Lighthouse test. This is useful for diagnostics: it can help identify the LCP element, render-blocking resources, long JavaScript tasks and other technical causes.
One Lighthouse run, however, does not describe the experience of all users.
What if the results are different?
You can have good CrUX data and a weaker laboratory test, or a strong Lighthouse score while real users still experience problems. In that situation, use field data to understand the real scale of the issue and laboratory tools to investigate the cause.
Why does Google use the 75th percentile?
The 75th percentile means, in simplified terms, that the experience should be good for the large majority of visits—not only for people using fast broadband and a new device.
That is why FreenetPro pays particular attention to mobile and real-user data instead of judging performance from a single PageSpeed screenshot.
What should you improve first?
Not every PageSpeed recommendation has the same priority. Start with the metric that is actually failing and the element responsible for it.
LCP — when the main content appears too late
A good LCP is no more than 2.5 seconds. Typical causes include a heavy hero image, slow server response, render-blocking CSS, delayed fonts, excessive client-side rendering or loading the LCP asset too late.
If the LCP element is the hero image, lazy-loading it can make the result worse rather than better. The important asset should be requested early and delivered efficiently.
INP — when you click and nothing happens
A good INP is no more than 200 ms. Poor INP is often caused by long JavaScript tasks, too much work on the main thread, heavy third-party scripts, inefficient event handlers or complex interfaces that do too much after each interaction.
Why INP matters to the business
Users do not know the term INP. They simply feel that the site is sluggish. Improving INP is therefore not only a technical task for Google; it can make navigation, forms, menus, filters and product selection noticeably easier to use.
CLS — when the page jumps during loading
A good CLS is no more than 0.1. Common causes include images without reserved dimensions, banners inserted above existing content, late-loading fonts, dynamically injected elements and components whose final size is not known when the page first renders.
The fix is usually to reserve space and make the layout predictable, not to hide shifts after they occur.
Do you need 100/100 in PageSpeed Insights?
No. A better goal is a website that is fast, stable and responsive for real users, with good field data and no obvious performance bottleneck.
Continue optimizing when the remaining issue affects many users, a key conversion path or an entire page template. If the site is already healthy and the remaining recommendation has little practical impact, further work may have a lower business priority.
The most common mistake: optimizing the score instead of the website
It is easy to remove a useful feature or load something unnaturally just to improve a laboratory score. The question should always be whether the change makes the real experience better without breaking functionality, SEO or conversion.
WordPress and Core Web Vitals — what usually has the biggest impact?
On WordPress sites, common factors are heavy themes or builders, too many plugins, duplicated scripts, large unoptimized media, slow hosting, excessive third-party code and database or caching problems.
Is a cache plugin enough?
Sometimes caching produces a large improvement, but it cannot fix every structural problem. It will not remove unnecessary JavaScript, simplify a heavy layout or repair a poorly implemented interaction.
What about animations?
Animations are not automatically bad. Problems appear when they block interaction, trigger expensive layout work, cause visual shifts, autoplay constantly or depend on heavy libraries for a small visual effect.
Use motion where it supports understanding and keep a prefers-reduced-motion path for users who request less animation.
What about Google Tag Manager, analytics and chat widgets?
Third-party scripts can add measurable cost. That does not mean removing analytics or useful tools, but each script should have a clear purpose. Load it at the right moment, avoid duplicates and remove tools that no longer support a business requirement.
How to check Core Web Vitals step by step
1. Start in Search Console
See whether groups of real URLs have Core Web Vitals problems and whether the issue is mainly mobile or desktop.
2. Open PageSpeed Insights
Compare field data and laboratory diagnostics.
3. Check mobile first
Mobile often exposes slower devices, weaker networks and interface problems that are hidden on a powerful desktop computer.
4. Identify the failing metric
If CLS is the problem, server optimization may change little. If INP is poor, compressing the hero image may not address the cause.
5. Find the responsible element or code
Use Lighthouse and DevTools diagnostics to identify the specific LCP element, script, long task or layout shift.
6. Make one useful change and test again
Check that the fix did not create a new visual, functional or accessibility problem.
7. Wait for new field data
CrUX data does not change immediately after deployment. PageSpeed Insights uses a rolling 28-day field-data period, so improvements appear gradually.
What is really worth improving — priorities
Priority 1 — a problem users can feel
Slow main content, delayed controls or visible layout jumps deserve attention first.
Priority 2 — poor field Core Web Vitals
If real-user data repeatedly shows a failing metric, the problem is more important than one unusual lab run.
Priority 3 — a problem repeated across a template
Fixing a shared product, article or service template can improve many URLs at once.
Priority 4 — an issue that also affects conversion
A slow product-variant selector is usually more important than a minor Lighthouse note on a page almost nobody visits.
Priority 5 — cosmetic optimization
Once the real experience is good, further score-chasing should be weighed against other priorities.
Core Web Vitals when building a new website
Performance is easiest to protect before launch: choose a lightweight architecture, limit dependencies, size media correctly, plan the hero/LCP element, avoid layout shifts and test mobile early. This is usually cheaper than building a heavy site first and trying to “save PageSpeed” later with more optimization plugins.
Does a faster website always sell more?
No honest provider can promise that reducing LCP by half a second will automatically increase sales by a fixed percentage. Performance removes friction; the commercial effect still depends on the offer, traffic quality, UX, trust and many other factors.
Core Web Vitals checklist
- ☐ Am I looking at real-user data or only Lighthouse?
- ☐ Do I know the specific LCP element?
- ☐ Is INP being affected by unnecessary JavaScript?
- ☐ Are image and component dimensions reserved to avoid CLS?
- ☐ Have I checked mobile separately?
- ☐ Are third-party scripts genuinely needed?
- ☐ Does the fix improve the site, not just the score?
- ☐ Have I verified the result again after deployment?
From FreenetPro practice
If one badly prepared image damages LCP, we fix the image. If INP comes from too much JavaScript, we look for unnecessary code. If the whole site is built from heavy dependencies and every optimization creates another conflict, then we assess whether the problem is architectural.
FAQ
What are the Core Web Vitals in 2026?
LCP, INP and CLS. LCP measures how quickly the main content appears, INP measures responsiveness during interaction and CLS measures layout stability.
What is a good LCP?
Google classifies LCP up to 2.5 seconds as good. Between 2.5 and 4 seconds needs improvement; above 4 seconds is poor.
What is a good INP?
A good INP is up to 200 ms. Values above 500 ms are classified as poor.
What is a good CLS?
A good CLS is up to 0.1. Values above 0.25 are considered poor.
Will PageSpeed 100/100 improve Google rankings?
Not automatically. Relevance, useful content and the overall quality of the site remain more important than a perfect laboratory score.
Why does PageSpeed show a different score each time?
Laboratory tests depend on test conditions and can vary slightly. Use CrUX field data and trends rather than judging the site from one run.
Why is there no real-user data in PageSpeed Insights?
Not every URL has enough Chrome UX Report data. PageSpeed may show origin-level data or laboratory data only. Missing CrUX data does not prove that the page is good or bad.
Are Core Web Vitals more important on mobile?
The same metrics matter across devices, but mobile often reveals more real-world constraints, so it deserves separate attention.
Will a cache plugin fix Core Web Vitals on WordPress?
It can help, but it cannot solve every problem. Structural issues, unnecessary scripts and heavy components usually need direct fixes.
How long does it take to see an improvement?
Lab results can change immediately after deployment. CrUX field data uses a rolling 28-day period, so real-user improvements appear gradually.
What next?
Start with the metric and page type that causes the biggest real problem. Fix the root cause, verify the change and then decide whether further optimization is still worth the effort.