Core Web Vitals: How Page Speed Is Hurting Your Google Rankings (And Your Leads)

The business owner's guide to page speed, performance metrics, and the double revenue leak most websites don't know they have

Every time someone clicks on your website and then stares at a loading screen for more than three seconds, there's a 53% chance they've already left. They didn't tell you. They didn't fill in a 'too slow' form. They just hit the back button and visited your competitor's site instead.

Google knows this. Which is why, since 2021, page speed has been a confirmed ranking factor through a set of metrics called Core Web Vitals. Sites that load fast and feel responsive rank better than sites that don't — all other factors being equal.

But here's what most guides about Core Web Vitals miss entirely: slow page speed doesn't just hurt your rankings. It also silently destroys conversions from the traffic you already have. That's a double revenue leak. Your slow site is costing you in two directions simultaneously — fewer visitors from lower rankings, and fewer leads from the visitors who do arrive.

This guide explains exactly what Core Web Vitals are, what they're doing to your rankings and lead volume, how to diagnose your own site in two minutes, and — critically — what to do about it, whether you're a business owner who can action quick wins yourself or someone who needs to brief a developer.

The Short Answer: Page Speed Is a Confirmed Google Ranking Factor (With Real Business Consequences)

Google confirmed Core Web Vitals as ranking signals in June 2021 with what it called the Page Experience update. For the first time, user experience metrics — specifically how fast a page loads, how responsive it feels, and how stable its layout is — were officially woven into the ranking algorithm.

This was a significant shift. Google had long valued content quality, backlinks, and technical crawlability. Adding user experience signals sent a clear message: a technically indexed, well-linked page with excellent content can still be outranked by a competitor whose site simply works better for the people visiting it.

But the ranking impact is only part of the business case for fixing page speed. The conversion impact is often larger and more immediately measurable. Research from Deloitte found that a one-second improvement in mobile site load time translates to a 7% increase in conversion rate. For an e-commerce site doing R100,000 per month in online revenue, one second of improvement is worth R7,000 per month in additional sales — before any ranking improvement is counted.

The combined picture: a slow site ranks lower (fewer people find you) and converts less (fewer of those who find you take action). Fix the speed, and both metrics improve simultaneously.

What Are Core Web Vitals? The Three Metrics That Matter

Core Web Vitals are a set of three specific measurements that Google uses to assess the real-world user experience of a page. The word 'core' matters: these are the three metrics Google has decided are most closely correlated with whether users have a good or bad experience loading a webpage.

LCP (Largest Contentful Paint): how fast your page appears loaded

LCP measures how long it takes for the largest visible content element on the page to finish loading. This is usually your hero image, the main product photo, or a large heading text block at the top of the page.

The reason LCP matters from a user perspective: it's the moment a visitor perceives the page as 'loaded enough to use.' Before LCP, they're watching a loading screen. After LCP, they start engaging with your content and deciding whether to stay.

Google's threshold: LCP under 2.5 seconds is 'Good.' Between 2.5 and 4 seconds is 'Needs Improvement.' Over 4 seconds is 'Poor' and carries active ranking risk.

Business translation: Every second your LCP extends beyond 2.5 seconds is a second your potential customer sits looking at nothing while your value proposition fails to appear. The median mobile LCP for SME websites is approximately 3.1 seconds — already outside Google's 'Good' range.

INP (Interaction to Next Paint): how responsive your page feels

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. While FID only measured the delay before the browser started responding to the first interaction, INP measures the worst-case delay for any interaction throughout the entire page visit. It captures what happens when a user clicks a button, opens a dropdown, submits a form, or types in a search field.

Google's threshold: INP under 200 milliseconds is 'Good.' Between 200ms and 500ms is 'Needs Improvement.' Over 500ms is 'Poor.'

Business translation: When a visitor clicks your 'Get a Quote' button and nothing happens for half a second, the digital equivalent of a staff member ignoring a customer, many users will click again (sometimes submitting a duplicate enquiry), assume the button is broken, or leave. Poor INP is one of the quietest conversion killers in the web experience toolkit.

CLS (Cumulative Layout Shift): how stable your page layout is

CLS measures how much the visual elements of your page jump around unexpectedly while it's loading. Every time a button moves, a text block shifts down, or an image pops into the layout after the initial paint, Google records the shift and adds it to your CLS score. The higher the score, the more unstable your layout.

Google's threshold: CLS under 0.1 is 'Good.' Between 0.1 and 0.25 is 'Needs Improvement.' Over 0.25 is 'Poor.'

Business translation: Poor CLS is the reason visitors accidentally click the wrong button because it moved as they tapped it. On mobile, with smaller touch targets and slower connections, layout instability is responsible for mistaken form abandonment, accidental social shares, and frustrated users who feel the site is broken. It's also the most common complaint we hear about newly redesigned websites that were built with heavy page builders.

How to Check Your Core Web Vitals Right Now (Free, Takes 2 Minutes)

Before investing in fixes, you need to know where you stand. Here are the three tools to use, in order of priority:

• Google PageSpeed Insights (pagespeed.web.dev) — Enter your URL and get both a performance score (0–100) and the specific CWV measurements for your page. Critically, run the test on your URL in Mobile mode, not Desktop — Google uses mobile-first indexing, so mobile scores are what actually affect your rankings. A score under 50 on mobile is a significant problem. Under 30 is urgent.
• Google Search Console — Core Web Vitals report — Go to your GSC account, navigate to Experience > Core Web Vitals. This shows field data — the actual experience of real users on your site, not just the lab simulation from PageSpeed Insights. Field data is what Google uses for ranking purposes. If you have enough traffic, you'll see a breakdown of URLs categorised as 'Good,' 'Needs Improvement,' and 'Poor.' Pay particular attention to which pages are in the 'Poor' category — these are your highest-priority fixes.
• Chrome User Experience Report (CrUX) — This is the source dataset Google draws from. You can access it through PageSpeed Insights (it's shown as 'Field Data' when enough data is available for your URL) or via the CrUX dashboard. If your site is new or low-traffic, you may not have enough field data yet, in which case rely primarily on PageSpeed Insights lab data.

One important distinction to understand: lab data (what PageSpeed Insights simulates) and field data (what real users experience) can differ. A page might score 70 in the lab on a fast test connection but score much lower in field data because your real visitors are on slower mobile connections. Field data is what Google weights in ranking decisions — so if your GSC shows 'Poor' field data, that's the number that matters most.

How Much Do Core Web Vitals Actually Affect Your Rankings?

Let's be honest about this, because most guides either oversell or undersell the ranking impact of CWV.

Core Web Vitals are a tiebreaker signal, not a primary ranking factor. Content relevance, backlinks, and technical crawlability still dominate ranking decisions. A site with excellent CWV scores but thin, irrelevant content will not outrank a site with average CWV scores and exceptional content.

What CWV do is act as a deciding factor when other signals are roughly equal. And in practice, 'roughly equal' is extremely common: in any competitive local or niche search, there are typically several pages with comparable content quality and similar authority competing for positions two through eight. CWV performance is one of the signals that breaks those ties.

Additionally, Google has explicitly stated it will apply a 'content warning' to pages that fail Core Web Vitals in certain contexts. While this isn't yet universal, it signals that the weighting is likely to increase over time, not decrease.

The double revenue leak: rankings AND conversions

The conversation about Core Web Vitals usually stops at rankings. Here's why that undersells the business case dramatically.

Consider a local accounting firm with 400 organic visitors per month. Their site has an LCP of 5.2 seconds on mobile, a PageSpeed score of 28, and a mobile bounce rate of 73%. They rank sixth on page one for their primary keyword and generate approximately 8 leads per month from organic traffic.

After a performance optimisation project that brought their LCP to 1.9 seconds and PageSpeed score to 84:

1. Mobile bounce rate dropped from 73% to 41%
2. Average session duration increased from 42 seconds to 2 minutes 18 seconds
3. Organic lead form completions increased from 8 to 19 per month
4. Over the following three months, they moved from position 6 to position 3 for their primary keyword

The conversion improvement (8 to 19 leads per month) happened immediately — from the same traffic volume. The ranking improvement followed over three months. The combined business impact was a 140% increase in organic leads. Both effects from one project.

This is the double revenue leak in reverse: fix the speed, gain on both fronts simultaneously.

The Most Common Core Web Vitals Failures (And What Causes Them)

When we audit a site for CWV issues, the same causes appear over and over. Understanding which cause applies to your site helps you brief your developer correctly and set realistic expectations for what a fix involves.

What kills LCP: the usual suspects

The Largest Contentful Paint is most commonly affected by image issues. The single biggest LCP killer we encounter on SME sites is a hero image uploaded directly from a camera or design export without any compression or resizing. A 4MB JPEG serving as a full-width banner is not unusual. On a mobile connection, that single image can add three to five seconds to the LCP score.

Beyond images, LCP failures commonly result from:

1. Render-blocking JavaScript. Scripts that must run before the browser can paint anything to the screen — even if they're not needed for the initial view. Third-party tag managers, analytics snippets, and social media widgets are frequent culprits.
2. Cheap shared hosting. On shared servers, if other sites on the same server experience a traffic spike, your Time to First Byte (TTFB) increases. We regularly see TTFB values of 2–4 seconds on basic shared hosting plans, meaning the server takes 2–4 seconds just to start responding, before the page begins loading. Managed hosting or a VPS resolves this at relatively modest additional cost.
3. No Content Delivery Network (CDN). Without a CDN, all assets are served from a single server location. If your server is in Johannesburg and a visitor is accessing from Cape Town or internationally, the physical distance adds latency. A CDN distributes your assets globally and serves them from the nearest point of presence.

The most dramatic LCP improvement we've ever achieved took a client's score from 11.2 seconds to 1.6 seconds in a single afternoon. The entire fix was image compression and conversion to WebP format. They had 340 product images served as uncompressed PNGs averaging 2.8MB each. Converting and compressing took three hours of developer time. The ranking recovery started within six weeks.

What causes INP failures: JavaScript overload

INP failures are almost always caused by too much JavaScript running on the main thread. When JavaScript is executing, the browser can't respond to user interactions — which is precisely what INP measures.

The most common causes of high INP scores:

1. Plugin bloat on WordPress. Each installed plugin adds JavaScript to the page, even when that plugin's functionality isn't needed on that specific page. A marketing site with 40 plugins, 8 analytics tools, a live chat widget, a CRM integration, and an A/B testing script is very common. Each of these scripts queues up on the main thread, delaying the browser's ability to respond to user clicks. We regularly see sites where removing 60% of installed plugins (many of which were inactive) reduces INP from 800ms to under 200ms.
2. Heavy JavaScript frameworks on simple pages. Some agencies build marketing websites using React or Vue — frameworks designed for complex web applications — when static HTML with minimal JavaScript would perform dramatically better. A 'Contact Us' page doesn't need React. The JS overhead adds hundreds of milliseconds of unnecessary processing.
3. Third-party scripts with their own event handlers. Chat widgets, ad network scripts, and social media integrations often attach their own event listeners to the page, competing with your site's interactions for main thread priority.

What causes CLS: the jumping page problem

Layout shifts happen when the browser doesn't know how much space an element will take up before it loads — so it reserves no space for it initially, then has to push everything else down when it finally appears.

The most common CLS causes:

1. Images without explicit width and height attributes. If the HTML doesn't tell the browser the image dimensions before the image loads, the browser can't reserve space for it. This is one of the easiest CLS fixes and one of the most common omissions.
2. Dynamically injected content. Cookie consent banners, promotional banners, chat widgets, and email capture pop-overs that insert themselves into the flow after the initial page load push existing content around. These are CLS disasters, particularly when they push a header or navigation bar down after a user has already started interacting.
3. Web fonts loading late. If a fallback font is displayed first and then replaced by the web font when it loads, and the two fonts have different letter spacing or line heights, text will visually reflow. Using font-display: swap and preloading fonts prevents this.
4. Page builder misconfigurations. Elementor, Divi, and WPBakery sites are particularly prone to CLS issues because the way these builders inject CSS and JavaScript often creates multiple rounds of layout calculation. Some configurations are essentially unfixable without switching to a different theme architecture.

How to Fix Core Web Vitals: A Priority Guide for Business Owners

Not all CWV fixes require a developer. Some can be done in an afternoon with the right tools. Others require specialist development work. And some require confronting the honest conclusion that your current website architecture can't be optimised to passing scores without a rebuild.

Here's how to think about the tiers of fix effort:

Quick wins: fixes you can action in a day

These are the changes that don't require touching code and that produce the most reliable immediate improvements:

1. Compress your images. Use a free tool like Squoosh (squoosh.app) to compress images before uploading them. Target under 100KB for images, under 50KB for thumbnails. Convert to WebP format where possible — WebP images are 25–35% smaller than equivalent JPEGs with no visible quality loss. On WordPress, a plugin like ShortPixel or Imagify automates this for the existing media library.
2. Set image dimensions. In WordPress, most themes do this correctly. Check using the PageSpeed Insights 'Avoid Explicit Width and Height' recommendation. If it's flagging specific images, those images need dimension attributes added in HTML.
3. Remove plugins you don't actively use. In WordPress, go to Plugins > Installed Plugins and deactivate (then delete) anything you installed for a past project, anything that adds functionality you no longer use, and any duplicate tools (if you have two caching plugins, two SEO plugins, or two contact form plugins).
4. Install and configure a caching plugin. WP Super Cache (free), W3 Total Cache (free), or WP Rocket (paid) can reduce your TTFB and repeat-visit load time significantly. WP Rocket is the one we recommend most consistently because it requires minimal configuration to produce good results.

Developer fixes: what to brief your web team

The fixes below require developer access and time but are well-defined tasks that any competent web developer can execute. Use the table below as a literal developer brief:

If you're commissioning these fixes as a package, a competent developer should be able to implement all seven in one to two days of work for a typical WordPress or custom site. The resulting PageSpeed score improvement typically ranges from 25 to 50 points depending on the starting state.

When the rebuild is the answer

This is the conversation that most web development guides avoid having. Sometimes, patching doesn't work. The architectural decisions made when a site was built — usually the combination of a heavy page builder, an unoptimised theme, and shared hosting — create performance ceilings that individual fixes can't break through.

Signs that a rebuild may be necessary:

1. Your PageSpeed score is under 30 on mobile despite having already implemented image compression and caching
2. Your site was built with Elementor or Divi on a theme that doesn't offer a lightweight loading option, and your developer has confirmed the builder itself is the bottleneck
3. You're on shared hosting and your TTFB is consistently above 1.5 seconds regardless of caching configuration
4. Your site has over 50 active plugins and significant functionality depends on many of them

A rebuild for CWV purposes doesn't necessarily mean a visual redesign. It means replacing the architecture with one that performs well: typically a lightweight, well-coded WordPress theme (GeneratePress, Kadence, or Blocksy), managed hosting (Kinsta, WP Engine, or Cloudways), and a disciplined approach to scripts and plugins. If a visual redesign is also due, combining the two projects into a single engagement is almost always the most cost-efficient approach.

Core Web Vitals and Google Ads: The Quality Score Connection Most People Miss

If you run Google Ads, here is a piece of information that may reframe your entire perspective on the ROI of a web performance project.

Google Ads Quality Score is calculated in part by the landing page experience that users have after clicking your ad. Google evaluates load speed, mobile-friendliness, and content relevance. A slow, CWV-failing landing page gets a low landing page experience score, which reduces your overall Quality Score, which in turn increases your Cost Per Click.

The relationship is roughly this: for every Quality Score point you lose, your CPC increases by approximately 16-25%. A landing page improvement that takes your Quality Score from 4 to 7 can reduce your CPC by 40-50% for the same ad position. You pay less per click and rank higher in the ad auction simultaneously.

For a business spending R15,000 per month on Google Ads driving traffic to a slow landing page, a Quality Score improvement of three points could reduce that spend to R9,000–10,000 per month for the same results. The performance project pays for itself through Ads savings, before the organic ranking improvements are counted at all.

This is why we evaluate Core Web Vitals performance when onboarding any client who runs both organic SEO and Google Ads. The ROI case for a performance project becomes dramatically stronger when you include both channels in the calculation.

How to Track Core Web Vitals Progress in GA4 and Search Console

After implementing performance fixes, you need to know whether they worked. Here's the measurement framework:

• Google Search Console: Core Web Vitals report — Your primary source of truth. After fixes are deployed, it typically takes two to four weeks for the GSC report to update with new field data measurements. Look for URLs moving from 'Poor' to 'Needs Improvement' and from 'Needs Improvement' to 'Good.' This confirms Google is registering the improvement and re-assessing the ranking signal.
• Google Search Console: Performance report — Monitor your organic impressions and average position for target keywords over the 30–90 days following performance improvements. Ranking signal changes from CWV improvements are not immediate — Google needs to re-crawl, re-assess, and update rankings. Typical visible ranking movement: 30–90 days after GSC confirms improved field data.
• GA4: Bounce rate and engagement metrics — This is where conversion impact shows up fastest. In GA4, go to Reports > Engagement > Landing Pages. Filter by organic traffic source. Compare your bounce rate (or 'engaged sessions' rate) and average session duration before and after the performance fixes. Improvements here typically appear within days of deployment, not weeks.
• GA4: Goal completions from organic — If conversion tracking is configured correctly in GA4 (form submissions, phone call clicks, e-commerce transactions), track organic goal completions monthly. A speed improvement that improves mobile bounce rate from 70% to 40% will almost always produce a measurable uplift in organic conversions within the same reporting period.
• PageSpeed Insights: baseline and milestone checks — Run and record your PageSpeed score (mobile) at three stages: before any work begins, after quick wins, and after developer fixes. Keep a simple log of scores. This gives you a clear before/after narrative for internal reporting and justifies future investment.

One practical note: don't let the technical measurement distract from the business outcome. The ultimate measure of whether CWV improvements worked is organic lead volume and cost per lead from organic traffic. Everything else is an indicator; that is the result.

Frequently Asked Questions

Are Core Web Vitals a confirmed Google ranking factor?

Yes — Google confirmed Core Web Vitals as ranking signals with the Page Experience update in June 2021. However, they are best understood as a tiebreaker signal rather than a primary ranking factor. Content relevance, backlinks, and technical crawlability still dominate ranking decisions. In practice, CWV scores are most impactful in competitive SERPs where multiple pages have comparable content quality — which describes the majority of local and niche business search results. Google has also indicated that the weighting of user experience signals is likely to increase over time.

What PageSpeed Insights score do I need for good SEO?

A score of 70 or above on mobile is a solid target. Scores of 85+ are excellent. The absolute PageSpeed lab score matters less than the underlying Core Web Vitals field data in Google Search Console, but they're closely correlated. More importantly: compare your score to your top organic competitors, not to an abstract benchmark. If you score 55 and your top competitor scores 45, you likely have a speed advantage despite both scores being below 70. If you score 40 and they score 80, the gap is contributing to the ranking difference. Use PageSpeed Insights in mobile mode — Google's mobile-first indexing means mobile scores are what affect rankings.

How long does it take to improve Core Web Vitals?

The fixes themselves can range from hours (image compression) to weeks (architecture-level developer work). However, the ranking impact of improvements takes longer to manifest than the performance improvements themselves. After deploying fixes, Google typically needs two to four weeks to register the improved field data in Search Console, and then an additional four to eight weeks before ranking movements become visible. For conversion rate improvements, the impact is often immediate — users on your site today experience the faster page, and conversion metrics in GA4 can improve within the first week after deployment. For full ranking impact, allow 30 to 90 days from the date your GSC Core Web Vitals report shows improved field data.

Does page speed affect mobile rankings differently?

Google uses mobile-first indexing, which means the mobile version of your site determines your ranking for all users — not just mobile visitors. This matters because mobile Core Web Vitals scores are almost always significantly worse than desktop scores, for reasons including smaller screens requiring different image sizes, mobile network variability, and less powerful processors handling JavaScript. When you run PageSpeed Insights, always prioritise the mobile score. The desktop score is useful context but the mobile score is what Google predominantly weighs in its ranking assessment.

Can I pass Core Web Vitals with a WordPress site?

Yes — but the outcome depends heavily on your hosting, theme, and configuration. A WordPress site on managed hosting (Kinsta, WP Engine, Cloudways), using a lightweight theme (GeneratePress, Kadence, Blocksy), with a well-configured caching plugin and properly optimised images can routinely achieve PageSpeed scores of 80 to 95. The same WordPress site on basic shared hosting with Divi or Elementor, 50+ plugins, and uncompressed images will struggle to reach 40 regardless of optimisation effort. If you're on WordPress and have already tried optimisation without improvement, the combination of your page builder and hosting may be the architecture bottleneck — which typically requires rebuilding rather than patching.

Or download the free CWV Fix Checklist:

15 common causes + developer brief template → yoursite.co.za/cwv-checklist

This is article 5 in our SEO Strategy & Fundamentals series.

Also in this series:

1. Article 1: Why Your Website Isn't Ranking on Google: A Technical SEO Checklist → yoursite.co.za/blog/website-not-ranking-google
2. Article 2: How Long Does SEO Take to Show Results? Realistic Timelines for SMEs → yoursite.co.za/blog/how-long-does-seo-take
3. Article 3: On-Page vs Off-Page vs Technical SEO: What to Prioritise First → yoursite.co.za/blog/on-page-vs-off-page-vs-technical-seo
4. Article 4: What Is Domain Authority and How Does It Affect Your Rankings? → yoursite.co.za/blog/domain-authority-explained

About the Author

Written by the web development and SEO team at [Your Agency Name]. We build fast, SEO-ready websites for South African SMEs and measure performance improvement in rankings, lead volume, and cost per acquisition — not just PageSpeed scores.

yoursite.co.za | hello@yoursite.co.za | 031 XXX XXXX