How We Improved a Client's LCP from 5.2s to 1.8s (And Increased Conversions by 34%)

If you're running paid traffic, here's a number that should bother you: the average mobile landing page takes over 8 seconds to fully load. Most users are gone by second three.

We deal with this constantly at Wonderflow. Performance marketing only works when the full funnel works—and a slow landing page is a hole in the bucket that no amount of ad spend can fix.

This post breaks down a real optimization we ran on a client's Webflow landing page. Here's what moved:

• Largest Contentful Paint (LCP): 5.2s → 1.8s
• Form submissions (MoM): +34%
• Bounce behavior: noticeably calmer almost immediately after deploy

No redesigns. No platform switch. Just targeted, technical fixes aimed at one thing: getting the hero on screen faster.

First, why LCP is the metric that actually matters for paid traffic

Largest Contentful Paint measures how long it takes for the biggest visible element—usually the hero image or headline block—to render in the viewport. For the user, LCP is basically the moment the page feels loaded.

This matters beyond SEO. Yes, Google's Core Web Vitals use LCP as a ranking signal, but for a paid landing page, the conversion math is more immediate: a slow LCP means people hit back before your offer even registers.

The question "does page speed affect conversions?" stopped being theoretical a long time ago. A landing page bleeding out at 5-second LCP is an expensive problem when you're paying for every click.

What we were working with

The setup:

• Platform: Webflow
• Tracking: Google Tag Manager with a standard ads + analytics stack
• Primary conversion: form submissions
• Measurement: month-over-month lift after changes stabilized

The problem: LCP clocking around 5.2 seconds on mobile under real-world conditions. Lighthouse occasionally showed better numbers in lab runs, but cold sessions—the kind every paid visitor experiences, no cache, no warm connections—were consistently awful.

This is a pattern we see constantly when we do performance marketing audits. Lighthouse can flatter you. Real users don't.

‍

Having speed issues of your own? See how much it might be costing you:

‍

Step 1: Actually confirm what the LCP element is

Before you touch anything, you need to know what the browser considers the LCP element. Don't guess.

We used:

• PageSpeed Insights for field data and initial diagnostics
• Chrome DevTools Performance panel to confirm the element and trace the exact load timeline
• Lighthouse as a debugging aid, not a scorecard

In this case: the LCP element was the hero image. Seemed obvious in hindsight, but confirming it changed where we focused.

The actual problem: the browser started the hero image too late

Slow LCP usually comes from one of four buckets:

1. High TTFB (server response is slow before anything else can happen)
2. Resource load delay (the browser discovers the LCP element late)
3. Resource load duration (file is too large, CDN is far, bandwidth is constrained)
4. Render delay (render-blocking CSS/JS holds up the first paint)

Our main culprit was resource load delay.

The hero image request wasn't starting early enough. The browser was busy discovering other resources—scripts, stylesheets, third-party tags—and only got around to the hero image after a pile of other work was already queued. If you've ever stared at a waterfall chart and seen your hero image kick off suspiciously late, you know exactly what this looks like.

What we changed (the stuff that actually moved the number)

1. Made the LCP image visible to the browser from the start

On a lot of Webflow pages, the hero is either a CSS background image or loaded in a way that the browser can't prioritize early. CSS background images, in particular, are invisible to the browser's preload scanner until the stylesheet has been parsed. That's a meaningful delay before a single pixel loads.

We moved the hero to a proper <img> element with explicit priority signals:

html

<img
 src="/images/hero.webp"
 srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
 sizes="(max-width: 767px) 100vw, 50vw"
 fetchpriority="high"
 loading="eager"
 alt="..."
/>

The fetchpriority="high" attribute tells the browser: this matters, start it now. And loading="eager" is there because lazy loading your LCP image—which happens more often than you'd think with "optimize everything" defaults—is one of the fastest ways to tank your LCP score.

2. Added a preload hint for the hero

Even with a correctly structured <img>, adding a <link rel="preload"> in the document head is the most direct way to guarantee the browser starts the hero as early as possible:

html

<link
 rel="preload"
 as="image"
 href="/images/hero-1600.webp"
 imagesrcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
 imagesizes="(max-width: 767px) 100vw, 50vw"
/>

This is particularly effective on Webflow, where you have some control over the <head> but can't always restructure the full document order.

3. Cleaned up above-the-fold resource contention

Even with a prioritized hero image, other resources can compete for bandwidth and delay the first meaningful paint. We audited everything loading above the fold:

• Early-loading scripts that weren't needed for the initial render
• Animations triggered on load (genuinely nice-looking; genuinely bad for LCP)
• Third-party embeds that fired before the page had a chance to show anything

The goal isn't a spartan page. It's a page that gets the hero visible fast and loads everything else after. Above-the-fold optimization is really just: don't make the hero wait for things that don't need to go first.

4. Reviewed GTM so it wasn't competing with critical rendering

GTM is table stakes for performance marketing. It's also one of the more common quiet performance drains on landing pages, because tag sprawl accumulates over time and nobody audits it.

We did a focused pass:

• Removed duplicate pixels firing on the landing page (this happens more than anyone admits)
• Deferred non-critical tags where possible
• Made sure nothing in the tag stack was blocking the page from rendering the hero

This is the less glamorous side of landing page optimization, but it's real.

5. Images, CDN, and TTFB—in the right order

We also handled the standard image hygiene: converted to WebP, sized assets properly for different breakpoints, confirmed caching headers were set correctly.

One note on order of operations: if your primary problem is resource load delay, compressing the image won't feel like it did much—because the browser is still starting the request late. Fix the discovery problem first, then optimize the asset itself.

Webflow has CDN behavior built in, so TTFB wasn't our ceiling here. But if you're on a slow host or serving assets from a single origin, improving your TTFB should come before everything else.

How we validated it (beyond the Lighthouse score)

Lab scores are a starting point, not a finish line. Here's how we confirmed the change was real:

Technical validation: Chrome DevTools traces confirmed the hero image request was now starting earlier in the waterfall. LCP element was correctly identified and prioritized.

Business validation: Form submissions increased 34% month-over-month. Bounce behavior improved noticeably. The results held over time—not a one-week blip.

That second layer matters. Core web vitals improvements that don't show up in actual conversion data are interesting but not useful. We kept measuring until the lift was durable.

Results

MetricBeforeAfterLCP5.2s1.8sForm submissionsBaseline+34% MoMBounce behaviorElevatedNoticeably improved

The checklist if you want to replicate this

Identify the actual LCP element before doing anything else—PageSpeed Insights and Chrome DevTools both show you directly. Once you know what it is:

1. Make it a proper <img> element (not a CSS background)
2. Add fetchpriority="high" and loading="eager"
3. Add a <link rel="preload" as="image"> in the document head
4. Audit what's loading above the fold and defer anything non-essential
5. Review your GTM container for duplicate or early-firing tags
6. Compress and size images correctly (WebP/AVIF for hero assets)
7. Check TTFB if load times still feel sticky after the above

The same logic applies whether you're on Webflow, Shopify, or WordPress—resource discovery and priority behavior is a browser-level problem, not a platform-specific one.

Why this is a paid media problem, not just an SEO problem

Slow pages hurt organic rankings through Google's Page Experience signals. That's real. But for performance marketing teams, the more immediate damage is to funnel economics:

• Clicks you paid for that bounce before the offer loads
• Conversion rates that make winning ad creative look like it isn't working
• Budget efficiency that compounds poorly over time

Speed is part of the conversion rate optimization conversation. It belongs in the same planning process as your creative, your targeting, and your offer—which is something we build for directly in Wonderflow's marketing flow planning tools.

Want us to run the same teardown on your page?

If you think your landing page speed is leaking conversions, we can do the same LCP breakdown and prioritized fix plan we ran here—focused on what actually moves conversion rate, not just what looks good in a score report.

Send us:

• Your landing page URL
• Your primary conversion goal (form submit, purchase, call booking)
• Your platform (Webflow, Shopify, WordPress)

We'll tell you bluntly what's most likely causing the delay and the first three fixes we'd make.

Get in touch with the Wonderflow team →

‍