Site speed and Core Web Vitals in plain language

A site's speed is not a single number. Google measures it with three metrics, the Core Web Vitals: how quickly the main content appears (LCP), how quickly the page responds when you tap or click something (INP) and how stable it stays while it loads (CLS).

All three are measured on real visitors, separately for mobile and desktop. A fast site is not only a matter of SEO. It is the site that does not make visitors leave before they see what you offer.

The three Core Web Vitals in simple terms

For each metric, Google sets a threshold for a “good” result. It assesses this at the 75th percentile of visits, which means at least three out of four visits must be within the threshold.

• LCP (Largest Contentful Paint): how much time passes until the largest element on the screen appears, usually the main photo or the heading. Up to 2.5 seconds is considered good.
• INP (Interaction to Next Paint): how quickly the page shows that it has responded when you tap a button, open a menu or type in a form. It measures interactions throughout the visit and keeps one of the slowest. Up to 200 milliseconds is considered good.
• CLS (Cumulative Layout Shift): how much the page “jumps”. If you are about to tap a link and at that moment the text moves down because an image above it has loaded, that is a layout shift. Up to 0.1 is considered good.

INP replaced FID (First Input Delay) in March 2024. FID only measured the delay of the first interaction, whereas INP looks at the whole visit. If you are reading a guide that still talks about FID, it is out of date.

How to check your site's speed

Two free Google tools are enough to know where you stand:

1. Open PageSpeed Insights and enter the address of a page. Start with the homepage and with the page that brings in the most customers.
2. First look at the real user data at the top, which comes from the Chrome User Experience Report. This is the data that counts in the assessment. If the page does not get enough traffic, it will not be shown for that particular page.
3. Further down, the Lighthouse analysis is a lab test. It helps you find causes, but it does not measure INP, because there is no real user tapping anything. Instead it shows Total Blocking Time, meaning how long the browser was blocked by long tasks, usually scripts.
4. In Google Search Console, the Core Web Vitals report groups the pages of your site into good, needs improvement and poor, for mobile and desktop. There you can see whether a problem affects one page or a whole type of page.
5. After each fix, check again. Real user data covers the last 28 days, so the improvement shows up gradually.

Common causes and how to fix them

On most slow sites the problems are few and they keep repeating:

• Heavy images: photos straight from the camera, several megabytes each, on a page that displays them small. Fix: compression, a modern format such as WebP or AVIF, and two or more sizes with srcset, so that phones download the smaller version.
• Lazy loading on the wrong image: lazy loading deliberately delays images until you get close to them. It is right for images further down the page, not for the main image, which is often the LCP. That one should load immediately, and it can be given high priority with fetchpriority.
• Too many scripts: chat, pixels, sliders, maps, social media widgets. Each one keeps the browser busy and makes INP worse. Fix: keep the ones you actually use and load the rest later, or only when they are needed.
• Fonts: many families and weights, loaded from an external server. Fix: fewer files, the WOFF2 format, hosting on your own server and preload for the main font.
• Images and embeds without dimensions: the browser does not know how much space to reserve, so the text moves when they load. Fix: width and height on every image, or fixed aspect ratios in CSS.
• Popups and bars that push the content down: an offer bar or a cookie banner that appears at the top and pushes the page down creates a layout shift. Fix: show it over the content without moving it, or in space reserved for it from the start.
• Slow server: if the first response is slow, everything else is slow too. Fix: caching, suitable hosting and less work on each request.

How much speed matters to Google

Google states that Core Web Vitals are used by its ranking systems, as part of page experience. It also states that the relevance and quality of the content matter more. A fast site with weak content will not outrank a slower page that answers the search better.

Speed, however, matters on every visit, not only for rankings. You have already paid for a visitor from an ad with the click. If the landing page is slow, some of those clicks are lost before the offer even appears. For the current thresholds and guidelines, the references are web.dev and Google Search Central.

In practice, most of the gain comes from simple steps: photos in WebP at the right size and with declared dimensions, fonts served from the same server, few external scripts. The websites we build are delivered on the same principle: fast loading, technical SEO, proper headings, a sitemap and structured data.