BlogImage Compression

How to Compress Images for Landing Pages

Resize, format, compress, and deliver landing page images for fast Largest Contentful Paint, with hero-image budgets, preload and fetchpriority guidance, and a pre-publish verification checklist.

Updated: July 19, 2026

To compress images for landing pages, resize each file to the largest pixel dimensions it actually displays at, choose WebP or AVIF for the hero and photos, and reduce quality until the file is as small as it can be while still looking clean—then deliver the hero as a real <img> element with eager loading, a fetchpriority="high" hint, and a preload so the browser requests it immediately. Treat figures like "keep the hero under ~200 KB" as practical starting budgets, not platform limits; the right size depends on each image's rendered width, detail, and whether it is the page's Largest Contentful Paint (LCP) element.

Landing pages are different from typical content pages: they are usually built to convert paid or campaign traffic, the hero image is most often the LCP element, and every fraction of a second of load time affects bounce and conversion. Google's Core Web Vitals—LCP, Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS)—remain a ranking signal in 2026, and image weight is the single biggest lever for LCP on a typical landing page. Compressing images here is not just a speed task; it is a conversion and ad-efficiency task.

Key Takeaways

  • The hero is usually the LCP element. Treat it as the most important image on the page: resize it, compress it hard, and deliver it eagerly with fetchpriority="high" and a preload.
  • Use a real <img>, not a CSS background, for the hero. The browser's preload scanner can discover an <img> early; it cannot discover a background image in time, which delays LCP.
  • Resize before you compress. Reducing a 5,000 px source to the display width removes more bytes than any quality slider will on its own.
  • Serve responsive variants with srcset. Mobile should download a small file; desktop retina can fetch a larger one. This is the largest mobile weight saving available.
  • Keep file-size budgets editorial, not absolute. ~100–200 KB for the LCP hero, ≤ 150 KB for supporting images, ≤ 50 KB for thumbnails. Adjust by rendered size and detail.
  • Reserve dimensions to prevent CLS. Set explicit width and height (or aspect-ratio) so the browser allocates space before the image loads.
  • Verify on the published page, not the builder preview. Open DevTools → Network and PageSpeed Insights after publishing to see real transferred size and LCP timing.

Why Landing Page Images Need Different Treatment

On a blog or documentation page, images are supporting content. On a landing page, the hero image is often the first thing a visitor—and the browser—tries to paint, which makes it the LCP element. That changes the optimization priority: the hero must be small, discovered early, and requested with high priority. Landing pages also tend to receive mobile and paid traffic, where slower networks make heavy images far more costly, and where load time has a direct line to conversion and ad cost.

Image role on a landing pageTypical positionPriorityWhy it matters
Hero imageAbove the fold, full-bleed or largeHighest — usually the LCP elementDetermines LCP and first visual impression
Product or feature screenshotAbove or below the foldMediumSupports comprehension; lazy-load if below the fold
Logo / iconHeaderHigh (small)Tiny file but renders early; keep it minimal
Founder / team / testimonial avatarsBelow the foldLowLazy-load; small squared sources
Decorative backgroundBehind sectionsLow–mediumShould never be the LCP; keep lean and lazy or purely decorative
Open Graph / social previewOff-pageN/AControls link unfurls, not on-page speed

The practical takeaway: most of your effort should go into the hero, because that single image usually defines the page's LCP and first impression.

Before You Start: Find the LCP Element and Its Rendered Size

Before resizing anything, identify which element is the LCP and how wide it actually renders.

  1. Open the live or preview page in a browser.
  2. Open DevTools → Network, reload, and look for the largest image by transferred size—this is usually your LCP candidate.
  3. Alternatively, run PageSpeed Insights and read the "Largest Contentful Paint element" line directly.
  4. Right-click the image and choose Inspect; note its rendered pixel width at the widest breakpoint where it appears.

That rendered width is your target. Uploading an image wider than this adds bytes without adding visible detail. For the hero, plan to also produce smaller variants for srcset (for example, 640, 1024, and a 2× desktop width).

Step 1: Resize to Display Dimensions

The largest source of avoidable weight is uploading images far wider than they ever render. A hero shown at 1,440 px does not need a 6,000 px source.

  1. Export the hero at the largest rendered width, or up to ~2× that width if you want sharp retina rendering. Use 2× as a starting point, not a rule—test whether the sharpness justifies the extra weight.
  2. Produce two or three additional width variants for srcset (e.g., a mobile width and a mid-size width) so phones download less.
  3. For supporting images and avatars, size each one to the largest width it occupies in the layout.
  4. Resize first, then compress. Shrinking a 5,000 px image to 1,600 px before quality tuning removes more bytes than any quality slider alone.

Step 2: Choose the Right Format

Content typeRecommended formatWhen to use PNGNotes
Hero photographs, product shotsAVIF or WebPNot recommendedOffer a JPEG/WebP fallback via <picture> for older browsers
Logos, icons, simple illustrationsSVG—Best for vector art; file size depends on path complexity
Screenshots, UI capturesWebP (lossy or lossless)When pixel-perfect accuracy is requiredPNG is an option if text legibility suffers at lossy quality
Images needing transparencyWebP with alphaWhen WebP alpha is unacceptable in testingTest both; WebP alpha is widely supported
Decorative texture or gradientCSS gradients where possible—A CSS gradient is lighter than any raster file

WebP vs AVIF for the hero: WebP has near-universal support and is the safe default. AVIF typically produces smaller files at similar quality, which matters most for the LCP hero, but encodes more slowly and is unsupported on a few older browsers. The robust pattern is a <picture> element that offers AVIF first, then WebP, then a fallback.

<picture>
  <source type="image/avif" srcset="hero-1600.avif 1600w, hero-2400.avif 2400w" sizes="100vw">
  <source type="image/webp" srcset="hero-1600.webp 1600w, hero-2400.webp 2400w" sizes="100vw">
  <img src="hero-1600.jpg" srcset="hero-1600.jpg 1600w, hero-2400.jpg 2400w"
       sizes="100vw" width="1600" height="900" alt="…" fetchpriority="high" decoding="async">
</picture>

Step 3: Compress to a Practical Size Budget

Run each resized image through a compression tool and reduce quality until it looks clean at its display size. Landing-page starting budgets:

Image roleStarting budgetHow to judge quality
LCP hero image≤ 200 KB (closer to ~100 KB when possible)Check skin tones and fine detail at full hero size; compare with the original
Supporting screenshot≤ 150 KBCheck text legibility and edges at 1:1 zoom
Logo / icon≤ 50 KBCheck crispness at the rendered size
Avatar / thumbnail≤ 50 KBCheck sharpness at the small rendered size
Decorative background≤ 150 KBSlightly softer is acceptable at background opacity

These are editorial budgets to start from, not platform limits. Adjust upward if an image needs higher quality to look right, or downward if it is simple and can go smaller. For the hero, push toward the smaller end—every kilobyte you remove from the LCP image directly improves LCP on mobile.

Quality check method: Zoom to 1:1 (100%) and inspect text edges, fine lines, gradients, and faces or skin tones. Compression artifacts appear first in high-frequency areas. Stop reducing quality when degradation becomes noticeable at the image's normal display size.

Compression Tool Options

ToolTypeGood for
Squoosh (squoosh.app)BrowserSingle images; side-by-side codec comparison
Squoosh CLICLI / NodeScripted or build-pipeline batch processing
sharpNode libraryProgrammatic pipelines; fast batch processing and variant generation
ImageOptim (macOS)DesktopDrag-and-drop batch; metadata stripping
TinyPNG / TinyJPGWebPNG and JPEG optimization with a simple interface
LessMB (lessmb.com)BrowserBrowser-based compression before uploading to your landing page builder

For a browser-based compression step, you can use LessMB at https://lessmb.com before uploading the optimized file to your builder. If you build landing pages from code, sharp or the Squoosh CLI can generate the responsive srcset variants for you as part of the build.

Step 4: Deliver the Hero for Fast LCP

This is the step that distinguishes landing-page image work from ordinary compression. The hero is usually the LCP element, so how you mark it up decides how fast it paints.

  1. Use a real <img> element, not a CSS background image. The browser's preload scanner reads HTML and can request an <img> before the stylesheet and layout are finished. It cannot discover a background-image until CSS is parsed and the element is laid out, which delays the request and worsens LCP. Reserve background images for purely decorative layers.
  2. Load the hero eagerly. Leave loading at its default (eager)—do not lazy-load the LCP image. Lazy-loading the hero delays the single most important paint.
  3. Add fetchpriority="high" to the hero <img>. This tells the browser to fetch the LCP image ahead of other, lower-priority resources.
  4. Add a preload hint in the document <head> so the browser starts the request as early as possible: 
    <link rel="preload" as="image" href="hero-1600.webp"
      imagesrcset="hero-1600.webp 1600w, hero-2400.webp 2400w"
      imagesizes="100vw" fetchpriority="high">
    Match the imagesrcset/imagesizes to the responsive variants the <img> actually uses, and preload only one image—the LCP—to avoid wasting bandwidth.
  5. Set explicit width and height (or aspect-ratio) on every image so the browser reserves space before it loads. Omitting dimensions causes layout shift (CLS) even when the file is small.
  6. Serve via a CDN so the hero is cached close to the visitor. Most landing-page builders do this automatically; if you self-host, put a CDN in front of the image origin.

Step 5: Handle Below-the-Fold Images and Lazy Loading

Everything that is not above the fold on first paint should be deferred so it does not compete with the hero.

  1. Add loading="lazy" and decoding="async" to supporting screenshots, avatars, and any decorative image below the fold.
  2. Keep logos and small header images eager if they are part of the initial visual—otherwise lazy-load them.
  3. Confirm with DevTools → Network that below-the-fold images are requested only after the hero has loaded, not during the initial waterfall.

How to Verify What the Landing Page Actually Delivers

Compression is only meaningful if you verify it on the published page, not in the builder preview.

  1. Publish the page and open it in a browser.
  2. Open DevTools → Network, filter by Img, and reload.
  3. For each image, check:
    • Transferred size: the actual bytes sent over the network—the number that matters for page weight.
    • Content-Type: should be image/avif or image/webp where your conversion is active.
    • Priority / Initiator: confirm the hero is requested early and is not waiting on CSS or JavaScript.
  4. Sort by Transferred size and review anything above budget.
  5. Run PageSpeed Insights (pagespeed.web.dev) and check:
    • The LCP element and its load time—this is the headline number for a landing page.
    • CLS—should be near zero if you set dimensions.
    • INP—images rarely affect INP directly, but heavy JavaScript that blocks interaction often accompanies image-heavy pages.
    • Opportunities flagged as "Properly size images," "Serve images in next-gen formats," or "Preload key requests."
  6. Re-run the audit on a mobile throttling profile. Slow networks expose oversize heroes that look acceptable on a fast desktop connection.

Why the Hero Might Still Be Slow After Compression

If DevTools shows a slow LCP or a large hero after compression, common causes include:

  • The hero is a CSS background image. The preload scanner cannot see it. Replace it with a real <img> with fetchpriority="high".
  • No preload hint. The browser discovers the hero only after parsing CSS and laying out the page. Add a <link rel="preload" as="image"> for the LCP image.
  • The image was compressed but not resized first. A 4,000 px WebP at high quality is still large. Resize to the display width, then compress.
  • The browser is serving an oversized responsive variant. Check the actual URL in DevTools to see which srcset variant was delivered to your device.
  • The hero is lazy-loaded. Remove loading="lazy" from the LCP image.
  • The image is served from a slow origin without a CDN. Check the timing breakdown in DevTools; the request may spend most of its time waiting (TTFB) rather than downloading.
  • The browser cached the old version. Hard-reload with Cmd + Shift + R (Mac) or Ctrl + Shift + R (Windows) to bypass cache.

Pre-Publish Checklist

Before upload

  • Identified the LCP element (usually the hero) and measured its rendered width
  • Resized the source to that width (up to ~2× for the hero, tested)
  • Produced responsive srcset variants for the hero
  • Chose the appropriate format (AVIF or WebP for photos, SVG for vectors)
  • Compressed to a starting budget and checked visual quality at 1:1 zoom
  • Confirmed no visible artifacts on text, edges, gradients, or faces
  • Stripped metadata if the tool supports it
  • Prepared concise, descriptive alt text

After publish

  • Opened DevTools → Network → Img and reloaded the page
  • Confirmed transferred sizes are within budget
  • Confirmed content-type is image/avif or image/webp where expected
  • Confirmed the hero is an <img>, eager, with fetchpriority="high"
  • Confirmed a preload hint exists for the LCP image
  • Confirmed width/height are set (CLS near zero)
  • Ran PageSpeed Insights and reviewed LCP, CLS, and INP
  • Re-tested on a mobile throttling profile

Common Mistakes That Undermine Landing Page Compression

  • Using a CSS background image for the hero. The preload scanner cannot discover it in time. This is the most common reason a landing page LCP underperforms.
  • Lazy-loading the LCP image. This delays the most important paint on the page. The hero should load eagerly.
  • Omitting width and height. Without reserved dimensions, images cause layout shift (CLS) as they load.
  • Uploading at the original camera or export resolution. A hero captured at 6,000 px and displayed at 1,440 px wastes the overwhelming majority of its pixels. Resize first.
  • Treating file-size targets as platform limits. 200 KB is a starting budget. A simple hero may be fine at 80 KB; a detail-rich product shot may need more.
  • Serving one desktop-size file to every device. Without srcset, mobile downloads the full-resolution hero. Provide responsive variants.
  • Preloading too many images. Preload only the LCP image; preloading everything wastes bandwidth and competes with the hero.
  • Checking only the builder preview. The preview does not show real delivered file size or LCP timing. Always verify with DevTools and PageSpeed Insights on the published page.

Next Step

Audit one live landing page: open DevTools → Network → Img, sort by transferred size, and run PageSpeed Insights to read the LCP element. If the LCP is a hero image, re-export it from the original source, resize to the display width, generate responsive srcset variants, convert to AVIF or WebP, and deliver it as an <img> with fetchpriority="high" and a preload. Publish and re-run PageSpeed Insights to measure the LCP change—then repeat for the next heaviest image.

FAQ

What is the best image size for a landing page hero?

Export the hero at roughly 2× the largest width it renders at, then serve it responsively with srcset so browsers pick a smaller variant on mobile. As a practical file-size budget—not a platform limit—aim to keep the LCP hero under ~200 KB, and closer to ~100 KB when you can, because the smaller it is, the faster the hero paints on mobile networks.

How do I make my landing page hero image load faster?

Resize the source to its display dimensions, convert it to WebP or AVIF, compress it to the smallest size that still looks clean, then mark it as eager loading with fetchpriority="high" and preload it with a <link rel="preload" as="image"> hint. Use a real <img> rather than a CSS background, because the preload scanner discovers an <img> hero earlier, which improves LCP.

Should I lazy-load images on a landing page?

Lazy-load only images below the visible viewport on first paint—supporting screenshots, lower logos, and testimonial avatars. Never lazy-load the LCP element, which on a landing page is usually the hero. Lazy-loading the LCP image delays the most important paint and typically worsens LCP and conversion.

What image format is best for landing pages?

AVIF or WebP for photographs and complex hero imagery (offer a fallback through a <picture> element), SVG for logos, icons, and simple illustrations, and PNG only when you need lossless precision or transparency that WebP does not handle acceptably. WebP is the safe default; AVIF is usually smaller at similar quality.

Why does my landing page hero load slowly even after compression?

Common causes include rendering the hero as a CSS background instead of an <img>, omitting a preload hint, serving an oversized responsive variant, leaving it lazy-loaded, hosting it without a CDN, or compressing without resizing first. Inspect the request in DevTools → Network and check the LCP element and its timing in PageSpeed Insights.

How does image weight affect landing page conversion?

Faster pages convert better. Studies from Google, SOASTA, and Deloitte have found a measurable relationship between page-load time and conversion or bounce rate, and landing pages are especially sensitive because paid traffic magnifies the cost of every second of delay. Shrinking the LCP hero is high-leverage because it improves both first paint and total page weight.

How do I prevent images from shifting layout on a landing page?

Set explicit width and height (or aspect-ratio) on every image so the browser reserves space before the file loads. Without reserved dimensions, images cause cumulative layout shift (CLS) as they appear, which hurts Core Web Vitals and makes the page feel unstable.

Should I use responsive images (srcset) on a landing page?

Yes. A responsive hero with srcset and sizes lets a phone download a small variant while a desktop retina screen fetches a larger one. This is one of the largest weight savings available on mobile, where the same hero otherwise downloads at full desktop resolution. Provide at least two or three width variants and let the browser choose.

Should I compress images before uploading them to my landing page builder?

Yes. Compressing and resizing before upload gives you the most control over what gets served. Builders such as Unbounce, Instapage, Webflow, and Framer optimize what you give them—some convert to WebP and serve CDN variants, others do less—so a smaller, well-sized source leads to faster delivery. Verify the final served size in DevTools, not the source file size.

Will compressing an image twice reduce its quality?

Repeated lossy compression accumulates quality loss. Compress from the original source file each time, and keep your uncompressed originals in a safe location so you can re-export at any quality level as needed.

Sources