Someone sent you a PageSpeed Insights link and you saw red numbers? Don't panic. These metrics tell you in plain language about three things your client feels on their phone: whether the page loaded at all, whether it responds to taps, and whether everything jumps around under their finger. Google recommends that site owners achieve good Core Web Vitals for success in search and to ensure a great user experience generally. This isn't a verdict — it's a map of what to fix first so your site doesn't push away people who already landed on it.
In this article you'll find: Google's exact thresholds without jargon, an explanation of each metric with an example from your industry, a scheme for reading the report in five minutes, and the specific order of fixes. You'll also learn how to talk to your developer so you don't spend money on things that don't make sense.
Three metrics, three customer feelings
What LCP measures and why it matters
Each of the three Core Web Vitals measures something different, but they all answer a simple question: how does the client feel on your site?
LCP (Largest Contentful Paint) — the time after which the largest element on screen becomes visible. For the client this answers: "Does the page work at all?" If you open a dentist's website and the main photo of the clinic takes four seconds to load — the client thinks something is wrong and closes the page. Good LCP is 2.5 seconds or less; the threshold is measured at the 75th percentile of page loads.
What INP measures and why clients get frustrated
INP (Interaction to Next Paint) — the time the page takes to respond to any click, tap, or text entry. For the client this answers: "Does the page listen to me?" When you tap the "Book appointment" button and the page hesitates for half a second before anything happens — that's annoying. Good INP is 200 milliseconds or less; above 500 ms is considered poor.
What CLS measures and why text jumps
CLS (Cumulative Layout Shift) — how much things shift on screen while reading. For the client this answers: "Can I read peacefully?" Imagine reading a service description, then a cookie banner pops up, the text slides down and you lose your place. Pages should have CLS of 0.1 or less, measured at the 75th percentile.
| Metric | What it measures | What the client feels | Good threshold |
|---|---|---|---|
| LCP | Time to load the largest visible element | "Does the page work at all?" | ≤ 2.5 s |
| INP | Response time to any interaction | "Does the page listen to me?" | ≤ 200 ms |
| CLS | Total layout shift while using the page | "Can I read peacefully?" | ≤ 0.1 |
Why 75th percentile, not average
When you see "LCP 3.2 seconds" in the report, you might wonder where that number comes from. Google doesn't calculate the average of all visits. Instead it takes the 75th percentile — what does that mean in practice?
Here's an example on hypothetical numbers — substitute your own. Imagine your site gets 100 visits per month. Load times look like this: 70 people loaded the page in 1.5 seconds, 10 people in 3 seconds, 20 people in 4 seconds. The average would be about 2.15 seconds and would look good (less than 2.5 seconds).
This is the value shown in the report because Google wants to know if the majority of users have good times, not whether a few have phenomenal ones.
Why does this matter for you?
The 75th percentile metric tells you whether at least three-quarters of customers have no reason to complain.
Field data versus lab data in PageSpeed Insights
When you go to pagespeed.web.dev and enter your site address, you see two types of data: field and lab. It's worth knowing the difference and which to focus on.
Field data comes from real users who visited your site in the last 28 days. Chrome measured their LCP, INP and CLS in the background and sent this information to Google. This is data you can really trust, because it shows how the site works in the real world — on different phones, on different networks, at different times of day.
Lab data comes from Lighthouse simulation. PageSpeed Insights runs your site in a controlled environment: on an average smartphone, on an average 4G connection. This is a tool for finding problems, not for judging reality. Lighthouse might show red LCP, but if field data is green — don't panic. The report might also show green values even though users complain — in that case field data is more important.
Why does field data sometimes not exist? If your site has very few visits, Google doesn't have enough data to show reliable values. In that case you have to rely on labs, but treat it as a hint for improvement, not a final verdict.
PageSpeed Insights provides both lab and field data; PSI reports the 75th percentile of metrics.
Rule: make decisions based on field data, find problems in lab data.
How to read PageSpeed Insights report in five minutes
You don't need to understand every line in the report. Five steps are enough:
- 01Address
- →02phone
- →03field
- →04red
- →05diagnostics
- →06developer
Here's the scheme:
Enter address in PageSpeed Insights → open result on phone → read field data at the top → if metric red, scroll to diagnostics → write: "On services page LCP 4.2 s — main image".
The most common causes of poor CLS: images without dimensions, ads/embeds/iframes without dimensions, dynamically injected content. Once you know what's wrong, you can order a fix for that specific thing instead of saying "make the site faster."
Which pages on your business site to measure
You don't need to check every subpage. Measuring four to six key pages is enough to know the health of the entire site:
- Homepage — your business card, most often the first contact.
- Two to three most important services — the ones people call about most often.
- Contact page — when someone has already decided to call, they can't have trouble loading the number.
In Search Console (search.google.com/search-console) there's a Core Web Vitals section that shows which addresses have problems. If ten different service pages have the same problem — it's the template's fault, not a single page. In that case you fix the template and all pages improve at once.
What to fix first — impact and difficulty matrix
Not everything can be fixed at once. Here's the priority order that lets you start with what gives the most for the least effort:
| What to fix | Impact on metric | Difficulty | When to fix |
|---|---|---|---|
| Images without dimensions (width/height) | CLS, LCP | Low | Immediately |
| Heavy graphic banners on mobile | LCP | Low | Immediately |
| Third-party scripts (chat, maps, reviews) | INP | Medium | After images |
| Fonts from external servers | LCP | Medium | After images |
| Plugins that load unnecessary JavaScript | INP | Medium | After chat |
| Server optimization (CDN, compression) | LCP | High | At the end |
The most common causes of poor CLS are images without dimensions, ads, embeds and iframes without dimensions, and dynamically injected content.
What not to do
Before you spend money on "speeding up the site," remember three rules:
Don't chase 100 points in Lighthouse. A score of 100 means the page is perfectly optimized for the test, not for your customers. Achieving 100 often requires giving up important features (maps, forms, galleries). Aim for green field data, not a hundred.
Don't install "speed plugins" without measuring before and after. Most such plugins are ready-made bundles that sometimes work and sometimes break more than they fix. Measure the page before the change, make one change, measure again. Only then do you know if it helped.
Don't remove analytics blindly. Google Analytics, Meta Pixel and other tools are sources of knowledge about what your customers do. Instead of removing them, check if they load asynchronously (don't block page loading). That's usually enough.
Site speed doesn't solve everything
You might have perfect Core Web Vitals, but if the page doesn't have a clear offer — the client still won't call. The page can load in one second, but if it's unclear what you offer, for how much and how to order, no speed will help.
Before spending money on technical optimization, check if your page has: a headline with name and main service, a price list or clear call-to-action button, instructions on how to order. If it doesn't, no speed replaces content. More about why clients don't leave inquiries in Why customers don't leave inquiries. And about how business data affects visibility, read Restaurant data in Google and on portals.
Do it yourself in one evening
You don't need a developer to get started. Here are five steps you can do tonight:
- Go to pagespeed.web.dev and enter your homepage address.
- Do the same for your two most important services and the contact page.
- Write in a table (Excel or paper): page address, LCP, INP, CLS — with green, amber or red color.
- For each red metric, read one line in the "Diagnostics" section — that's the hint of what's wrong.
- Send the developer a message: "On page [address] I have [metric] [value], the result suggests [diagnostics description]. Please quote for fixing this specific element."
Repeat the measurement after making changes. If the developer says something is impossible or expensive — come back to this article, check if it's actually a priority, and decide if it's worth it.
How it looks when a system handles site speed
Manually checking PageSpeed Insights once a quarter is a good start, but it's easy to forget. It's better to turn this into a steady routine: regularly measure key pages in the field (real user data), generate a report with metrics, turn red values into specific tasks, and repeat the measurement after making changes. The result is a change history you can see clearly: it was bad, we did X, now it's better.
When you order a website, from day one you get a mobile-first version, basic SEO setup and analytics. The most common mistake is publishing without measurement — that's why it's worth checking results right after launch. See how it works on the service page.
If you're also interested in conversion optimization, SEO services, UI/UX design or performance measurement — we can do a full audit of your site. More about measuring results in Reporting automation. And about where to start with automation in a small business, read Automation in small business.
Frequently asked questions
Do I need green Core Web Vitals to rank high in Google?
Google takes many factors into account. Good Core Web Vitals is one signal that can help, but alone it doesn't guarantee positions. A page with perfect metrics but no content and no value for the user won't outrank a page with slightly worse metrics but a better answer to the customer's question.
What to do when PageSpeed Insights shows field data but my site has few visits?
If you have fewer than a few hundred visits per month, Google may not have enough data. In that case rely on lab data (Lighthouse) as a hint, but take it with a grain of salt — it tests under artificial conditions. In this situation the best approach is simply to take care of the basics: optimized images, no unnecessary scripts, working HTML code.
Can I fix CLS myself if I don't know HTML?
Often yes. The most common cause of poor CLS is images without dimensions. If you use WordPress or another CMS, in most cases adding width and height attributes to the image in the editor is enough. In builders (Wix, Webflow, GoDaddy) the system usually adds them automatically — check the gallery settings or image options.
How much does fixing Core Web Vitals cost?
It depends on the problem. Adding dimensions to images takes a minute of work — even free if you do it yourself. Optimizing server or rewriting code for high traffic is a larger project. The key is to start with measurement and a specific problem, not with "speed up the site."
Does removing plugins always help?
Not always. Sometimes a plugin is essential (e.g., contact form, Google Maps). Instead of removing, check if there's a lighter alternative or if the plugin has an async loading option. Sometimes one plugin slows the site more than ten others — it's worth measuring which one.
How often should I check Core Web Vitals?
After making changes — within a week to confirm it helped. Then once a quarter is enough, unless you add new features (new galleries, plugins, integrations) — then check after every change.