Google measures website speed with three numbers called Core Web Vitals: how fast the main content appears, how fast the page responds to a tap, and how stable the content stays as you read. Each number describes a different problem with a different fix, so ask "slow at what?" before you buy pricier hosting or order a rebuild.
This article gives you the official limits, the steps for measuring in PageSpeed Insights, and a table that shows what to fix first. You need half an hour and your site's URL.
The three numbers and their official limits
A good page meets all three together. These are the limits Google publishes on web.dev, as of our check in November 2026:
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | When the largest element on screen appears, often an image or headline | 2.5 seconds or less | Up to 4 seconds | Over 4 seconds |
| INP | How fast the page responds after a click or tap | 200 milliseconds or less | Up to 500 milliseconds | Over 500 milliseconds |
| CLS | How much content moves while you read | 0.1 or less | Up to 0.25 | Over 0.25 |
Google reads each metric at the 75th percentile of page loads, with phones and computers separated. Put simply, three quarters of your visitors should get this result or better, because an average can hide a poor experience for many of them.
How to measure in PageSpeed Insights
Follow this order, so you don't start with the least telling number:
- Pick your pages: the home page, your most visited service page, and any page your ads point to. Each template has its own issues, so don't stop at the home page.
- Open PageSpeed Insights, paste the URL and read the mobile result first.
- Read real-user data before the score: it comes from actual visits over the last 28 days, through the Chrome User Experience Report (CrUX).
- Record LCP, INP and CLS for each page in a simple table, with the date.
- Then move to lab data: a simulated load that's useful for diagnosing causes, though it may miss what your visitors really experience.
- Measure again after each fix: lab data changes right away, while real-user data shifts gradually because it covers 28 days.
If a page has no real-user data, the tool shows whole-site data when it's available. A low-traffic site may have none at all, and then lab data serves as a temporary guide.
The score out of 100 breaks down as poor from 0 to 49, needs improvement from 50 to 89, and good from 90 to 100. It's a lab score, and Google notes that it can vary between runs and that a good score doesn't guarantee a good experience for your visitors.
For the wider view, open the Core Web Vitals report in Search Console. It groups similar pages and gives each group the status of its worst metric, so one poor metric is enough to mark a group as poor.
The fix-order table
Start with the metric rated poor on your busiest pages, then use this table. The actions come from Google's guidance on improving LCP, CLS and INP. The order among them is our own practical judgment.
| What you see | Likely cause | Start here |
|---|---|---|
| High LCP, largest element is an image | A heavy image, or one that loads late | Shrink it, use WebP or AVIF, remove lazy loading from it, and add fetchpriority="high" |
| High LCP, slow first server response | The server, redirects or missing caching | Remove needless redirects, turn on caching, and use a content delivery network (CDN) |
| High LCP, largest element is text | Fonts or CSS holding up rendering | Reduce CSS and font files, and use a font-display value other than auto or block |
| High CLS as images appear | Images without set dimensions | Set width and height on every image and video |
| High CLS from a late bar or ad | Content entering without reserved space | Reserve its space in advance, or lay it over the content |
| High CLS when the font loads | Fallback font sized differently from the final font | Choose a close fallback, and preload the critical fonts |
| High INP | Long JavaScript tasks keeping the browser busy | Remove what you don't need, then split long tasks |
Three mistakes that waste your time
- Lazy loading every image: common advice with an important exception. The web.dev guidance states plainly that lazy loading your LCP image always slows it down. Defer only what sits below the first screen.
- Fixing images when the server is the problem: web.dev suggests a rough split of LCP time, with about 40% for server response and about 40% for downloading the file. As a hypothetical example, if your LCP is 4 seconds and 2 of them pass before the first response, start with the server before compressing images.
- Chasing a score of 100: Google says a high score doesn't guarantee top rankings, and that chasing a perfect score for SEO alone may not be worth the effort.
Third-party scripts and Arabic fonts
Every analytics tool, ad pixel and chat widget is code running on your page. web.dev recommends removing what adds no clear value and loading the rest with async or defer. List each tool, who uses its data and when they last did. Keep the ad tracking you depend on, because removing it costs you campaign measurement.
On Arabic sites, check your font file sizes in the tool's report instead of assuming. Load only the weights you actually use, and make sure text appears in a fallback font during loading.
What to expect after the work
Expect a better experience before you expect higher rankings. Google says it shows the most relevant content even when page experience is below par, and that page experience helps most when many pages offer useful content. So speed work complements SEO without replacing it. Measure the effect on requests on your own site by comparing mobile form submissions over a long enough period before and after the work.
Speed is one thing your site needs. The others are in our article on company websites.
Next step
Measure three pages on mobile today, write the numbers in a table, find the worst metric on your busiest page, and act on the first matching row of the fix-order table. If the trouble lies in how the site is built and you need someone to deal with it, that falls within PlanKit's corporate website service.