The three metrics Google actually measures
Core Web Vitals optimisation targeting LCP, INP, and CLS specifically - not generic speed advice that misses the metrics that count.
Core Web Vitals are three specific, named metrics Google uses to judge a page's real-world experience: Largest Contentful Paint (how fast the main content appears), Interaction to Next Paint (how quickly the page responds when someone actually clicks or taps), and Cumulative Layout Shift (whether elements jump around while the page loads). A page can score well on a generic speed test and still fail one of these, because they measure specific moments a generic test doesn't isolate.
This distinction matters because fixing the wrong thing is common. A team that shrinks images to improve 'speed' may do nothing for INP if the actual problem is a heavy JavaScript bundle blocking the main thread when a user taps a button. Each metric has its own cause and its own fix.
Core Web Vitals optimisation is the process of diagnosing and fixing the three specific metrics Google measures for page experience - LCP, INP, and CLS - individually, rather than applying general speed advice and hoping it covers all three.
What we bring to this
LCP Diagnosis & Fixes
- Identifying the actual largest content element and what delays it
- Server response time and render-path fixes
- Preloading and prioritising the correct resource
INP Optimisation
- Main-thread blocking script identification
- Event handler and input responsiveness tuning
- Third-party script impact assessment
CLS Elimination
- Reserving space for images, ads, and embeds before they load
- Font-loading strategy to prevent layout jumps
- Dynamic content injection review
Field Data Monitoring
- Search Console Core Web Vitals report tracking
- Real-user monitoring, not just lab test scores
Scope of work
| Area | What's included |
|---|---|
| Diagnosis | Per-metric breakdown of what is causing each Core Web Vitals score to fail, by page template |
| Fixes | Implementation of the specific technical changes each metric requires |
| Field Data Setup | Search Console and real-user monitoring configured to track real visitor experience, not just a lab score |
| Regression Tracking | Ongoing monitoring so a passing score does not quietly slip back to failing |
The engagement, step by step
Field data review
We start with real-user data from Search Console, not just a single lab test, since lab scores can miss what actual visitors on real networks experience.
Per-metric diagnosis
Each failing metric is diagnosed on its own terms - LCP, INP, and CLS have different root causes and do not share a fix.
Template-level fixes
Fixes are applied at the template level where possible, since most Core Web Vitals problems repeat across every page using the same layout.
Verification against field data
Changes are checked against real-user field data, not just a lab re-test, since lab and field results can diverge.
Ongoing tracking
Search Console and monitoring stay in place after the fix, so a new script or image doesn't quietly push a metric back into the red.
How this compares
| Metric-Specific Diagnosis | Generic Speed Advice |
|---|---|
| Identifies which of LCP, INP, or CLS is actually failing | Treats "speed" as one undifferentiated problem |
| Fixes match the specific cause per metric | Common fixes (image compression) may not touch INP or CLS at all |
| Verified against Search Console field data | Often verified against a single lab test only |
Where this fits
- A site ranks well but Search Console flags Core Web Vitals as "Needs Improvement," which can affect how it competes against pages that pass
- A redesign introduced layout shift from ads or embeds that were not accounted for during development
- A page feels fast to load but sluggish to interact with, which points to an INP problem rather than a loading problem
Who needs this
Sites flagged in Search Console
Where the Core Web Vitals report shows pages in the "Needs Improvement" or "Poor" category.
Sites that pass lab tests but underperform in the field
A gap between lab and field data usually means real users on real devices are having a different experience than the test.
What changes for you
- Pages meet the specific thresholds Google measures, rather than a general sense of "faster"
- Interactions feel responsive because INP is diagnosed and fixed on its own terms, not bundled into a generic speed pass
- Layout stops jumping during load, which removes a common source of accidental clicks and visitor frustration
Why work with EASI7 on this
- We diagnose LCP, INP, and CLS as three separate problems with three separate causes, instead of one generic speed pass
- We verify against Search Console field data, not just a lab score that may not reflect what real visitors experience
Other services in this area
Every second of load time is a conversion cost
Website speed optimisation covering hosting, code, and asset delivery - fixed at the source, not patched with a caching plugin.
Built and tested on the devices your customers use
Mobile-specific optimisation for load time, layout, and usability - verified on real devices and real networks, not a desktop browser emulator.
Prevention is cheaper than a breach
Website security hardening covering SSL, updates, backups, and vulnerability monitoring - built around the fact that most compromises exploit known, unpatched holes.
A site that keeps working after launch
Ongoing website maintenance and support covering updates, monitoring, and small fixes - the recurring work that keeps a site from quietly degrading.
Common questions
They're a confirmed ranking signal, but a modest one relative to content relevance and backlinks. The more consistent impact is on conversion - visitors leave a slow, jumpy, unresponsive page before they ever see your offer, regardless of where it ranks.
No. We can diagnose exactly what is failing and fix the specific cause, and most sites do reach passing thresholds once the real bottleneck is addressed - but third-party scripts, ad networks, or platform constraints outside our control can limit what's achievable on some pages.
Search Console reports field data - real visits from real users on real devices and networks - while most speed testing tools report a single lab simulation. The two can diverge, especially on INP, which depends heavily on the visitor's actual device.
INP tends to take the most work, because it is often caused by third-party scripts (analytics, chat widgets, ad tags) that are outside your own codebase and harder to control directly.
Field data is based on a rolling 28-day window of real visits, so even a fix deployed today will not show improvement in Search Console for several weeks. A lab test will show the change immediately, but the field report lags by design.
There's overlap, but Core Web Vitals work targets these three specific metrics and their specific causes, while general speed optimisation covers broader load-time and asset concerns that may not move LCP, INP, or CLS directly.
Flagged in Search Console for Core Web Vitals?
We can tell you which of the three metrics is actually failing and why, before recommending a fix.
Talk to us →