To improve Core Web Vitals, you fix three things: how fast the main content shows up, how much the page jumps around while it loads, and how quickly it responds when someone taps or clicks. In Google’s language those are LCP, CLS, and INP. Most of the wins come from a short list: optimize your images, reserve space so nothing shifts, cut or defer heavy JavaScript, and put the site on hosting that is not held together with duct tape and optimism.
That is the whole answer. The rest of this post is the plain-English version of each piece, how to measure it, and one honest warning: Core Web Vitals help your users a lot and your rankings a little. It is a floor, not a magic lever.
Let me walk through it the way I would explain it to a business owner who just got a scary red score and a sales email in the same afternoon.
What Core Web Vitals actually measure
Core Web Vitals are three metrics Google uses to describe how a page feels to a real person. Not how it looks in a demo. How it behaves when a customer on a three-year-old phone taps your homepage.
Here is each one in plain English.
Largest Contentful Paint (LCP) measures loading. It is the time until the biggest thing on screen, usually a hero image or a headline, finishes rendering. If your page sits blank for four seconds, that is a bad LCP, and people are already reaching for the back button.
Cumulative Layout Shift (CLS) measures visual stability. It is how much the page jumps around while it loads. You go to tap a button, an ad or an image loads late, everything shoves down, and now you have tapped something you never wanted. CLS is the metric for that specific flavor of rage.
Interaction to Next Paint (INP) measures responsiveness. It is how quickly the page reacts after you tap, click, or type. In March 2024, INP officially replaced First Input Delay (FID) as the responsiveness Core Web Vital. If a marketer is still optimizing for FID, they are optimizing for a metric that retired.
The good thresholds are published by Google, measured at the 75th percentile of your real visitors. Here they are next to the fix that moves each one most.
| Metric | What it measures | Good score | Biggest lever |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading speed | 2.5 seconds or less | Faster server, optimized hero image |
| CLS (Cumulative Layout Shift) | Visual stability | 0.1 or less | Reserve space for images, ads, and fonts |
| INP (Interaction to Next Paint) | Responsiveness | 200 ms or less | Less JavaScript, broken into smaller tasks |
Those numbers come straight from Google’s own Web Vitals documentation. They are not my opinion, and they are not a competitor’s scary infographic. Now let me take them one at a time.
How to improve Largest Contentful Paint
To improve Largest Contentful Paint, you make the biggest visible element show up fast. On most pages that element is an image, so images are where you start.
- Compress and resize. A 4,000-pixel photo squeezed into a 600-pixel slot is bandwidth you are paying for and never using. Export images at the size they actually display.
- Use modern formats. WebP and AVIF are dramatically smaller than old JPEGs and PNGs at the same quality. Most builds can serve them automatically.
- Prioritize the hero. The one image above the fold should load eagerly, not lazily. Tell the browser it matters so it fetches it first.
After images, the second half of LCP is your server. If your host takes a full second to even start sending the page, you have burned half your budget before a single pixel appears. That is time to first byte, and slow hosting is the most common cause I see. We will get to hosting and CDNs in a minute, because they earn their own section.
One caution on lazy loading, since every plugin loves to enable it everywhere. Lazy-load the images below the fold. Never lazy-load the hero. Telling the browser to wait on the exact thing LCP measures is like hiding the finish line from a runner and wondering why the race got slower.
How to fix Cumulative Layout Shift
To fix Cumulative Layout Shift, you stop the page from moving after it starts drawing. The fix is almost always the same idea: reserve the space before the content arrives.
- Give every image width and height. When the browser knows the dimensions in advance, it holds the exact space open, and nothing below it jumps when the image loads. Modern build tools set these for you. Hand-coded
<img>tags often forget. - Reserve room for ads and embeds. Anything that loads late, an ad slot, a map, a video, needs a fixed container. Otherwise it drops in and body-checks everything below it.
- Handle fonts carefully. A custom font swapping in can reflow your text and nudge the layout. Preloading the font and setting a sensible fallback keeps the shift small.
CLS is the most satisfying metric to fix because the change is instantly visible. You reload the page and it just sits still like a well-behaved page should. No drama. No surprise re-taps. It is also the metric that page builders quietly ruin, because they inject widgets and scripts that load whenever they feel like it.
How to improve Interaction to Next Paint
To improve Interaction to Next Paint, you give the browser less work to do at the exact moment the user acts. INP is almost always a JavaScript problem.
Here is the plain version. When someone taps a button, the browser wants to respond right away. But if it is busy running a giant pile of JavaScript, the tap has to wait in line. That wait is your INP. The more scripts you pile on, the longer the line.
So the fixes are about doing less, later:
- Remove JavaScript you do not need. Every tracker, chat widget, popup, and “engagement” tool has a cost. Half of them exist because someone added them in 2019 and nobody dares touch it. Audit the list. Delete the dead weight.
- Defer what can wait. Scripts that are not needed for the first paint should load after the page is interactive, not before.
- Break up long tasks. Big chunks of JavaScript block the main thread. Splitting them into smaller pieces lets the browser handle a tap in between instead of making the user wait for the whole thing to finish.
If your page has forty third-party scripts, no amount of clever coding saves it. That is not a performance problem you optimize. That is a hoarding problem you clean up.
Good hosting and a CDN do more than any plugin
Here is the part people skip because it is not a checkbox in a plugin. The machine serving your website matters. A cheap, overloaded shared server is slow to respond no matter how tidy your images are, and that slow response shows up directly in your LCP.
Two things help more than most on-page tweaks combined:
- Decent hosting. If your time to first byte is high, upgrade the host before you spend a week compressing thumbnails. You cannot optimize your way out of a server that answers the phone slowly.
- A content delivery network (CDN). A CDN stores copies of your site around the world so a visitor in Denver is not waiting on a server in Frankfurt. For most sites this is one of the biggest single wins available, and it is not expensive.
This is also where good technical foundations pay off. Core Web Vitals optimization is far easier on a site that was built clean in the first place, which is exactly the thinking behind SEO-friendly website design. Fast is cheaper to keep than fast is to bolt on later.
How to measure Core Web Vitals without guessing
You cannot pass Core Web Vitals if you do not know where you are failing them. There are two kinds of data, and confusing them is the number one reason people “fix” a page and see nothing change.
Lab data is a single test run in a controlled environment. Field data is what real visitors actually experienced over the last 28 days. Google ranks on the field data. Your fancy lab score is a diagnostic, not the scoreboard.
Three tools cover almost everyone:
- PageSpeed Insights (pagespeed.web.dev). Paste in a URL and it shows both lab and field data, plus specific opportunities. Read the field data section first. It is the one Google counts.
- Google Search Console. The Core Web Vitals report groups your whole site into good, needs improvement, and poor, using real user data. This is the honest, site-wide view. Start here before you touch anything. Guessing is not a strategy, and Search Console is free.
- Chrome DevTools. For developers, the Performance panel shows exactly which script or image is causing the problem, down to the millisecond.
The reason lab and field data disagree so often: your test ran on fast office wifi, and your customers are on phones in a parking lot. The parking lot is the one Google cares about. Checking your vitals is also a natural part of any real website audit, not a separate ritual you do once and forget.
A fast page builder is usually a contradiction
Here is my one strong opinion for this post, and I will back it up.
Most drag-and-drop builders make Core Web Vitals harder than they need to be. Wix, Squarespace, and the average WordPress theme stacked with plugins tend to ship bloated, script-heavy pages, because the thing that makes them easy to launch is the same thing that makes them slow. Every widget you drop in drags a little JavaScript and a little layout shift along with it. You did not write that code. You cannot easily remove it. And it shows up in your INP and CLS whether you like it or not.
I have a computer science background, so I build in real frameworks that produce clean, static, fast pages instead of page-builder soup. That is not me being fussy. Pretty is not the same as fast, and Google keeps score on the second one. If your builder makes it impossible to control what loads and when, you have hit the ceiling of what optimization can do, and the honest fix is a better foundation, which is most of what our web design work is about.
If you are on a builder and not ready to move, you can still win the easy points: compress images, cut the plugins you do not use, and reserve space for anything that loads late. Just know that some of the ceiling is built into the tool.
Speed helps users a lot and rankings a little
Now the honest framing, because I am not going to sell you a fairy tale with a dashboard attached.
Core Web Vitals are a real Google ranking signal. They are part of the page experience signals Google has documented for years. But they are a tiebreaker, not a catapult. Google has said plainly that relevance wins. A faster page will not outrank a genuinely more useful one just because it loads quicker. If two pages are equally helpful, the faster one has an edge. That is the size of the lever.
So where is the real payoff? Users. A fast, stable page keeps people from bouncing, makes them more likely to read and buy, and does not make them tap a button that just teleported. That is worth doing on its own, before you ever think about rankings. This is also why Core Web Vitals lean heavily on the mobile version of your site, which ties directly into mobile-first indexing: Google evaluates the phone experience, so that is the one to fix first.
Think of it the way I explain most technical work. Passing Core Web Vitals does not guarantee you rank. It removes a reason not to. It is one piece of the larger technical SEO basics that decide whether Google can even understand and reward your page. Fast, stable, and responsive is the price of admission, not the prize.
Frequently asked questions
What is a good Core Web Vitals score?
A page passes when it hits the good threshold on all three metrics for at least 75 percent of real visitors: Largest Contentful Paint of 2.5 seconds or less, Cumulative Layout Shift of 0.1 or less, and Interaction to Next Paint of 200 milliseconds or less. Miss any one and the page counts as not passing, so treat all three as a set.
Do Core Web Vitals affect Google rankings?
Yes, but modestly. They are part of Google’s page experience signals and act as a tiebreaker between pages of similar relevance and quality. A faster page will not outrank a genuinely more useful one on speed alone. The bigger reason to fix them is that they directly improve the experience for the people already on your site.
What replaced FID in Core Web Vitals?
Interaction to Next Paint (INP) replaced First Input Delay (FID) in March 2024. INP is a more complete measure of responsiveness because it looks at all interactions on the page, not just the first one. If a tool or a marketer is still reporting FID, their information is out of date.
How do I check my Core Web Vitals?
Start with the Core Web Vitals report in Google Search Console for a site-wide view based on real user data. For a single page, use PageSpeed Insights and read the field data section, since that is what Google actually uses to rank. Developers can use the Chrome DevTools Performance panel to find the exact cause.
Why is my PageSpeed score different every time I run it?
Because a single test is lab data, run once in a controlled setting, and it varies with conditions. Google ranks on field data, which is the average experience of your real visitors over the past 28 days. Do not chase the lab number up and down. Watch the field data, which changes slowly as real fixes reach real users.
How long until Core Web Vitals improvements show up?
The field data in Search Console is a rolling 28-day window, so even a perfect fix takes weeks to fully reflect. You will see lab scores change immediately, but the number Google uses updates gradually. Make the fix, confirm it in the lab, then give the field data time to catch up.
What is the single biggest thing I can do to improve Core Web Vitals?
For most small business sites, it is a tie between decent hosting and controlling your images and scripts. A slow server sinks LCP no matter what else you do, and a pile of unused plugins wrecks INP and CLS. Fix the server, compress the images, and delete the scripts you do not use, and you have handled the majority of the problem.
Start with a look at where you actually stand
Core Web Vitals get talked about like a dark art, but they come down to three plain questions. Does the main content show up fast, does the page hold still, and does it respond when someone taps. Fix those, on hosting that keeps up, and you are most of the way there.
The fastest way to know what is dragging your scores down is to look. Run a free audit for a read on your speed, stability, and technical health today, or see how we handle the ongoing work as part of organic SEO. Fix the foundation first. Then worry about making it fancy.