Google assesses site speed with three Core Web Vitals: LCP (how fast the main element appears, good is within 2.5 s), INP (how quickly the page responds to actions, good is 200 ms or less) and CLS (how much the layout jumps, good is 0.1 or less). You can check your site for free in PageSpeed Insights. The usual culprits are heavy images, fonts, third-party scripts and missing caching.
After this you will be able to
- Name the green- and red-zone thresholds for LCP, INP and CLS and explain what each metric measures
- Tell CrUX field data from a Lighthouse lab run and explain why their numbers differ
- Check your site in PageSpeed Insights and Search Console and work through the eight-point speed-up checklist
Contents
What Core Web Vitals are
“The site is slow” is too vague to act on. That is why Google singled out three metrics that describe how a real person experiences speed: when they saw the main content, whether the page reacted to a tap, and whether a button slid out from under their finger. Together they are called Core Web Vitals — the core quality signals of a web page.
Here is how it looks in practice. A visitor opens a coffee shop page: LCP is the moment the large photo with the menu appears on the first screen. INP is how long they wait after tapping “Book a table” before anything changes on screen. CLS is whether the button slid down just as a banner finished loading above it — and whether they tapped something else by mistake.
LCP — Largest Contentful Paint
- What it measures
- When the largest element on the first screen is rendered: a photo, headline or banner
- Good
- within 2.5 s
- Poor
- over 4 s
INP — Interaction to Next Paint
- What it measures
- How quickly the page responds to taps, clicks and keyboard input
- Good
- 200 ms or less
- Poor
- over 500 ms
CLS — Cumulative Layout Shift
- What it measures
- How much the layout shifts while the page loads and is used
- Good
- 0.1 or less
- Poor
- over 0.25
Field data and lab data: why the numbers differ
Site owners are often surprised when one tool shows green metrics and another shows red. Usually the tools are measuring different things. Field data is what happened for real visitors. Lab data is a single run of the page under artificial conditions.
Field data
- Collected from real Chrome users — the CrUX report
- Reflects experience over the last 28 days
- This is what Core Web Vitals are assessed on
- Only available for pages and sites with enough traffic
Lab data
- A single Lighthouse run under simulated conditions
- Available for any page, even a new one
- Handy for finding causes and checking fixes
- May not match what real visitors experience
How to check your site
Open PageSpeed Insights
It is a free Google service at pagespeed.web.dev. Paste a page address — not just the home page, but also the page that matters most for requests.
Look at the top block first
The Core Web Vitals assessment based on real users is the main result. Check the Mobile and Desktop tabs separately.
Then look at diagnostics
Below comes the Lighthouse lab report with a score and a list of specific issues: heavy images, render-blocking scripts, layout shifts.
Connect Search Console
The Core Web Vitals report groups problem pages across the whole site, not just one.
Re-check after fixes
The lab result updates immediately; the field result updates as data accumulates.
Do not chase a Lighthouse score of 100: it is a lab assessment, not a goal in itself. What matters more is that real visitors, especially on phones, land in the green zone on all three metrics.
Why a site is slow: the main causes
Heavy images: huge JPEGs and PNGs, photos straight from a camera
- Metric affected
- LCP
- What to do
- Compress them, serve WebP or AVIF, provide different sizes for different screens
Images and banners without set dimensions
- Metric affected
- CLS
- What to do
- Set width and height or reserve space for the block
Web fonts: many weights, loaded from a third-party server
- Metric affected
- LCP, CLS
- What to do
- Keep only the weights you need, preload them, configure font-display
Third-party scripts: live chats, widgets, pixels, maps
- Metric affected
- INP, LCP
- What to do
- Remove what you do not need, load the rest after the main content
Heavy JavaScript that runs on every action
- Metric affected
- INP
- What to do
- Break up long tasks, remove unused code
No caching or CDN, slow hosting
- Metric affected
- LCP
- What to do
- Set up browser and server caching, serve files through a CDN closer to the visitor
Hosting deserves a separate mention. Until the server responds, the browser has nothing to show, so a slow or overloaded server adds delay to every other stage. If most visitors are in Kazakhstan but the server is far away and there is no CDN, every request travels a long way — and it shows up in LCP before the images even start loading.
In our experience, on small business sites the main problem is almost always in the first two rows and in third-party scripts: each widget added at some point weighs little, but together they noticeably slow the page down, especially on a phone with mobile internet.
Speed-up checklist
Start with whatever gives the most effect for the least effort: compress the main first-screen image and load it properly, set image dimensions and review third-party widgets. Rewriting code or moving to another host makes sense once the simple measures are done and the metrics are still in the amber or red zone.
- The main image on the first screen is compressed, in a modern format and loaded with high priority
- Images below the first screen load lazily
- All images, videos and ad slots have set dimensions
- No more fonts than needed, and text is visible right away while the font loads
- Third-party scripts are reviewed: unnecessary ones removed, the rest do not block the first screen
- Compression and caching are on, static files are served through a CDN
- No background video on the first phone screen if you can do without it
- Both the mobile and desktop versions are checked, not just one
Speed and SEO: what Google itself says
There are many myths around speed, so we rely on Google Search Central documentation. Google recommends that site owners achieve good Core Web Vitals and states that this, along with other page experience aspects, aligns with what its core ranking systems seek to reward.
Speed up your site for people first: a fast page means fewer abandoned visits and more visitors who read all the way to the “Send a request” button.
Sources
- web.dev: Web Vitals
- web.dev: Largest Contentful Paint (LCP)
- web.dev: Interaction to Next Paint (INP)
- web.dev: Cumulative Layout Shift (CLS)
- web.dev: Interaction to Next Paint becomes a Core Web Vital on March 12
- web.dev: Why lab and field data can be different
- PageSpeed Insights: About
- Chrome UX Report (CrUX)
- Google Search Central: Understanding Core Web Vitals and Google search results
- Google Search Central: Understanding page experience
- web.dev: Optimize LCP
- web.dev: Best practices for fonts
