Image Optimization for Landing Pages: Why Your Hero Image Is Killing Your Conversions
Your landing page hero image looks incredible in Figma. But if it takes 4 seconds to load, visitors are gone before they ever see it. Here's how to fix that without sacrificing a single pixel of quality.
TinyImage Team
Lead Architect
June 3, 2026
Published
7 min
Read time
Topics
Table of Contents
Image Optimization for Landing Pages: Why Your Hero Image Is Killing Your Conversions
I'm going to start with something that might sting a little.
That gorgeous hero image on your landing page—the one your designer spent two weeks perfecting—is probably costing you money right now. Not because it looks bad. Because it's too heavy, and your visitors are bouncing before they ever see it.
Here's a stat that changed how I think about landing pages forever: a 1-second delay in page load time reduces conversions by roughly 7%. And the single biggest contributor to that delay, nine times out of ten, is a bloated hero image sitting above the fold.
A Real Story, Real Numbers
Last quarter, I audited a SaaS startup's paid landing page. Their designer had exported a beautiful 4K PNG from Figma—3840px wide, crystal sharp. The developer dropped it in. Everyone was happy with how it looked.
The problem? The image was 2.8MB. On a typical 4G mobile connection, it took 4.2 seconds to load. Their bounce rate sat at 62%. For a company spending $15,000/month on Google Ads at $5 CPC, that meant roughly 1,860 visitors per month were leaving before the page even rendered.
We changed exactly one thing: the image pipeline. Same design, same ad copy, same targeting.
The results:
| Metric | Before | After |
|---|---|---|
| Hero image size | 2.8MB PNG | 210KB AVIF |
| LCP (Largest Contentful Paint) | 4.2 sec | 1.1 sec |
| Bounce rate | 62% | 38% |
| Conversion rate | 2.1% | 3.4% |
| Additional monthly revenue | — | ~$12,000 |
Nobody tweeted about their hero image being 210KB. But their revenue dashboard noticed.
Takeaway #1: Before you A/B test headlines, colors, or CTAs, check your hero image size. It might be the single highest-ROI fix available to you.
The Format Decision That Matters Most
If your hero is a photograph (which it usually is), you have three real options in 2026. But they're not interchangeable.
AVIF is your primary format. It delivers dramatically smaller files than JPEG at the same visual quality—we're talking files that are a fraction of the original. All major browsers support it now. If you're building a landing page in 2026 and not using AVIF, you're leaving performance on the table.
WebP is your fallback for older browsers. It's still a significant upgrade over JPEG and has near-universal support.
JPEG is your last resort—the "I need this to work literally everywhere including email clients from 2015" option.
Here's the pattern you should be using:
<picture>
<source srcset="/hero.avif" type="image/avif" />
<source srcset="/hero.webp" type="image/webp" />
<img
src="/hero.jpg"
alt="Product hero shot"
width="1200"
height="630"
fetchpriority="high"
decoding="async"
/>
</picture>
Six lines of HTML. That's it. Six lines between a fast landing page and a slow one.
Takeaway #2: The
<picture>element with an AVIF → WebP → JPEG fallback chain is the baseline for any landing page built today.
The Lazy-Loading Trap (This One Catches Experienced Devs)
If you've read any performance guide in the last five years, you've absorbed the mantra: lazy-load your images. And that's excellent advice—for everything below the fold.
But your hero image IS the fold. Adding loading="lazy" to it tells the browser: "Don't prioritize this. Wait until the user scrolls near it." Since the hero is already visible, the browser delays fetching it for no good reason. I've measured this adding 300-800ms to LCP—an eternity on a landing page where every millisecond directly correlates with revenue.
Do the opposite. Tell the browser this image is the most important thing on the page:
<img
src="/hero.avif"
alt="Product hero shot"
width="1200"
height="630"
fetchpriority="high"
/>
And for an extra edge, preload it in your <head> so the browser starts fetching before it even parses the body:
<link
rel="preload"
as="image"
type="image/avif"
href="/hero.avif"
fetchpriority="high"
/>
This can shave 200-400ms off your LCP. On a landing page, that's not a micro-optimization—that's real money.
Takeaway #3:
loading="lazy"on a hero image is one of the most common LCP mistakes on the web. Usefetchpriority="high"instead. Reserve lazy loading exclusively for below-the-fold content.
Dimensions: The Grand Piano Problem
Here's a metaphor I keep coming back to: serving a 3840px-wide hero to a phone with a 400px viewport is like shipping a grand piano when someone ordered a keyboard. Same notes, comically wasteful delivery.
Your landing page probably has a max-width around 1200px. On a 2x Retina screen, the sharpest you'll ever need is 2400px. On a standard screen, 1200px does the job. On mobile? 800px is plenty.
Use srcset so the browser picks the right size automatically:
<img
srcset="/hero-800.avif 800w, /hero-1200.avif 1200w, /hero-2400.avif 2400w"
sizes="(max-width: 768px) 100vw, 1200px"
src="/hero-1200.avif"
alt="Product hero shot"
width="1200"
height="630"
fetchpriority="high"
/>
On mobile—which is where most paid landing page traffic comes from—this can eliminate the majority of unnecessary bytes. That's the difference between a 3-second load and a sub-1-second load.
Takeaway #4: Never serve an image wider than 2x the container's CSS width. Use
srcsetto let the browser choose the right size per device.
The Quality Anxiety That's Holding You Back
People get nervous about compression. "Won't it make my hero look blurry?"
Here's why the answer is almost always no: your hero image is viewed by users who are scanning a page in 2-3 seconds, at normal screen distance, while deciding whether to keep reading. They're not zooming in at 400% in Photoshop. You have significantly more compression headroom than your gut tells you.
For hero images specifically:
- AVIF at quality 65-75 is the sweet spot. At 70%, the difference from the uncompressed original is imperceptible at normal viewing distance.
- WebP at quality 75-80 needs a bit more headroom because the codec is less efficient.
- JPEG at quality 80-85 is the floor if you're stuck with the legacy format.
If you want to see the difference (or lack thereof) before committing, drop your hero into TinyImage and use the side-by-side slider. It runs entirely in your browser—nothing gets uploaded.
Takeaway #5: Compression anxiety is the biggest psychological barrier to fast landing pages. AVIF at quality 70 is visually indistinguishable from the original for 99% of hero images.
Calculate Your Own Dollar Impact
Here's a framework to estimate what a slow hero image is costing your business specifically:
- Monthly ad spend ÷ CPC = Total clicks
- Total clicks × current bounce rate = Bounced visitors
- Estimate that 40% of bounces are speed-related (conservative)
- Speed-related bounces × your conversion rate = Lost conversions
- Lost conversions × average deal value = Money left on the table
Run those numbers with your own data. The result usually makes people immediately open DevTools and check their hero image size.
The Pre-Ship Checklist
Before you push your next landing page live:
- Hero is AVIF with WebP and JPEG fallbacks via
<picture> - Max dimension is 2400px (not 3840px "just in case")
- AVIF quality is between 65-75
-
fetchpriority="high"is on the hero tag -
loading="lazy"is NOT on the hero image - Hero is preloaded in
<head>for best LCP - Below-the-fold images use
loading="lazy" - All
<img>tags have explicitwidthandheight(prevents layout shift)
Eight items. Ten minutes of work. Potentially thousands of dollars in recovered conversions every single month.
Deploy Visual Excellence
Put what you've learned into practice with TinyImage.Online - the free, privacy-focused image compression tool that works entirely in your browser.
