Site speed and Google ranking - Core Web Vitals explained

Dashboard with Core Web Vitals metrics and performance

Core Web Vitals are three specific speed and UX metrics that Google directly uses to rank sites - officially since 2021. A site that isn't in the green zone loses positions, especially on mobile devices, where Google primarily measures. Professional optimization is part of our web development service, but you can do a lot yourself - this guide shows you exactly how.

Table of contents:

What Core Web Vitals are

Core Web Vitals are three metrics Google uses to evaluate the real user experience on a site:

  • LCP (Largest Contentful Paint) - how fast the largest visible element loads
  • INP (Interaction to Next Paint) - how fast the site responds to user action
  • CLS (Cumulative Layout Shift) - how much elements 'shift' during loading

Each metric has three zones: green (good), yellow (needs improvement) and red (poor). The goal is all three in the green zone for 75% of visits - Google looks at the 75th percentile of real users, not the average. Translated: it's not enough for your site to fly on your new laptop over fiber internet, it has to be fast on an average phone over a mobile network too.

An important distinction many people miss: Google ranks based on field data - anonymized measurements from real Chrome users over the last 28 days (the CrUX report) - not lab tests. That's why a PageSpeed score of 95 doesn't guarantee the green zone, and vice versa: a site with a score of 70 can have all three metrics in green.

How much does it affect ranking? Core Web Vitals aren't the decisive factor - quality content and links still carry the most weight. But with evenly matched competition, the faster site gets the edge, and a slow site loses visitors before they even see the content. In practice, the effect of speed on conversions is often bigger than the effect on ranking itself - which is why optimization pays off twice.

LCP - Largest Contentful Paint

LCP measures the time from opening the page to the moment the largest visible element appears - most often the hero image or a large heading.

  • Green zone: under 2.5 seconds
  • Yellow zone: 2.5-4.0 seconds
  • Red zone: over 4.0 seconds
How to measure LCP

Enter your URL into PageSpeed Insights (pagespeed.web.dev) and check the field data at the top of the report. Then in the lab section click on the LCP metric - Lighthouse shows you exactly which element is the LCP on that page. That's the element you optimize, not 'all images on the site'.

Typical causes and fixes
  • Oversized hero image - a 2 MB JPEG on a mobile network eats 2-3 seconds on its own. Fix: WebP/AVIF format, srcset for responsive versions, compression.
  • LCP image loading lazily - lazy-loading the hero image is a classic mistake. Fix: remove loading='lazy' from the LCP element, add fetchpriority='high' and a preload tag.
  • Slow server - if TTFB (time to first byte) exceeds 600ms, the problem starts before anything is even shown. Fix: better hosting, caching, CDN.
  • Render-blocking CSS and JavaScript - the browser waits to process them before rendering. Fix: defer for JS, inline the critical CSS.

In practice, just optimizing the hero image and adding a preload often brings LCP from over 4 seconds to under 2.5 - the biggest gain for the least work.

INP - Interaction to Next Paint

INP measures the time from a user action (click, typing, tap) to the site's visual reaction. It replaced the older FID metric in 2024 and is stricter: it looks at all interactions during a visit and grades you by one of the worst, so it's not enough for just the first interaction to be fast.

  • Green zone: under 200ms
  • Yellow zone: 200-500ms
  • Red zone: over 500ms
How to measure INP

You'll see INP in the field data of PageSpeed Insights (the lab test doesn't measure it directly). For deeper debugging, open Chrome DevTools > Performance panel, record a session while clicking around the site and look for long tasks marked in red - those are the scripts blocking the main thread and keeping the site 'frozen' while the user waits for a reaction.

Typical causes and fixes
  • Third-party scripts - Tag Manager with a pile of tags, Hotjar, chat widgets, video embeds. Fix: async or defer on everything, plus a regular audit - drop the tags nobody looks at.
  • Chat widgets and similar add-ons that load immediately. Fix: delay loading until the first scroll or interaction - nobody opens the chat in the first second.
  • Heavy JavaScript on click - e.g. a product filter that recalculates the entire catalog. Fix: break the work into smaller chunks or move it to a web worker.
  • Oversized DOM - pages with thousands of elements, typical with page builders. Fix: a simpler template, fewer nested sections.

CLS - Cumulative Layout Shift

CLS measures how much elements 'jump' and move while the page loads. This is the metric users find most irritating: you go to click a button, the content shifts and you click an ad instead. It has no unit in seconds - it's a score combining how many elements moved and how far.

  • Green zone: under 0.1
  • Yellow zone: 0.1-0.25
  • Red zone: over 0.25
How to measure CLS

Besides PageSpeed Insights, the fastest way to see exactly what's jumping is Chrome DevTools > Performance: record the page load and the panel marks every layout shift along with the element that caused it. Important: test in mobile view, because CLS on a phone often behaves differently than on desktop.

Typical causes and fixes
  • Images without width/height attributes - the browser doesn't know how much space to reserve, so the content shifts when the image arrives. Fix: width and height on every img tag.
  • Fonts that load late (FOUT) - text renders, then 'jumps' when the real font arrives. Fix: preload the main font and tune font-display.
  • Ads, embeds and banners injected into the layout afterwards. Fix: reserve the space in advance (min-height on the container).
  • Cookie notices pushing content down. Fix: show them as an overlay on top of the content, not as a block that moves the page.
Performance dashboard with site speed metrics
Performance metrics

How to measure - tools and order

Three free tools we use daily, and the order in which to apply them:

1. PageSpeed Insights - first check

Go to pagespeed.web.dev, enter your URL and wait for the report. The top part ('Discover what your real users are experiencing') is field data - that's what Google sees. The bottom part is a lab test with concrete recommendations for fixes. If your site doesn't have enough traffic for field data, you rely on the lab test, but with a grain of salt.

2. Google Search Console - overview of the whole site

In Search Console, open the Core Web Vitals report (especially the Mobile tab). Instead of page by page, Console groups similar URLs and shows you which groups are in the yellow or red zone - so you immediately know whether all blog pages have the problem or just the homepage. When you fix something, click 'Validate fix' so Google re-checks.

3. Chrome DevTools - debugging an individual page

The Lighthouse tab for a quick local test, the Performance panel for detailed analysis of what exactly is slowing things down. This is a tool for finding causes, not for grading - the grade comes from field data.

Golden rule: measure before every change and after it. Without measurement, optimization is guessing - and field data refreshes only over 28 days, so be patient with conclusions.

Practical optimization - what first

Order by impact on most sites - start from the top:

  1. Compress all images into modern formats (typically 60-80% smaller file size)
  2. Activate browser caching and a CDN (Cloudflare has a free plan that covers most smaller sites)
  3. Remove unnecessary plugins and scripts - every extra JS means a slower site
  4. Lazy-load images and iframes below the fold (but never the LCP element)
  5. Optimize fonts - preload the main one, drop the variants you don't use
  6. Minify CSS and JavaScript (modern build tools do this automatically)
  7. Server response time - consider better hosting if your TTFB exceeds 600ms

Images deserve special attention because they're the most common culprit for both LCP and CLS. The choice of format alone makes a huge difference - we covered in detail when to use which in our guide to SVG, WebP and AVIF image formats.

A realistic estimate from practice: an average WordPress site with bad hosting and uncompressed images can be sorted out in about a week of work - from a PageSpeed score of 30 to 85+. If you're still choosing a platform, also read WordPress or a custom site - the choice of technology directly determines how much speed you can squeeze out at all. And since Google measures the mobile version of your site, a mobile-first approach is half the job.

Frequently asked questions

Do I need a PageSpeed score of 100?

No. A score of 100 looks nice in a screenshot, but Google ranks by field data, not the lab score. The goal is the green zone for all three metrics with real users - you often achieve that with a score of 80-90 already. Chasing the last 10 points usually costs more than it's worth.

How long until results show up in Google?

Field data covers the last 28 days, so the full effect of your changes shows only after about a month. In Search Console, run 'Validate fix' to speed up the re-check. Any ranking changes come even slower - count on 1-3 months.

How much does speed optimization cost?

It depends on the state of the site. Basic optimization of a WordPress site (images, caching, excess plugins) is roughly 150-400 EUR one-off in Serbia. Deeper interventions - changing the theme, refactoring code, migrating hosting - cost more, but are sometimes the only path to the green zone. So audit first, decision after.

My site is in the yellow zone - is that urgent?

It's not an alarm, but it is a task. The yellow zone means part of your users have a poor experience and a competitor with green metrics has the edge. Start with your most visited pages - that's where the biggest return is.

Conclusion

Core Web Vitals are no mystery: three metrics, clear thresholds, free measurement tools. The biggest gains are almost always the same - optimized images, fewer scripts, decent hosting. Measure, fix the biggest problem, then measure again. Speed is also just one part of technical SEO - for the bigger picture, check out our SEO optimization service.

If you don't have the time or technical knowledge to carry all of this out yourself, we're here: performance optimization of websites is part of our everyday work, and through our contact page you can request a free PageSpeed audit with concrete recommendations for your site.

Let's talk about your project!Let's talk about your project!