Core Web Vitals: speed fixed in the code, not with a plugin
LCP, INP and CLS measure what visitors feel: how soon the page shows, how fast it responds, how much it jumps. We diagnose from field data, find the cause in a trace and fix it in your framework.
One page load. LCP is the moment the largest visible element (here, the hero image) finishes rendering. CLS accumulates when late assets such as fonts or ads push content around. INP measures the delay between a tap and the next frame, which long JavaScript tasks make worse.
LCP · loading
Largest Contentful Paint
Time until the largest text block or image in the viewport is rendered. Good: 2.5s or under. Dominated by server response, render-blocking CSS and the hero image's discovery and size.
INP · responsiveness
Interaction to Next Paint
The worst delay between a user interaction and the next screen update, across the visit. Good: 200ms or under. Caused by long JavaScript tasks, heavy event handlers and hydration.
CLS · stability
Cumulative Layout Shift
How much visible content moves unexpectedly. Good: 0.1 or under. Caused by images without dimensions, late fonts, injected banners and ads.
Fixes
The causes we find most, and what we do about them
Metric
Common cause
Fix
LCP
Slow server response (TTFB)
Page caching, CDN, database query fixes, edge rendering on Cloudflare where it fits
LCP
Hero image discovered late or oversized
Preload the LCP image, serve responsive sizes in WebP or AVIF, never lazy-load above the fold
LCP
Render-blocking CSS and JavaScript
Inline critical CSS, defer non-critical scripts, remove unused CSS from the theme
INP
Long tasks from third-party scripts
Audit tags, load them after interaction or in a worker, remove the ones nobody uses
INP
Heavy hydration in React or Next.js
Server components, code splitting, lazy hydration of below-the-fold widgets
INP
Event handlers that do too much
Yield to the main thread, debounce, move work off the interaction path
CLS
Images and embeds without dimensions
Width and height attributes or aspect-ratio boxes on every media element
Reserve space or overlay instead of pushing content
Measurement
Lab data finds the cause. Field data tells the truth.
Search Console and the Chrome UX Report show what real visitors experience at the 75th percentile, grouped by URL pattern. That is the number that decides whether a page passes. Lab tools such as Lighthouse and performance traces run on one machine and are for finding out why.
We start with field data per template, pick the worst templates, record traces on a throttled mid-range device, and fix the longest chain first. After each fix we wait for the field data to update, which takes about 28 days, and confirm the improvement with real visitors rather than a screenshot.
For sites without enough traffic for field data, we add a small real-user monitoring script and build the dashboard in your analytics so the numbers stay visible after we leave.
Week 1
Diagnose
Field data per template, traces for the worst, a ranked list of causes with expected gain.
Weeks 2–3
Fix
Pull requests in your repo: images, caching, critical CSS, script loading, hydration, layout reservations.
Week 4+
Verify
Field data confirms the change. A performance budget is added to CI so regressions fail the build.
Google's published 'good' thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1, measured at the 75th percentile of real user visits. A page passes when all three are good for most of its visitors, not when a lab tool scores it 100.
Why does Lighthouse say 95 but Search Console says we fail?
Lighthouse is a lab test on one simulated device and connection. Search Console uses field data from real Chrome users on real devices and networks. A page can be fast in the lab and slow for the visitors who matter. We diagnose with lab traces but we measure with field data.
Do Core Web Vitals affect rankings?
They are a ranking signal among many, and a modest one. The bigger effect is on conversion: slow or jumpy pages lose visitors before they read anything. We treat performance as a revenue input first and a ranking input second.
Can you fix performance on WordPress?
Yes. Most WordPress problems are theme and plugin weight, render-blocking assets, unoptimised images and no caching layer. We fix them at the theme and server level rather than stacking another optimisation plugin on top.
How long does a performance project take?
Diagnosis takes about a week. Fixes range from a few days for image and caching work to three or four weeks for a JavaScript-heavy front end that needs server rendering or code splitting. We agree the scope after diagnosis.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.