What is a good Largest Contentful Paint score?

A good LCP is 2.5 seconds or faster, measured from when a visitor requests the page to when the biggest visible element finishes loading. Between 2.5 and 4 seconds counts as needs improvement, and anything past 4 seconds counts as poor. Mobile connections usually run slower than the desktop you tested on, so check the phone score separately.

Does Core Web Vitals actually affect Google rankings?

Yes, but as one signal among many, not the deciding one. Google's Search Central documentation groups it under page experience, alongside mobile-friendliness and HTTPS, and says strong content on a slow page can still outrank thin content on a fast one. A poor score will not sink a good page, but it removes an advantage a competitor with a faster page already has.

Why does my page feel fast to me but slow to a phone visitor?

Your own computer is usually faster than an average visitor's phone, and your office internet connection is usually faster than mobile data. Google's field data comes from real Chrome users on their own devices and networks, which is why a site can look instant in your browser and still fail its phone score for actual visitors.

What is Interaction to Next Paint and why did it replace FID?

Interaction to Next Paint, or INP, measures how long the page takes to visibly respond after any tap or click during the whole visit, not just the first one. It replaced First Input Delay as the official metric because FID only measured the first interaction and ignored a page that stayed slow to respond after that, which INP now catches.

Can caching alone fix a bad speed score?

Caching helps returning visitors, but it does nothing for the large share of visitors arriving for the first time, since there is nothing cached yet to serve them. A first-time visitor's speed depends on image size, font loading, and how much script runs before the page settles, so caching is one fix among several rather than a complete one.

What Do Core Web Vitals Mean for Your Slow Website?

Core Web Vitals are Google's three speed scores for real visitors: how fast content appears, layout stability, and how fast the page responds to taps.

In short

Core Web Vitals are three scores Google uses to judge how a page feels to a real visitor: how fast the main content appears (LCP), how much the layout jumps while loading (CLS), and how fast the page responds to a tap (INP). A slow score does not just cost search ranking — it is often the real reason a visitor leaves before reading a word. SiteHealth checks your Core Web Vitals on phone and desktop every hour and reports which one is failing, and why, in plain sentences.

What is a Core Web Vital, really?

A Core Web Vital is one of three specific measurements Google runs against your page from real visitor data, not a lab test on one machine. Each one maps to a different kind of frustration, and each has its own pass/fail line:

LCP (Largest Contentful Paint) — how long the biggest visible thing on the screen, usually a hero image or headline, takes to finish loading.
CLS (Cumulative Layout Shift) — how much content jumps around after it first appears, as images, ads, or fonts arrive late and shove things out of the way.
INP (Interaction to Next Paint) — how long the page takes to visibly react after someone taps a button, opens a menu, or fills in a form field.

Google pulls these numbers from the Chrome browsers of people who actually visited your site, so the score reflects real phones on real networks, not a best-case test in an empty browser tab.

Why does my Largest Contentful Paint stay slow?

LCP stays slow when the biggest thing on the page has to wait behind other work before it can even start loading. The most common causes are an oversized hero image that was never compressed, a web font that blocks text from showing until it downloads, and JavaScript that runs before the browser gets to the image at all. A good LCP is 2.5 seconds or faster; past 4 seconds counts as poor. On a hero image alone, the difference between a 200 KB compressed file and a 2 MB original can be the entire gap between those two numbers.

How do you bring LCP down?

Compress and correctly size the hero image so the browser is not downloading a file larger than it will ever display.
Load the main heading font with font-display: swap or a system font, so text shows immediately instead of waiting on a font file.
Move non-essential scripts (chat widgets, tracking pixels, carousels) to load after the main content, not before it.
Turn on server or CDN caching so the page itself does not have to be rebuilt from scratch on every visit.

Why does the page jump around while it loads?

CLS happens when something loads in after the layout has already settled and shoves the content that was already there. The two most common causes are an image with no width or height set, so the page reflows once the image's real size is known, and an ad or embed that inserts itself into the page after the fact. A good CLS score is 0.1 or lower; anything past 0.25 counts as poor. The fix is almost always the same: reserve the space before the content arrives, instead of letting it push everything down once it shows up.

What does a slow tap response feel like?

INP is the gap between when someone taps something and when the page visibly reacts, and it is measured across every interaction during the visit, not just the first one. A slow INP feels like a button that needs a second tap because the first one did not seem to register, or a form field that lags a beat behind typing. A good INP is 200 milliseconds or under. INP replaced an older metric called First Input Delay as Google's official Core Web Vital specifically because FID only checked the first interaction and stayed blind to a page that got sluggish later in the visit.

What counts as a good phone score?

Google reports Core Web Vitals separately for phones and desktop, and the phone number is usually the one that matters, since most visitors to a small-business site arrive on mobile data rather than office wifi. A page that passes all three thresholds on desktop can still fail on phone, because mobile processors are slower and mobile networks add real latency to every file the page requests. If you only check one score, check the phone one — a fast desktop test tells you almost nothing about what most of your visitors actually experience. A site built with an AI tool like Lovable, Bolt, or v0 is especially prone to this gap, since preview builds are often tested once on a fast office connection and never checked again on an actual phone.

Do caching and compression matter as much as the code?

Caching and compression matter, but they solve a different half of the problem than code does. Caching means a returning visitor's browser reuses files it already downloaded instead of fetching them again; compression means the files themselves are smaller to begin with. Neither one helps the large share of visitors who are arriving for the first time with nothing cached — for them, the size of your images and the amount of script running before the page settles still decide the outcome. Checking Core Web Vitals by hand means running a tool, reading a report meant for developers, and remembering to do it again after every content update, which is where it tends to quietly stop happening. SiteHealth runs the phone-and-desktop speed check along with the caching and compression check every hour and reports a plain-English change the moment a new hero image or plugin drags the score back down. See the full list of checks on Features.

Is this worth fixing if you are not technical?

The honest objection is that Core Web Vitals sounds like a developer's problem, and some of it is — moving a script, reserving image dimensions, and swapping a font-loading setting are code changes. But you do not need to make the fix yourself to know it needs making. Knowing which of the three scores is failing, on which page, and why turns a vague "the site feels slow" into a specific instruction you can hand to a developer or your web host: "the hero image on the homepage is 2.1 MB, please compress it." That single sentence gets fixed a lot faster than a general complaint, and as covered when looking at what uptime monitoring misses, a site that loads does not mean a site that works well for the person waiting on it. Nobody files a support ticket over a page that took three extra seconds — they just leave, and you never see the reason in any log.

What should you check first?

Run the free check at SiteHealth on your own homepage and note the phone speed score first, since that is what most visitors actually see.
Open the largest image on the page in any image tool and check its file size — anything over 300 KB on a hero image is worth compressing.
Look for a font-loading setting in your site builder or theme and confirm it is not blocking text from showing while the font downloads.

That is the whole first pass: one free check, one image size, one font setting. Nothing on that list requires paying for anything or waiting on a developer to get started.