What is Core Web Vitals and why does it matter?

• Largest Contentful Paint (LCP): how long the biggest visible element, usually the hero image or main headline, takes to appear. It's the visitor's sense of "has this page loaded?"
• Interaction to Next Paint (INP): how quickly the page visibly responds when someone taps, clicks or types, measured across the whole visit. It's the difference between a menu that opens instantly and one that hangs.
• Cumulative Layout Shift (CLS): how much content jumps around while the page loads. It's the reason people tap the wrong button when an image or banner pops in late.

INP replaced First Input Delay (FID) as the responsiveness metric in March 2024. FID only measured the delay before the first interaction was handled. INP looks at responsiveness across all interactions, so it's a stricter and more honest test of how a page feels to use.

Google grades each metric at the 75th percentile of real visits, separately for mobile and desktop:

A page passes Core Web Vitals when all three are in the "good" band.

Google uses Core Web Vitals as part of its page experience signals in ranking. Relevance and content quality come first, so good scores won't rescue a thin page. But between comparable pages competing for the same search, a fast, stable page has an edge.

The bigger impact is commercial. Slow LCP means people leave before the offer appears. Poor INP makes forms and menus feel broken. High CLS causes mis-taps on buttons and form fields. All three hit hardest on the pages that make money: service pages, booking forms and checkouts. Fixing Core Web Vitals is as much a revenue job as an SEO one.

Start with field data, then use lab tools to find the cause.

• Field data comes from real Chrome users via the Chrome User Experience Report (CrUX). You'll see it in Search Console's Core Web Vitals report and in the top section of PageSpeed Insights. This is what Google uses.
• Lab data comes from Lighthouse and the lab section of PageSpeed Insights. It simulates one load on one device. Use it to find what's slow, not to judge whether you pass.

Low-traffic sites may not have enough visits for field data. In that case, test key templates in the lab on a throttled mobile profile, and add real-user monitoring if you need ongoing numbers.

LCP:

• Serve the hero image in WebP or AVIF, sized for the screen it's shown on.
• Don't lazy-load the hero image. Mark it as high priority instead. - Cut server response time with caching and a CDN close to your visitors.
• Remove render-blocking CSS and scripts above the fold.

INP:

• Audit third-party scripts: chat widgets, tag managers, heatmaps and ad pixels are frequent offenders.
• Break up long JavaScript tasks and defer anything not needed for the first interaction.
• Avoid heavy page-builder markup that makes every interaction expensive.

CLS:

• Set width and height (or aspect ratio) on every image, video and embed.
• Reserve space for banners, cookie notices and ads before they load.
• Load web fonts so text doesn't reflow badly when the font arrives.

• Chasing a perfect Lighthouse score. A 100 in the lab means little if real mobile users still wait.
• Testing on office Wi-Fi and a new laptop. Your customers are on mid-range phones and mobile data.
• Fixing once, then adding five scripts. One new chat widget or tracking pixel can undo months of work.
• Ignoring INP. Sites that passed under FID often fail INP, because it measures every interaction.
• Treating it as an SEO-only task. The pages that fail are usually your booking and enquiry pages.

A hypothetical example. Say you run a property brokerage whose listing pages show "Poor" LCP and INP on mobile in Search Console. The hero is a 4 MB photo carousel, lazy-loaded. A live chat widget, two analytics tags and a heatmap tool all load on every page. The enquiry form appears late and pushes content down.

The fix list writes itself: serve the first listing photo as a compressed, correctly sized, high-priority image, load the rest of the carousel on interaction, delay the chat widget until the visitor scrolls or after a few seconds, remove the duplicate analytics tag, and reserve space for the form. Then check field data over the following 28 days, since CrUX reports a rolling window and won't move overnight.

We set a performance budget before design starts, so the hero, fonts and scripts are chosen to fit inside it rather than trimmed afterwards. Every key template is tested on a mid-range phone profile before launch, and we check field data after launch once there's enough traffic to report.

We also treat third-party scripts as a decision, not a default. If a chat widget or tracking tool is worth its cost in speed, it stays and gets loaded sensibly. If its job can be done server-side, for example by sending form data straight to your CRM through an automation, it goes.