Key takeaways
- Core Web Vitals are three Google metrics: loading (LCP), responsiveness (INP) and visual stability (CLS).
- A good INP is 200 milliseconds or less, measured at the 75th percentile of real visits, on mobile and desktop separately.
- INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024.
- On small business sites the usual causes are heavy themes, chat widgets, pop-ups and too many tracking tags.
- Speed helps, but it does not rescue a site Google cannot crawl or pages that do not answer the search. Fix those first.
What are Core Web Vitals?
Core Web Vitals are three measurements Google uses to judge the experience of a page: how fast the main content appears (LCP), how quickly the page reacts when someone taps or clicks (INP), and how much the layout jumps while it loads (CLS). They come from real visitors using Chrome, not from a lab test.
The official definitions live on web.dev's Web Vitals page. For each metric there is a "good" line, and Google checks it at the 75th percentile of page loads. In practice, that means at least three out of four visits must reach the good line, not just your visit on a fast office connection.
| Metric | What it measures | Good | What a visitor feels |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading of the main content | 2.5 seconds or less | "The page is here." |
| INP (Interaction to Next Paint) | Responsiveness to taps, clicks and keys | 200 milliseconds or less | "The button reacts when I press it." |
| CLS (Cumulative Layout Shift) | Visual stability while loading | 0.1 or less | "The text did not jump while I was reading." |
What is INP, in plain words?
INP measures how long your page takes to show a visible reaction after someone interacts with it: opening a menu, tapping Call, choosing a size or submitting a form. It looks at interactions across the whole visit. If the screen freezes for a moment after a tap, visitors feel it, and INP records it.
According to web.dev's INP guide, an INP at or below 200 milliseconds means good responsiveness, between 200 and 500 milliseconds needs improvement, and above 500 milliseconds is poor. The same guide explains where the delay comes from: long tasks that keep the browser busy before it can respond, the time your own code takes to handle the click, and the time the browser needs to draw the next frame.
Picture a customer on a phone who taps "Book now" and nothing happens, so they tap again, and then the form opens twice. That is a responsiveness problem, and it costs leads even when the page looked fast when it loaded.
What happened to FID?
First Input Delay (FID) was the old responsiveness metric. It only measured the delay before the browser started handling the first interaction. Google replaced it with INP as a Core Web Vital on March 12, 2024, because INP reflects every interaction and the full wait until the screen updates.
The change was announced on web.dev: Interaction to Next Paint is officially a Core Web Vital. If an old report or plugin still talks about FID, it is out of date. Many sites that passed FID easily now fail INP, because INP also counts the work that happens after the first click.
Do Core Web Vitals affect Google rankings?
Yes, as part of page experience, but they are not the whole story. Google says good Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward. In my experience a fast page with weak content still loses to a slower page that answers the search better.
Google's own page, Understanding Core Web Vitals and Google search results, recommends reaching good scores both for success in Search and for a better user experience. I read it this way: speed is a tiebreaker in search and a real factor in conversions. A page that reacts instantly keeps more of the visitors you already paid to attract.
What usually slows down a small business website?
On small business sites the problems are rarely exotic. The usual suspects are a heavy theme or page builder, huge images, chat and booking widgets, pop-ups, sliders and a tag manager loaded with old tracking tags. Each adds scripts that compete for the browser's attention right when the visitor is trying to tap something.
Heavy themes and builders
Multipurpose themes load code for features you never use, on every page.
Chat and booking widgets
Third-party scripts that start working the moment the page opens, even if nobody chats.
Too many tracking tags
Old pixels and tests that stay in the tag manager long after the campaign ended.
Oversized images
Photos straight from the camera slow the main content and hurt LCP.
Pop-ups and sliders
Big scripts, and often layout jumps that hurt CLS.
Fonts and embeds without space reserved
Maps, videos and web fonts that push content down as they arrive.
A real example: on a medical clinic site I worked on, the images alone weighed 5.85 MB. After compressing and resizing them, they came down to about 0.56 MB, with no visible loss of quality. That was one of ten fixes in the clinic technical SEO case study, and the cheapest one to make.
How can you check your own Core Web Vitals?
Open Google Search Console and look at the Core Web Vitals report: it groups your URLs into good, needs improvement and poor, using real visitor data. Then test one page from each group in PageSpeed Insights to see which metric fails and why. Start with mobile, where most local customers browse.
- Search Console, Core Web Vitals report: which groups of pages fail, on mobile and on desktop.
- PageSpeed Insights on your top landing pages: home, main service pages, top products.
- Look at the field data first (real users). The lab score is only a diagnosis tool.
- Write down the failing metric per template, not per URL. One theme fix usually solves hundreds of pages.
- Test again 28 days after a fix, since field data looks back over recent weeks of visits.
What should you ask your developer?
Ask specific questions tied to the failing metric, not “make the site faster”. Which scripts run on every page and who still needs them? Can chat and review widgets load only after a click? Are images resized and served in modern formats? Which interaction is slowest in INP, and what code runs on it?
- Give me a list of every third-party script and tag, with the owner and the purpose of each.
- Can the chat widget load when the visitor clicks the chat button instead of on page load?
- Which interaction has the worst INP, and what code runs when it happens?
- Are images resized to the size they are shown, compressed and lazy-loaded below the fold?
- Do embeds, banners and fonts have space reserved so the layout does not jump?
- What will we remove, not just optimize? Deleting unused code is the fastest win.
If the answer to most of these is "the theme does it", the theme is the problem. That does not automatically mean you need a new site. Read do I need a new website for SEO? before you decide.
Where speed fits in an SEO plan
I work in this order: first make sure Google can crawl and index the pages that sell, then make sure each page answers its search, then fix speed on the templates that bring traffic and leads. The full sequence is in my technical SEO checklist, and it is how I run every technical SEO project. If you are planning a redesign, set Core Web Vitals targets in the brief, as explained in website redesign without losing SEO.
My overall approach is on the SEO consultant home page. If you want someone to look at your numbers, a technical SEO audit starts at $450 (see pricing), and the first 30-minute diagnosis is free through the contact page.
Frequently asked questions
Is a PageSpeed score of 100 required?
No. The lab score is a diagnosis tool. What matters is the field data from real visitors reaching the good thresholds for LCP, INP and CLS.
Does INP matter for a site with few buttons?
Yes. Menus, accordions, phone links and forms are all interactions. A small site with a heavy theme can still have poor INP.
Why does my site pass on desktop but fail on mobile?
Phones have less processing power and slower connections, so the same scripts take longer. Google reports mobile and desktop separately.
Will a caching plugin fix INP?
Usually not. Caching speeds up loading, but INP depends on the code that runs when someone taps. That needs less or lighter JavaScript.
How long until Search Console shows the improvement?
Field data looks back over recent weeks of real visits, so expect several weeks before the report reflects a fix.
