Technical SEO and Core Web Vitals: site speed and user experience
What LCP, INP and CLS measure, how to read them in PageSpeed Insights and Search Console, common causes of slow sites, and an audit checklist.
- 8 min read
You open a page on your phone and the main content is slow to appear. As you go to tap a button, it suddenly jumps because an image loaded above it, so you tap something else; you tap again and the page only responds after an annoying pause. You will probably close it and go back to the search results. That poor experience can be measured, and Google does measure it, with a set of metrics called Core Web Vitals. In this article we explain the three metrics and their official thresholds, how to read them in Google’s free tools, the most common causes of poor scores and how to fix them, and then offer a short technical audit checklist that works for any site.
What you will learn
- The three metrics – LCP, INP and CLS – and what each means for a visitor.
- The thresholds Google considers good, and how they are measured.
- The difference between lab data and data from real users.
- The most common causes of slowness and their fixes, plus a quick technical audit checklist.
Why does Google care about page experience?
Google’s aim is for the searcher to find a helpful answer quickly and comfortably. If two pages are roughly equal in relevance and quality, the better experience may tip the balance. But note something Google itself stresses: excellent content that fits what people are searching for remains the most important thing, and improving speed alone will not make a page with weak content rank. Good performance, then, is not a substitute for content; it is what lets good content reach the reader without waiting or irritation driving them away. And more important than Google: every second of delay means visitors who leave before reading a word.
The three metrics
1. Largest Contentful Paint – LCP
Largest Contentful Paint measures the time until the largest visible element in the first screen appears – usually the main image or the large heading. It answers the visitor’s question: “Has the page started showing what I came for?”
2. Interaction to Next Paint – INP
Interaction to Next Paint measures how quickly the page responds to a visitor’s interactions throughout their visit, such as clicking a button, opening a menu or typing in a field. It became a Core Web Vital in March 2024, replacing an older metric called FID, which measured only the delay before the first interaction.
3. Cumulative Layout Shift – CLS
Cumulative Layout Shift measures how much page elements move unexpectedly while the page is displayed – for example, an ad or image appearing suddenly and pushing the text down. Its value is not in seconds but a score reflecting the size and distance of the shifts.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | How fast the main content appears | 2.5 seconds or less | Up to 4 seconds | More than 4 seconds |
| INP | How fast the page responds to interaction | 200 milliseconds or less | Up to 500 milliseconds | More than 500 milliseconds |
| CLS | Visual stability of the page | 0.1 or less | Up to 0.25 | More than 0.25 |
Google recommends that a page meets the “good” threshold for at least 75% of real visits, with mobile and desktop measured separately. In other words, what matters is not how the page feels on your fast office computer, but how it feels to most of your visitors on their real devices and networks.
Lab data and real-user data
This difference confuses many people. Lab data comes from a simulated test run once on a virtual device and network; it is excellent for diagnosing problems and trying fixes immediately. Field data is collected from real users’ visits in the Chrome browser over the last 28 days, and it reflects the actual experience. You may get an excellent lab score while the field data is poor, or the reverse, because your real audience may use slower phones or weaker networks than the simulation. Small new sites may not have enough field data yet, and that is normal.
How to measure
- PageSpeed Insights: enter a page’s URL to get its field data, if available, and a lab analysis with suggestions ordered by impact.
- The Core Web Vitals report in Search Console: groups similar pages on your site and shows which are good and which need improvement.
- Chrome’s developer tools: the Lighthouse and Performance panels allow detailed analysis while you work on a fix.
The following video from the Chrome for Developers team explains how to improve these metrics:
The most common causes and their fixes
When LCP is slow
- Huge images: an image thousands of pixels wide shown in a small space. Compress images, use modern formats such as WebP or AVIF, and serve different sizes for different screens.
- Delaying the main image: lazy loading helps for images further down, but it hurts when applied to the first visible image. Load the main image early with high priority.
- A slow server: use page caching and a content delivery network (CDN) close to your audience.
- Render-blocking files: large CSS and JavaScript files that must load before anything appears.
When INP is poor
- Heavy JavaScript: long tasks keep the browser busy so it cannot respond to clicks. Split long tasks and remove unused code.
- Too many plugins and third-party scripts: chat widgets, tracking and ads. Review them, keep only what is essential, and defer what is not needed straight away.
When CLS is high
- Images without set dimensions: set the width and height, or an aspect ratio, so the browser reserves the space in advance.
- Ads and banners that appear suddenly: give them a fixed space, and do not push existing content down.
- Fonts: swapping a font once it loads can change the size of the text. Use suitable font-display settings and load important fonts early.
What if your site runs on WordPress?
Content management systems such as WordPress make building sites much easier, but every plugin you install may add CSS and JavaScript files to every page, even pages that do not need them. Review your plugins regularly, remove what you do not use, choose a lightweight theme, and use a reliable caching plugin. And before any major update or plugin change, try it on a staging copy of the site, then measure the metrics before and after publishing.
A quick technical audit checklist for any site
- All important pages are indexed and listed in the sitemap.
- The site runs on HTTPS, and old versions redirect to new ones permanently.
- Pages are comfortable on a phone: readable text, buttons large enough to tap, and no horizontal scrolling.
- Images are compressed and have dimensions and alt text.
- There are no broken internal links leading to 404 error pages.
- The three metrics are in the good range on mobile first.
Technical improvement complements what you learned in how Google Search works and serves the content you plan in keyword research. After every improvement, measure its effect as we explain in measuring digital marketing. In the digital marketing and SEO course at Badr Academy Education we carry out full technical audits of real sites. For further resources visit the learning library, or try the Find your path tool.
The takeaway
Core Web Vitals measure three things every visitor feels: how fast the content appears, how quickly the page responds, and how stable it is. The good thresholds are LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1. Measure with real data, start with mobile, and fix the big causes first: images, JavaScript and elements that move.
© 2026 Badr Academy Education – this content is exclusive to Badr Academy Education. Short quotations are welcome with the source and a link to this page.
Category: Digital marketing & SEO
Comments (0)
You can comment without an account; your comment appears after review, and the academy may edit it before publishing.
No comments yet – be the first to join in.


Add a comment