Performance

A 1-Second Delay Costs You 7% of Conversions. We Checked.

Page speed isn't a technical concern. It's a revenue concern. Here's what the data actually shows about the relationship between load time and conversion rate — and the specific fixes that have the biggest impact.

·10 min read

The Number That Should Scare You

53% of mobile visitors leave a page that takes longer than 3 seconds to load. That's Google's number, from their own research, replicated across multiple studies. Not "consider leaving." Not "get frustrated." Leave. Tab closed. Back button. Gone.

Let me make that concrete. If your landing page gets 10,000 mobile visitors per month and your page loads in 4.2 seconds — which is close to the median we see at roast.page — you're losing roughly 5,300 of those visitors before they see your headline, your offer, your testimonials, anything. Your entire marketing funnel is processing the 47% of visitors who were patient enough to wait.

The relationship between speed and conversion isn't linear. It's a cliff. Under 2 seconds, conversion is relatively stable. Between 2-3 seconds, you start losing people. After 3 seconds, the drop accelerates. By 5 seconds, the majority of your mobile audience is gone. And the visitors who do stay are already frustrated, which makes them less likely to convert even if they read the whole page.

The Case Studies That Changed My Mind

I'll be honest: I used to think page speed was a nice-to-have. A technical concern for developers. Something that mattered for SEO but not for conversion in any meaningful way. Then I started looking at the data.

Vodafone improved their Largest Contentful Paint by 31%. The results: 8% more sales. 15% improvement in lead-to-visit rate. 11% improvement in cart-to-visit rate. From a single metric improvement.

Walmart found that every 1 second of load time improvement increased conversion by 2%. Every 100 milliseconds of improvement added roughly 1% to incremental revenue. At Walmart's scale, 100 milliseconds is worth hundreds of millions.

Rakuten 24 improved their Cumulative Layout Shift score (how much the page jumps around while loading) and saw a 33.13% increase in revenue per visitor and a 15.2% increase in conversion rate. Not from adding features. Not from changing copy. From making the page stop jumping.

The pattern is consistent across every case study I've found. Speed improvements produce conversion improvements. The magnitude varies — 2% here, 15% there — but the direction never does. I have not found a single credible case study where making a page faster reduced conversion. Not one.

Core Web Vitals: The Three Numbers That Matter

Google's Core Web Vitals are the closest thing we have to a standardized speed scorecard. They measure three specific aspects of page experience, and each one affects conversion differently.

LCP Largest Contentful Paint

How fast does the main content appear?

Good: under 2.5s. Needs improvement: 2.5-4s. Poor: over 4s. This is the metric that most directly correlates with bounce rate. A slow LCP means visitors are staring at a blank or half-loaded screen for seconds. The hero image, the headline, the CTA — if these take 4+ seconds to appear, you've already lost the five-second test.

CLS Cumulative Layout Shift

How much does the page jump around while loading?

Good: under 0.1. Needs improvement: 0.1-0.25. Poor: over 0.25. CLS is the most insidious metric because it causes mis-clicks. The visitor reaches for a button, the layout shifts, they tap an ad or a different link instead. It feels buggy and untrustworthy. Rakuten's 33% revenue increase from fixing CLS tells you how much this matters.

INP Interaction to Next Paint

How fast does the page respond when you interact with it?

Good: under 200ms. Needs improvement: 200-500ms. Poor: over 500ms. INP measures the lag between a user action (clicking a button, typing in a field) and the visual response. A sluggish form, a button that takes half a second to respond — these create a "this thing is broken" feeling that kills trust at the exact moment you're asking for commitment.

Only about 47% of websites currently meet Google's "good" threshold for all three Core Web Vitals. That means more than half the internet is delivering a measurably degraded experience. If you fix yours, you're already ahead of the majority.

The Speed Fixes That Actually Move the Needle

I'm going to skip the generic advice ("minify your JavaScript") and focus on the specific fixes I've seen produce the largest improvements on real landing pages.

1. Fix Your Hero Image

On most landing pages, the LCP element is the hero image. It's the largest visual element, and it's above the fold, so it directly determines how fast the page feels.

The most common problem: the hero image is a 2400px-wide, 1.5MB PNG being served to every device. On mobile, this image displays at 375px wide. You're sending 4x more data than needed.

The fix: use responsive images. In Next.js, the next/image component handles this automatically — it generates multiple sizes and serves the right one. In plain HTML, use srcset and sizes attributes. For an image that's 100% viewport width, a 375px version for mobile and an 800px version for desktop is sufficient for most cases.

Format matters too. WebP is roughly 25-35% smaller than JPEG at equivalent quality. AVIF is another 20% smaller than WebP. If you're still serving JPEG or PNG hero images, switching to WebP alone can cut your LCP by 0.5-1 second on mobile connections.

One more thing: add fetchpriority="high" to your hero image tag. This tells the browser to prioritize loading this image over other resources. It's a single HTML attribute that can improve LCP by 200-400ms because the browser stops wasting bandwidth on below-the-fold images and scripts.

2. Kill Render-Blocking Resources

Open Chrome DevTools, go to the Performance tab, and look at what's blocking your first paint. For most landing pages, it's a combination of: external CSS files that load synchronously, JavaScript bundles that execute before the page can render, and third-party scripts (analytics, chat widgets, tracking pixels) that load in the <head>.

The fix for each:

  • CSS: Inline the critical CSS needed for above-the-fold content. Load the rest asynchronously. This ensures the hero section renders immediately without waiting for the full stylesheet.
  • JavaScript: Add defer or async to script tags. Defer means the script loads in parallel but executes after HTML parsing. Async means it loads and executes as soon as it's ready. For most landing page scripts, defer is what you want.
  • Third-party scripts: Load them after the page is interactive, not in the head. Your analytics can wait 2 seconds. Your chat widget can wait 5 seconds. Your visitor can't wait at all.

3. Stop the Layout Shift

Layout shift happens when elements on the page change size or position after the initial render. The most common causes on landing pages:

The top 4 layout shift culprits:

1. Images without dimensions. If you don't specify width and height on your images, the browser can't reserve space for them. When the image loads, everything below it jumps down. Fix: always include width and height attributes (the browser uses them to calculate aspect ratio and reserve space).

2. Web fonts loading late. Your page renders with a fallback font, then the web font loads and every line of text reflows because the metrics are different. Fix: use font-display: swap combined with a size-adjusted fallback font, or preload your primary font with <link rel="preload">.

3. Dynamic content injected above the fold. A cookie banner that pushes the page down. A promotional bar that loads 1 second after the page. An ad slot that fills in. Fix: reserve space for dynamic elements with a fixed-height container, even before the content loads.

4. Embeds and iframes. Third-party embeds (video players, social feeds, maps) often load with a zero-height initial state and then expand. Fix: wrap them in a container with a fixed aspect ratio.

Layout shift is the metric most people underestimate. It doesn't make your page slow in the traditional sense — the content loads fine. But it makes the page feel unstable and unpredictable. Every shift is a micro-betrayal of the user's expectations, and those add up faster than you'd think.

4. Lazy Load Everything Below the Fold

Your landing page has a hero, a features section, testimonials, a comparison table, a pricing block, and a footer. The visitor sees the hero first. Everything else is below the fold — invisible until they scroll.

Loading all of that content upfront means the browser is downloading and rendering images, loading scripts, and processing HTML for sections the visitor may never see. It competes for bandwidth and processing power with the one section that actually matters right now: the hero.

The fix: lazy load images and heavy content below the fold. The loading="lazy" attribute on images defers loading until they're about to enter the viewport. For component-level lazy loading, use dynamic imports (in Next.js, next/dynamic) to split heavy sections into separate chunks that load on demand.

The hero section — your LCP content — should load with zero competition. Everything else can wait.

Speed and SEO: The Double Benefit

Google has used page speed as a ranking factor since 2010 and Core Web Vitals as a ranking factor since 2021. The March 2026 core update further strengthened the weight of performance metrics in the ranking algorithm.

This creates a compounding effect: faster pages rank higher, which drives more organic traffic, which generates more conversions. Slower pages rank lower, get less traffic, and convert the traffic they do get at a lower rate. The fast get faster and the slow get slower.

For the AI search engines that are increasingly driving traffic — ChatGPT, Perplexity, Gemini — page speed matters differently but still matters. These systems evaluate page quality when deciding which sources to cite, and a page that loads slowly or shifts around is less likely to be referenced as a high-quality source.

The Speed Audit: What to Measure

Google's PageSpeed Insights is free and gives you everything you need. Enter your URL and you get your Core Web Vitals scores, a performance score out of 100, and specific recommendations for improvement.

When we run pages through roast.page, we include PageSpeed data as part of the Technical & SEO dimension. The analysis shows your performance score alongside LCP, CLS, FCP, and INP — with thresholds marked so you can see exactly where you're passing and failing.

The speed benchmarks that matter:

TARGET

LCP under 2.5 seconds

TARGET

CLS under 0.1

TARGET

INP under 200 milliseconds

TARGET

FCP under 1.8 seconds

Sites that hit all four of these consistently see 15-30% better conversion rates and 24% lower bounce rates than sites that don't. These aren't aspirational numbers. They're table stakes for a serious landing page.

The Uncomfortable Prioritization

Here's what I tell founders who push back on speed work: every second of delay is a tax on every other optimization you've done.

You spent two weeks refining your copy. You hired a designer for your hero section. You collected testimonials and placed them above the fold. You A/B tested your CTA copy. All of that work — weeks of effort, thousands of dollars — is invisible to the 53% of mobile visitors who leave before any of it loads.

Speed isn't a technical nice-to-have. It's the prerequisite for every other optimization to work. The fastest path to more conversions isn't better copy or prettier design. It's making sure people can see the copy and design you already have.

Fix your speed. Then fix everything else.

Want a complete picture of how your page performs? Run it through roast.page — the analysis includes your Google PageSpeed data alongside the design, copy, and conversion assessment so you can see exactly where speed is costing you.

page speedCore Web Vitalsperformance optimizationconversion ratetechnical SEO

Curious how your landing page scores?

Get a free, specific analysis across all 8 dimensions.

Analyze your page for free →

Keep reading