Website Speed and Conversions: Core Web Vitals in Practice

Most people accept that a slow site loses customers, but the advice around it is full of recycled statistics that nobody can trace back to a source. The useful questions are narrower: which parts of "speed" do visitors actually feel, what are the agreed thresholds, which of those your server controls, and how to measure the effect on your conversion rate. This article answers those with Google's published Core Web Vitals definitions, concrete fixes, and a measurement setup you can copy.

Why speed changes conversion rates

Rather than quote someone else's percentages, it helps to look at the mechanism. A visitor who arrives from an ad or a search result is deciding, in the first few seconds, whether this page is worth their time. Three things interrupt that decision:

• Waiting for anything useful to appear. A blank or half-rendered screen gives the visitor a reason to hit Back, especially on mobile.
• Taps and clicks that do nothing. A button that does not respond feels broken, so people tap again, abandon a form, or leave.
• Content that jumps. A layout that shifts as images and ads load causes mis-taps — the visitor clicks the wrong thing, or loses their place.

Each maps to one of Google's Core Web Vitals. The impact on conversions is real but differs a lot between sites, which is why the last section of this article shows how to measure it on your own traffic rather than borrowing a number.

Core Web Vitals and their thresholds

Google defines three Core Web Vitals and publishes thresholds for each on web.dev. A page "passes" when the 75th percentile of real page loads, measured separately for mobile and desktop, falls in the "good" range.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Google states that Core Web Vitals are used by its ranking systems as part of page experience, while also stressing that relevant, helpful content matters more. Treat good vitals as a user-experience goal first and a possible tie-breaker in search second.

How server response time feeds into LCP

LCP is not just a front-end metric. Google's web.dev guide on optimizing LCP splits it into four sub-parts:

1. Time to First Byte (TTFB) — from the navigation start until the first byte of HTML arrives. Includes redirects, DNS lookup, TCP and TLS setup, and the time your server takes to generate the page.
2. Resource load delay — the gap between TTFB and when the browser starts downloading the LCP resource (often the hero image).
3. Resource load duration — how long that resource takes to download.
4. Element render delay — from download finished until the element is actually painted.

Nothing can render before the HTML arrives, so every millisecond of TTFB is added directly to LCP. If your server takes 1.5 seconds to produce HTML on mobile, you have only one second left for everything else to stay under 2.5 seconds. web.dev suggests that, as a rough guide, most sites should aim for a TTFB of 0.8 seconds or less. For a deeper look at the first sub-part, read what TTFB is and why it matters.

You can see the TTFB breakdown for any URL from your own terminal:

curl -o /dev/null -s -w 'dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n' https://example.com/

Each value is cumulative from the start of the request. If ttfb is much larger than tls, the time is being spent on your server generating the page. If dns alone is large, see how DNS latency affects speed.

Practical fixes, by metric

Reduce TTFB (server side)

• Cache full pages for anonymous visitors. A cached page can be served by nginx or a CDN without running your application at all.
• Enable the PHP OPcache (or your runtime's equivalent) and confirm it is actually on in production.
• Find slow database queries. Enable the slow query log (MySQL: slow_query_log = 1, long_query_time = 0.5) and add indexes or caching for the worst offenders.
• Remove redirect chains. http:// → https:// → https://www. is two extra round trips before the page even starts loading. Link directly to the final URL.
• Use a CDN for static assets and, where possible, cached HTML, so visitors far from your server are not paying the full network distance.

Improve the rest of LCP

• Never lazy-load the LCP image. loading="lazy" on a hero image delays it on purpose.
• Give the LCP image fetchpriority="high" and make sure it appears in the HTML, not only after JavaScript runs.
• Serve properly sized images in modern formats (WebP or AVIF) with srcset, so phones do not download desktop-sized files.
• Reduce render-blocking CSS and JavaScript in the <head>; defer scripts that are not needed for first paint.

Improve INP

• Break long JavaScript tasks into smaller pieces so the main thread can respond to input between them.
• Audit third-party scripts (chat widgets, tag managers, A/B testing tools). They often run heavy work on every interaction.
• Give immediate visual feedback on click (disable the button, show a spinner) before doing expensive work.

Improve CLS

• Set width and height attributes (or CSS aspect-ratio) on images and video so the browser reserves space.
• Reserve fixed space for ads, embeds and cookie banners instead of inserting them above existing content.
• Use font-display: swap or optional carefully and match fallback font metrics to limit text reflow.

Measure the effect on your own conversions

The only conversion figure that matters is yours. To get it, collect field data (real user monitoring, or RUM) and join it with conversion events. Google's open-source web-vitals JavaScript library makes the first part a few lines:

import {onLCP, onINP, onCLS, onTTFB} from 'web-vitals';

function send(metric) {
  navigator.sendBeacon('/rum', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,   // "good" | "needs-improvement" | "poor"
    id: metric.id,
    page: location.pathname
  }));
}

onLCP(send);
onINP(send);
onCLS(send);
onTTFB(send);

Store these alongside a session identifier, then compare conversion rate per LCP rating bucket for the same page type (for example, product pages on mobile). Be careful about the conclusion: slow sessions also tend to come from older devices and weaker networks, whose owners may convert differently anyway. The cleanest evidence comes from a before/after comparison around a single performance change, or from an A/B test where one variant is deliberately faster.

Free sources of field data you already have:

• PageSpeed Insights shows Chrome User Experience Report (CrUX) data for URLs and origins with enough traffic, alongside a Lighthouse lab test.
• Google Search Console → Core Web Vitals groups your URLs into good, needs improvement and poor, for mobile and desktop.

Keep watching server response time

Core Web Vitals reports are based on a rolling 28-day window, so a regression can hurt conversions for weeks before the report shows it. Server response time is the part you can watch continuously: a synthetic check that requests your page every few minutes and records DNS, connect, TLS and time to first byte will show a slow deploy, an overloaded database or a dying cache within minutes. It does not replace RUM — it measures from one location and does not render the page — but it is an early warning for the TTFB part of LCP. Our guide to response-time alerts explains how to set thresholds that do not fire on every blip.

FAQ

What is a good page load time?

"Load time" is too vague to target. Use Google's thresholds instead: LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1, at the 75th percentile of real visits.

Does a fast Lighthouse score mean my site is fast?

Not necessarily. Lighthouse is a lab test on one simulated device and network; Core Web Vitals assessments use field data from real users. Use Lighthouse to debug and field data to judge.

Why is my TTFB fine in curl but LCP still poor?

Your server is not the bottleneck. Look at the other three LCP sub-parts: a late-discovered or oversized hero image, render-blocking scripts, or client-side rendering that delays the main content.

Key takeaways

• Speed affects conversions through waiting, unresponsive input and layout jumps — LCP, INP and CLS.
• Good thresholds: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1, judged at the 75th percentile.
• TTFB is the first part of LCP; aim for roughly 0.8 s or less, and fix it with caching, faster queries and fewer redirects.
• Measure conversion rate by vitals bucket on your own traffic instead of relying on borrowed statistics.
• Watch server response time continuously; field reports lag by weeks.

Uptime Monitor records DNS, connect, TLS, time-to-first-byte and total response time for every check, charts the response time, names the likely bottleneck phase when the site is slow, and can alert you when response time stays above a threshold you set for as many consecutive checks as the site's fail threshold. That makes it a simple early-warning system for the server side of LCP. Start with the free plan and set a response-time threshold for your most important landing page.