Core Web Vitals in Plain Words

You're the worst person to test your own website's speed. Your browser has everything cached, your connection is good, and you already know where every button is. A first-time visitor on a mid-range phone and a shaky mobile signal has a very different experience, and that visitor is the one Google tries to describe with Core Web Vitals.

Short answer: Core Web Vitals are three measurements of how a page feels to real visitors. Largest Contentful Paint (LCP) is how quickly the main content appears, and 2.5 seconds or less is good. Interaction to Next Paint (INP) is how quickly the page reacts when someone taps or clicks, and 200 milliseconds or less is good. Cumulative Layout Shift (CLS) is how much the page jumps around while loading, and 0.1 or less is good. Google judges them at the 75th percentile of real visits, separately for mobile and desktop.

What are the three Core Web Vitals, in plain words?

LCP: how long until the page looks ready. The browser identifies the biggest thing in the first screen, usually a hero image, a large heading or a block of text, and measures when it's fully drawn. If your homepage opens with a three-megabyte photo, LCP is the number that suffers.

INP: how long the page takes to respond. You tap "Add to cart" or open the menu. INP measures the delay between that tap and the screen visibly reacting. A page can load fast and still feel dead if the browser is busy running scripts when you touch it. INP replaced an older metric called FID in 2024, and it looks at the slowest interactions across the visit, not only the first one.

CLS: how much stuff moves. You've lived this one. You go to tap a link, an image finishes loading above it, everything slides down and you tap an ad instead. CLS adds up those unexpected shifts into a single score. Lower is better, and zero is perfect.

The thresholds are easy to remember. Good: LCP up to 2.5 seconds, INP up to 200 milliseconds, CLS up to 0.1. Poor: LCP over 4 seconds, INP over 500 milliseconds, CLS over 0.25. Anything in between needs improvement.

Do Core Web Vitals really affect rankings?

Yes, but modestly. They're part of Google's page experience signals, which is one input among many. Google has said that relevance and content quality come first, so a slow page with exactly what the searcher needs can still outrank a fast page that doesn't answer the question.

So why bother? Because rankings aren't the only reason. People leave pages that feel slow, and they abandon forms and carts that jump or freeze. Even if search engines ignored these metrics entirely, they would describe something that costs you inquiries and orders. Treat them as a measure of customer experience that happens to also help SEO. If you're planning a launch, they're part of our pre-launch SEO checklist.

Where can you check your own scores?

Start with PageSpeed Insights. Paste a URL and you'll see two different kinds of data, and mixing them up is the most common source of confusion.

Field data comes from real Chrome users over the previous 28 days. It's what Google actually uses. Lab data comes from a simulated test run once, on a standard device and connection. It's excellent for debugging and unreliable as a verdict, because one run can differ from the next by a wide margin.

Search Console has a Core Web Vitals report that groups your pages by status, which tells you whether you have a sitewide problem or a few bad pages. If your site is new or has little traffic, there may not be enough field data to show anything yet. In that case, rely on lab tests and real device testing until visits build up.

Then test on an actual mid-range phone, on mobile data, with the cache cleared. It takes ten minutes, and it teaches you more than another round of scores.

What usually makes LCP slow?

The causes are rarely mysterious.

A heavy hero image. An oversized photo is the number one offender. Resize it to the dimensions it actually displays at, compress it, and serve a modern format such as WebP or AVIF. Offer smaller versions to smaller screens with responsive image attributes. Don't lazy-load the hero image, because that tells the browser to delay the very thing you want first.

A slow server. If the first byte takes a long time to arrive, nothing after it can be fast. Caching, a sensible hosting plan and efficient database queries all help here.

Render-blocking files. Large CSS and JavaScript files in the page head hold up everything below them. Load only what the page needs.

Content built in the browser. If the page arrives as an empty shell and JavaScript assembles the content afterwards, LCP waits for all of it. Server-rendered pages put the content in the first response. It's one of the reasons we build with server-rendered Laravel templates rather than heavy page builders, a trade-off we cover in Laravel or WordPress.

What usually makes INP poor?

Almost always: too much JavaScript doing too much at once. The browser has one main thread. If it's busy running a tag manager, a chat widget, three trackers and an animation library, your tap waits in line.

Start by listing every third-party script on the page and asking what each one earns. Chat widgets, heat-map tools and old tracking pixels tend to accumulate and nobody removes them. Defer what can wait, delete what's unused, and keep your own click handlers short. If a button triggers heavy work, show visible feedback first, then do the work.

What causes layout shift?

Four things account for most of it.

• Images and videos without width and height set, so the browser doesn't know how much room to reserve.
• Embeds, ads and banners that load late and push content down.
• Web fonts that swap in with a different size than the fallback, reflowing the text.
• Cookie notices or promo bars injected at the top after the page has already rendered.

The fixes are mostly discipline. Always set dimensions on images. Reserve space for anything that loads later. Choose fallback fonts with similar proportions. Place notices as overlays or in space that was reserved from the start.

In what order should you fix things?

Work from the biggest wins down:

• Measure the main page templates (home, a service page, a product or article page), because one fix to a template improves every page that uses it.
• Fix the worst metric on the most visited template first.
• Re-test on a real phone, then wait. Field data covers 28 days, so improvements show up gradually in Search Console.
• Put a speed check on the monthly maintenance list, so a slow script doesn't creep back in. Our website maintenance checklist includes it.

Frequently asked questions

What is a good PageSpeed Insights score?

The overall number is a lab score, and it isn't what Google uses for ranking. Pay attention to whether the field data passes the three Core Web Vitals. A site can score 85 in the lab and pass comfortably, or score 98 and fail in the field.

Do I need all three metrics to be good?

To pass the Core Web Vitals assessment, all three must be in the good range at the 75th percentile. If one fails, the page doesn't pass, so look for the weakest metric first.

Why do my scores change every time I test?

Lab tests depend on the simulated device, your network and what happened to be running at that moment. Small differences are normal. Look for trends across several runs, and trust field data for the real picture.

Speed is built in, not bolted on

Most speed problems are decided in the first week of a project, in the choices about images, scripts and templates. Our web development work is built hand-written and server-rendered for that reason. If your current site feels slow and you'd like an honest read on why, send us the link.