A slow site loses sales quietly. Nobody complains: people just go back to the search results, close the tab, or give up halfway through checkout. Your media report shows the paid click, but not who left before the page even appeared.
This guide is for anyone who needs to decide what to fix on the site, in what order of priority, and how to tell whether it worked. It's useful for the people who run the site and for the people who hire them. The technical chapters explain just enough for you to talk with your developer and hold them to the right result.
Chapter 1What Core Web Vitals are
They're three measures Google uses to evaluate the experience of the people who visit a page. Each one answers a simple question:
| Metric | Question | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long does it take for the main content to appear? | Up to 2.5 s | Up to 4 s | Over 4 s |
| INP (Interaction to Next Paint) | Does the page respond quickly when I tap or click? | Up to 200 ms | Up to 500 ms | Over 500 ms |
| CLS (Cumulative Layout Shift) | Do things stay put while the page loads? | Up to 0.1 | Up to 0.25 | Over 0.25 |
Two details change how you should read these numbers:
- The 75th percentile is what counts. A page passes when at least 75% of visits fall within the "good" threshold. It doesn't help that the page loads fast on your computer if a quarter of your visitors have a poor experience.
- Mobile and desktop are evaluated separately. On most sites, mobile is where the problem is, and also where most of the traffic comes from.
In 2024, INP replaced the old interactivity metric (FID). If you still see reports that talk about FID, they're out of date.
Why your business should care
Core Web Vitals are part of the page experience signals Google takes into account, but they don't outrank relevance: great content on a slow page can still rank well. The stronger reason to care about them is a different one: speed and stability directly affect your conversion rate and the cost of your paid media, because every paid click that gives up before seeing the page is wasted budget.
Want to estimate what slowness is costing you? Manáry has a free tool for that: the cost of a slow website.
How to measure it the right way
There are two types of data, and mixing them up is behind a lot of bad decisions.
| Field data | Lab data | |
|---|---|---|
| What it is | Measurements from real visitors, on real devices and connections | A simulated test, under controlled conditions |
| Where to find it | Search Console, PageSpeed Insights (top section), the CrUX report, your own measurement in GA4 | Lighthouse, PageSpeed Insights (bottom section), Chrome DevTools |
| What it's for | Finding out whether the problem exists and whether the fix worked | Finding the cause and testing a fix before you publish it |
| Watch out | It takes about 28 days to reflect a change | It varies from one test to the next; it's not what Google uses to evaluate your site |
The tools, in the order you'll use them
Search Console's Core Web Vitals report
It shows groups of pages with problems, split into mobile and desktop. It's the big-picture map: it tells you which page templates (product, article, landing page) need attention.
PageSpeed Insights
For a specific page, it shows field data at the top (when there's enough traffic) and, below that, a lab test with opportunities for improvement.
Chrome DevTools
In the Performance panel, it shows which element is the LCP, which long tasks block interactions, and what moves around on the screen. It's where your developer finds the cause.
Your own measurement (optional, but recommended)
Google's web-vitals library can send LCP, INP, and CLS from every visit to GA4. That way you see the numbers by page, by device, and by campaign, without waiting for the public report.
What to ignore
A lot of time and money gets lost chasing the wrong number. These are the ones we recommend putting on the back burner:
- The 0 to 100 Lighthouse score as a goal. It's a summary of a lab test. It helps with diagnosis, but a site can score 70 and pass every Core Web Vital in the field, or score 95 and fail on real phones.
- Testing only on desktop. The connection and processor of a work laptop hide the problems your customers run into on an average phone.
- A single test. Lab results vary. Run the test three to five times and look at the median.
- Pages with no traffic. Fixing a page that gets ten visits a month won't change your business. Start with the pages that receive paid media and the pages that sell.
- Scores from other tools (letters, grades, proprietary scores). They're useful for comparing before and after, but they're not what Google evaluates.
The goal isn't a score of 100. The goal is for three out of four real visits, on mobile, to have a good experience on the pages that sell.
Chapter 4What order to fix things in
The right order saves weeks of work. This is the one we follow on Manáry projects:
List the pages that sell
Paid media landing pages, product and service pages, cart and checkout, forms. Cross-check them against your GA4 traffic and keep the ones that get the most visits.
Look at mobile first
On most sites, that's where the worst numbers and most of the audience are.
Fix the template, not the page
If all your product pages have the same problem, the cause is in the template. One fix solves hundreds of pages.
Start with LCP
It's the metric most closely tied to first impressions and to people leaving. Fixes usually take effect quickly.
Then CLS
It almost always has simple causes (images without dimensions, banners that push content down) and cheap fixes.
INP last
It takes more investigation, because it depends on the site's JavaScript and on third-party tools. It's also where the gains are hardest for competitors to copy.
Fixing LCP
LCP measures when the largest visible element appears, which is almost always the main image or the headline at the top. Its time breaks down into four parts, and each one calls for a different kind of fix:
| Part of the time | What happens | Typical fix |
|---|---|---|
| Server response | The browser waits for the server to start sending the page | Page caching, better hosting, a CDN |
| Delay before the download starts | The browser is slow to discover the main image | Image in the HTML, preloading, and high priority |
| Resource download | The image is heavy | WebP or AVIF, the right size for each screen |
| Render delay | CSS, JavaScript, or fonts hold up rendering | Less render-blocking CSS and JS, optimized fonts |
Never defer loading the main image
Lazy loading is great for images in the middle and at the bottom of the page, but applied to the top image it delays the very thing LCP measures. The main image should load immediately and with high priority (the fetchpriority="high" attribute).
Use the right format and size
WebP or AVIF files are usually a fraction of the weight of an equivalent JPEG or PNG. And the image should be the size it's displayed at: a 4,000-pixel photo shown on a 400-pixel phone screen is waste. The srcset attribute delivers the right version for each screen.
Avoid carousels and heavy video at the top
Carousels load several images and scripts before showing the first one. Background videos are very heavy on mobile. A well-chosen image converts just as well or better, and loads much faster.
Turn on page caching and a CDN
A page served ready-made from the cache, by a server close to the visitor, starts arriving in a fraction of the time it takes for a page that's built on every visit.
Take care of your fonts
Use only a few families and weights, host your fonts on your own site when possible, preload the main one, and use font-display: swap so the text shows up even before the font arrives.
Fixing INP
INP measures the time between a tap or click and the next screen update. When it's poor, people tap a button and nothing happens for a moment, so they tap again, or give up. The cause is almost always too much JavaScript running at the same time.
Cut and defer third-party scripts
Chat widgets, heatmaps, pixels from several platforms, review widgets. Each one seems light on its own; together, they tie up the phone's processor. Review your Tag Manager, remove what nobody uses, and load the rest after the first interaction or only on the pages that need it.
Break up long tasks
Any JavaScript task longer than 50 milliseconds locks up the page. Your developer can split the work into smaller chunks and hand control back to the browser between them, so the response to the tap comes first.
Give immediate visual feedback
When someone clicks a button that triggers something slow (submitting a form, filtering products), show a loading state right away. The screen changes quickly, and the heavy work happens right after.
Reduce the size of the page
Pages with thousands of elements (common with visual page builders and huge menus) make every screen update slower. Simplifying the structure improves INP and LCP at the same time.
Is your site losing sales because it's slow?
Manáry audits the Core Web Vitals of the pages that sell and delivers the fixes in order of impact.
Fixing CLS
CLS measures how much the content jumps around while the page loads. It's that moment when you're about to tap a link and the text drops down because a banner appeared above it. Besides being annoying, it causes misclicks, including on buy buttons.
- Give images, videos, and iframes dimensions. With width and height (or an aspect ratio) set, the browser reserves the space before the media arrives.
- Reserve space for what loads later. Banners, notices, ads, and widgets that load later should have a reserved area, or appear on top of the content without pushing it.
- Cookie banners that float instead of push. A notice that drops in at the top and pushes the page down is one of the most common causes of poor CLS.
- Fonts with similar metrics. When the site's font arrives and replaces the fallback font, the text can change size. Adjusting the fallback font so its metrics are similar prevents the jump.
- Animations with transform. Animating position and size with transform doesn't push neighboring elements around.
Bonus chapter: WordPress
A large share of business websites run on WordPress. The platform can be very fast, but a few common habits slow it down.
| Habit | Effect | What to do |
|---|---|---|
| A plugin for everything | Dozens of scripts and stylesheets on every page | Review your plugin list and remove the ones that aren't essential |
| Images uploaded as they came | High LCP and heavy pages | An optimization plugin that converts images to WebP or AVIF |
| No page caching | The server builds the page on every visit | Page caching and, if possible, server-level caching from your host |
| The cheapest hosting available | Slow server response on every visit | Hosting with up-to-date PHP and resources that match your traffic |
| A visual builder with a heavy structure | Lots of elements and CSS on every page | Lean sections, reusable components, nothing hidden that loads without being shown |
| Optimization on autopilot | Features that break the site or make one metric worse to improve another | Turn on one option at a time and measure before and after |
Be careful with the "delay all JavaScript" options in caching plugins. They can improve the lab test while delaying the response to the first clicks. Measure field INP after you turn them on.
A four-week fix plan
Week 1: diagnosis
Search Console and PageSpeed Insights on the pages that sell, on mobile. List the failing metric for each page template and the likely cause.
Week 2: LCP fixes
Main image, caching, fonts. Publish, and confirm in the lab that the change had an effect.
Week 3: CLS and cleanup
Media dimensions, banners, plugins, and third-party scripts you can do without.
Week 4: INP and monitoring
Long tasks and heavy scripts on the pages with the most interaction. Turn on field measurement and schedule a Search Console review for four weeks later.
Frequently asked questions
I fixed the site, but Search Console still shows a problem. Why?
Field data covers the last four weeks of visits, so the improvement shows up gradually. Use lab data to confirm the fix, and wait for the report cycle to catch up.
The page has no field data in PageSpeed Insights. Now what?
Pages with little traffic don't show up in the public report. Use the data for the whole domain, the lab test, and ideally your own measurement with the web-vitals library.
Will switching platforms fix it?
It's rarely necessary. In most cases, images, caching, third-party scripts, and page structure can be fixed on your current platform, at a much lower cost.
Do good Core Web Vitals guarantee the top spot on Google?
No. They're one of the page experience signals, and content relevance still carries more weight. The surest gain is in conversion: more people see the page, interact with it, and buy.
Want a site that's actually fast?
Manáry builds and optimizes websites with Core Web Vitals targets written into the contract, measured with real data.
Keep reading
Unlock the full material with a quick sign-up. It works for every Manáry resource.
It takes less than a minute. No email sequence you did not ask for.Want us to apply this to your business?
This material is what Manáry does every day with clients. If it makes sense, a specialist looks at your numbers and hands back the priorities, with no sales pitch.
Unlock the full read
Five quick fields and you read it right now, on the page. One sign-up unlocks every Manáry resource.