Site speed and Core Web Vitals: how they affect rankings and how to improve them

Site speed has gone from a technical spec that only developers cared about to part of how Google evaluates pages, and to a deciding factor between a visitor who stays and one who leaves. The core of the topic is called Core Web Vitals: three metrics that quantify how fast a page loads, how fast it responds to a click and how stable it is while it loads. It's a technical layer within organic SEO, not a substitute for it. In this guide we'll explain what each metric measures and what its target is, how to test in PageSpeed Insights, what slows most sites down and what to fix first. Want a starting point before you begin? A free SEO audit measures your server's response time and the weight of the page's code, and you test the three metrics themselves in PageSpeed Insights, as explained below.

Why Google takes site speed into account

Google tries to give users the best result, and a good result isn't only relevant content but also an experience that isn't frustrating. A site that takes eight seconds to load, jumps around while you scroll and doesn't respond when you tap a button is a bad experience. In the official Google Search Central documentation, Google recommends that site owners achieve good Core Web Vitals, and writes that a good page experience aligns with what its ranking systems seek to reward.

It's important to understand the size of the effect. Speed isn't a magic bullet that will catapult a weak page from 50th place to first. It's extra weight on the scale, and it mostly breaks ties between pages with similar content and authority. When a competitor with the same content quality loads faster, that small difference can decide who appears higher. In the Israeli market, where many businesses compete for the same keywords, every small advantage adds up.

The business impact is even bigger than the impact on rankings. A slow site loses visitors before they've even seen your offer, shortens time on site and lowers the rate of inquiries and purchases. Even if the direct weight of speed in rankings is modest, its effect on conversions is felt immediately.

The three Core Web Vitals metrics, in plain language

Each of the three metrics measures a different aspect of the experience, from the moment someone arrives to the moment they interact. Understanding what each metric measures is the first step to fixing it correctly.

LCP: how fast the main content loads

LCP, short for Largest Contentful Paint, measures how long it takes for the largest element in the initial view to appear. Usually that's the header image, a banner or the main block of text. It's the moment the visitor feels the page has really loaded, and hasn't just shown a white screen. The target is up to 2.5 seconds, and anything over four seconds is considered poor.

INP: how fast the site responds to you

INP, short for Interaction to Next Paint, replaced the old FID metric in March 2024. It measures how much time passes from the moment the visitor clicks a button, opens a menu or types in a field until the screen responds. The usual cause of a high INP is heavy JavaScript that ties up the browser's main thread: as long as the browser is busy running code, it can't respond to a click. The target is up to 200 milliseconds.

CLS: how stable the page is while it loads

CLS, short for Cumulative Layout Shift, measures jumps in the layout. We all know the moment when you're about to tap a button and suddenly an image or a banner loads above it and pushes everything down. The target is a score of up to 0.1. A high CLS is usually the easiest of the three problems to fix, but also the most annoying one for the visitor.

A point many people miss: according to Google's definitions on web.dev, a page meets the target when it meets it in 75 percent of visits, separately for mobile and desktop. In other words, it's not enough for the site to be fast for you at the office on a fiber connection. It has to be fast for most of your visitors too, who arrive on an average phone over a cellular network.

How to check where you stand, step by step

The main tool, and a free one, is Google's PageSpeed Insights. You enter the page URL, and within seconds you get a separate score for mobile and desktop, a breakdown of the three metrics and a list of recommendations for improvement. Check mobile first: Google crawls and ranks based on the mobile version of a site, and in Israel most browsing comes from phones.

Don't settle for the home page. Check the pages that actually bring traffic and inquiries: a main service page, a product page and a popular article. Often the home page is relatively fast, while the product pages are heavy because of image galleries and third-party scripts. Two tools complement it: the Core Web Vitals report in Search Console, which groups the problem pages across your whole site by type of issue, and Lighthouse, which is built into Chrome, for anyone who wants to see exactly which file is holding up the load.

The most common causes of a slow site

Before you fix anything, it's worth knowing the usual suspects. On most business websites in Israel, slowness comes from a handful of recurring causes, and they can almost always be handled without rebuilding the site.

• Heavy, uncompressed images. The number one cause. A three-megabyte image uploaded straight from the camera can wreck your LCP all by itself.
• Slow, cheap hosting. A crowded shared server in a distant data center lengthens the basic response time before loading has even begun.
• Too many third-party scripts. Ad pixels, chats, maps, widgets and plugins, each of them loading extra code and weighing down the browser.
• Inefficient code and bloated themes. Heavy themes and unnecessary plugins that load a lot of CSS and JavaScript, most of which isn't even used on the page.
• Fonts and background videos. Several weights of the same font, plus a background video on the mobile version, add a lot of weight before the visitor has seen anything.
• No caching. A site that builds every page from scratch on every request, instead of serving a saved, ready version, wastes time on every visitor.
• Elements without set dimensions. Images, banners and ads without a predefined height and width are the prime cause of layout shifts and a high CLS score.

Improving images: the highest return on effort

If there's one action that pays back the investment faster than all the rest, it's taking care of your images. On most sites, images make up the largest share of page weight, so this is where the greatest potential for improving LCP is concentrated.

1. Shrink the dimensions. There's no reason to upload an image 4,000 pixels wide to an area that displays it 800 pixels wide. Resize the image before uploading it, and serve different versions to different screens.
2. Compress in a modern format. Formats like WebP or AVIF deliver similar quality at a much smaller file size than JPEG.
3. Turn on lazy loading for images below the fold. Lazy loading makes them load only when the visitor reaches them, so the initial load is lighter.
4. Don't lazy load the main image. This is a common mistake: if the large image at the top of the page is marked for lazy loading, the browser delays it and LCP suffers. Mark it with high priority instead, for example with fetchpriority="high".
5. Set dimensions ahead of time. Give every image a set width and height to reserve its space and prevent layout shifts.

A common scenario: an online store uploads product images of two to three megabytes each, straight from the camera or the supplier. In a case like that, converting to WebP and shrinking to the actual display size cuts the weight of the images several times over, with no change to the design or the content. The visitor sees exactly the same thing, only faster.

Code, hosting and caching: the infrastructure that holds it all together

After images, these three areas determine how fast the site can be at all. Not every business needs to touch them itself, but it's worth understanding what's happening under the hood.

Cleaning up the code

A browser has to download, parse and run the CSS and JavaScript before it can display the page and make it interactive. The more code there is, and especially render-blocking code, the slower everything gets. The practical steps: minifying files, deferring non-critical scripts with defer or async so they load after the main content, breaking up long JavaScript tasks, and removing plugins you don't really need. Sometimes removing three old plugins improves INP more than any other optimization.

Hosting that matches the load

A quality server is the foundation for every other improvement. Cheap shared hosting puts dozens of sites on the same machine, and when one of them is busy, they all suffer. Moving to faster hosting, preferably with servers geographically close to your target audience, shortens the server's response time before the browser has even started working. For a business targeting an audience in Israel, that's a noticeable difference.

Caching and a content delivery network

Caching means saving a ready version of the page and serving it instead of building it from scratch every time. Combined with a content delivery network (CDN), which serves each visitor a copy from the server closest to them, it can significantly shorten load time. It's one of the most cost-effective improvements, because it helps all your visitors at once without touching the content.

When the platform itself is the problem

On some sites every fix is a band-aid: a heavy theme, dozens of plugins that depend on one another and a page builder that generates excess code on every page. In that situation, once you've exhausted images, caching and hosting, it's worth considering a new site that's built from the start with a performance budget. It's a business decision, not just a technical one, so it's worth understanding the differences between a custom-coded site, WordPress and Wix and what each costs, and looking for a business website development provider that measures speed before launch, not after. And if you replace your site, you must plan 301 redirects and preserve the URL structure, as we detailed in our guide to SEO migration without losing rankings.

Technical SEO beyond speed: structured data and crawl budget

Speed is the most visible part of technical SEO, but not the only one. In the same round of checks, it's worth going over two more topics that affect how Google sees your site.

Structured data and rich results

Structured data in JSON-LD format tells Google precisely what's on the page: a product with a price and availability, an event, a recipe, breadcrumbs or reviews. It makes rich results possible, such as star ratings or a price next to the result, which catch the eye. Two important rules: the markup must match the content the visitor sees on the page, and even valid markup doesn't force Google to show a rich result. Since 2023, Google has almost entirely stopped showing FAQ rich results for business websites, so it's worth investing in the types that are relevant to your business.

Crawl budget: when it actually matters

Crawl budget is the time and resources Google devotes to crawling a site. According to Google's guide, it's a topic that mainly concerns very large sites, with a million pages or more, or sites with more than 10,000 pages whose content changes daily. On a business site with a few hundred pages, the problem is usually not the budget but the waste: redirect chains, internal links to 404 pages, duplicate URLs created by parameters, and a sitemap that includes pages that aren't supposed to be in the index. Cleaning these up helps Google reach your important pages quickly, and it also improves the experience for your visitors.

How speed connects to the full SEO picture

Speed is an important layer, but it doesn't stand on its own. A fast site with weak content still won't rank, and a slow site with excellent content will pay an unnecessary price. The real power comes when you connect the technical side with the content side, so it's also worth reading our guide to optimizing content and page structure, which completes the picture from the content side.

In online stores the effect is double. On product and category pages, every second of loading translates into abandoned carts, so speed is a matter of profitability, not just rankings. Anyone who runs a store will also want to dig into our online store SEO guide. The combination of fast infrastructure, strong content and authority is what produces results that last over time, and if you'd rather put all these fronts in professional hands, you're welcome to explore VeloLinx's organic SEO packages.

Frequently asked questions

What is a good page load time for a website?

A simple rule of thumb: aim for the main content to appear within 2.5 seconds at most on mobile, which is the target of the LCP metric. Anything over four seconds is considered poor and needs attention. Keep in mind that speed isn't one number, but a combination of loading, responsiveness and stability that are measured together in Core Web Vitals.

Will improving site speed alone boost my Google rankings?

Not necessarily. Speed is a real signal, but one of many, and it works mainly as a tiebreaker between pages with similar content and authority. The biggest improvement comes when you combine a fast site with quality content, the right structure and authority. Speed removes a barrier; it doesn't replace the rest.

What's the difference between lab data and field data in PageSpeed Insights?

Lab data is a simulation Google runs under fixed conditions, useful for finding problems. Field data comes from real users who visited the site in Chrome, and it's the data Google actually uses to evaluate page experience. When you measure real success, you look at field data, and on a site with little traffic you compare lab data before and after every change.

What is INP, and why did it replace FID?

INP measures how fast the site responds to a visitor's interactions, such as clicking a button or opening a menu. It replaced FID in March 2024 because it's more accurate: it looks at interactions throughout the whole visit, not just the first one. The target is a response within 200 milliseconds at most.

My WordPress site is slow. Where should I start?

With three steps, in this order. First, deal with your images through compression, a modern format and resizing to the display size, because that gives the biggest improvement. Second, remove unnecessary plugins that pile on code. Third, turn on caching and check whether your hosting is strong enough. Measuring before and after every change will show you exactly what worked.

What else does technical SEO include besides speed?

Technical SEO includes everything that lets Google crawl, understand and display your site: a sound URL structure and internal links, correct redirects, a clean sitemap, a robots.txt file that doesn't block important pages, canonical tags, structured data and mobile friendliness. Speed is part of the list, not the whole list.

Do I need a Lighthouse score of 100?

No. Lighthouse is a lab tool, and its score varies between runs and between devices. Google takes into account field data from real visitors, so the goal is to meet the good thresholds for LCP, INP and CLS in most visits. A score of 100 in the lab is nice, but it's neither a requirement for ranking nor a promise of it.

What to do next

Run PageSpeed Insights on your home page, your main service page and the page that brings in the most inquiries, and write down the three metrics on mobile. Then start with the images. A free SEO audit will add your server's response time and the weight of the page's code to the picture, two things that affect loading. And if you'd like a clear order of priorities without guesswork, with speed handled as part of ongoing organic SEO work, you can message us on WhatsApp at 050-741-8449.