Core Web Vitals are Google’s headline performance metrics. They’re a ranking signal, they correlate strongly with conversion rate, and most SMB sites still miss the targets. Through 2024-2026 the metric set has shifted — Interaction to Next Paint (INP) replaced First Input Delay, the thresholds have stayed stable, and the diagnostic tools have gotten better. Here’s the 2026 state of the art and the targets we ship to on every FH client site.
The three metrics
- LCP (Largest Contentful Paint): time until the largest visible element renders. Target: under 2.5s.
- INP (Interaction to Next Paint): worst-case delay between user input and the next render. Target: under 200ms.
- CLS (Cumulative Layout Shift): unexpected visual movement during page load. Target: under 0.1.
All three measured at the 75th percentile of field data over a 28-day window. Lab data (Lighthouse) is a starting point but the field data from real users is what Google ranks on.
LCP: the headline number
LCP is the time until the largest visible element renders — typically the hero image or the main headline. The under-2.5s target is met by ~55% of SMB sites in our audit data. The bottom 25% are over 4 seconds, which is a ranking liability and a conversion catastrophe.
The four biggest LCP killers we see in audits: unoptimized hero images (often 1-3MB JPEGs served raw), render-blocking JS (often a CMS theme), web fonts blocking the hero text, and slow origin servers (cheap shared hosting). The SMB speed post covers the canonical fixes.
INP: the interaction metric
INP replaced FID (First Input Delay) in March 2024. INP measures the worst interaction latency over the user’s session — not just the first one. It’s a much harder bar than FID was. Sites that passed FID often fail INP.
The under-200ms target is missed by sites that ship too much JavaScript or that block the main thread on long tasks. Common culprits: heavy third-party scripts (chat widgets, tag managers), inefficient React re-renders, lack of debouncing on search inputs. We measure with PageSpeed Insights and the Performance tab in Chrome DevTools.
CLS: the layout-stability metric
CLS measures unexpected movement of visible elements during load. Common causes: images without width/height attributes, fonts swapping in and pushing text around, ads or embeds loading into spaces that weren’t reserved, sticky elements appearing without proper anchoring.
Hitting under 0.1 is mostly a discipline thing: always specify image dimensions (next/image forces this), use font-display: optional or swap with size-adjust, reserve space for embeds in CSS.
Where to measure (lab vs field)
Lab data: PageSpeed Insights’ Lighthouse score, Chrome DevTools’ Performance panel, web.dev/measure. Synthetic; runs on a controlled environment; useful for debugging.
Field data: PageSpeed Insights’ ‘Discover what your real users are experiencing’ section, Chrome User Experience Report (CrUX), Search Console’s Core Web Vitals report. Real user data; what Google actually ranks on.
Always optimize for field data. Lab data can show ‘good’ while field data shows ‘poor’ if your tests miss real user conditions (slow mobile networks, low-end devices, geographic distance from your origin).
The diagnostic flow we run on every audit
- Pull current field data from Search Console’s Core Web Vitals report. Note: which URLs are poor/needs-improvement, by which metric.
- Run Lighthouse against the top URLs. Note the specific issues (unoptimized images, render-blocking JS, etc.).
- Open Chrome DevTools Performance panel, record a slow-3G page load. Identify long tasks blocking the main thread.
- Pull the network waterfall. Identify any single request taking over 1s.
- Build a remediation list, prioritized by user-visible impact.
The typical first-pass remediation list
- Replace unoptimized hero images with next/image at the right resolution + format.
- Defer or async every non-critical third-party script.
- Preload web fonts; use font-display: swap with size-adjust to prevent layout shift.
- Add width/height to every image.
- Defer below-fold images via loading="lazy".
- Remove unused JavaScript (often 100-300KB on SMB sites that have accumulated dead code).
What ‘good’ looks like on FH client sites
- LCP: 1.5-2.0s on mobile, 0.8-1.2s on desktop.
- INP: 80-150ms.
- CLS: 0.00-0.05.
- Lighthouse score: 95+ on every page.
When the target is hard to hit
Two cases we hit regularly. Heavy interactive features (video players, chatbots, embedded forms from third parties) drive INP up. Solution: lazy-load them and accept that their loaded state has higher INP than the initial state. Heavy image content (portfolio sites, photography sites) drive LCP up. Solution: aggressive optimization, AVIF format, careful priority management on the hero image only.
The 28-day lag
Search Console field data is a 28-day moving average. A perf improvement you ship today doesn’t fully reflect in CWV scoring for 28 days. We tell clients: expect ranking improvements to compound over 60-90 days post-fix, not immediately. The fix is real; the credit just takes time.
Performance budgets
Set a budget at build time. JS bundle ≤ 200KB. CSS ≤ 60KB. Hero image ≤ 200KB. Total page weight ≤ 1MB. Run a CI check that fails the build if any budget is exceeded. Without a budget, regressions accumulate silently across every PR.
How this lands across FH client work
Every FH client site has a CWV-monitoring routine: weekly Search Console check, monthly Lighthouse audit, quarterly deep performance review. New builds ship with a perf budget enforced in CI. The combined effect is that every FH client site stays in ‘good’ on Core Web Vitals over time — drift doesn’t accumulate. If your site’s CWV is in the ‘poor’ or ‘needs improvement’ bucket and you want to fix it, book a consultation — the remediation engagement is usually a 1-2 sprint project with measurable ranking and conversion impact.
