Optimizing landing page images: formats, weight, and load order

On most landing pages, images account for the bulk of the downloaded weight: more than the HTML, CSS, and JavaScript combined. They're also where you gain the most, fastest — a badly exported image takes minutes to fix. We've covered loading speed as a whole elsewhere; this article is about images only, but in depth.

Why image weight decides how fast a page feels

A landing page rarely holds more than a few hundred lines of text, but it often carries a full-width hero photo, three product screenshots, a logo grid, and a row of testimonial portraits. And the largest of those images is, almost always, the element that triggers the LCP (Largest Contentful Paint) measurement. Optimizing images isn't about shaving kilobytes on principle, then: it's about acting on the metric Google uses to judge the page, and on the moment the visitor finally sees your promise.

The patience budget is short. A study by Fiona Nah published in 2004 in Behaviour & Information Technology measured users' "tolerable waiting time" for retrieving information: it sits at around 2 seconds, and visual feedback during loading noticeably extends that tolerance (study on Google Scholar). Two seconds is roughly what a single photo exported straight out of a camera takes to arrive over an average mobile connection.

Choosing the right format: the decision table

The first question isn't "how do I compress this" but "which format." A bad format condemns an image to stay heavy no matter what you do afterward: a PNG used for a photograph starts with a handicap no tool will make up for.

At equivalent perceived quality, WebP and AVIF produce lighter files than the JPEG and PNG they succeed — that's their entire reason for existing, and the actual gain depends on each image. The practical rule fits in three lines: vector goes to SVG (a logo in PNG is almost always a mistake), photographic goes to WebP, and the rare images that stay heavy go to AVIF, served through a <picture> tag with a JPEG fallback. One last reflex: to show an interface in motion, a muted looping MP4 weighs far less than the equivalent GIF.

Sizing to the dimensions actually displayed

This is the most common waste and the easiest to fix: a 4,000-pixel-wide photo served into a block that's 600 pixels across. The browser downloads the entire file, then shrinks it — the visitor pays full weight for detail they'll never see. Resize every image to the maximum width at which it's actually displayed, high-density screens included (multiply by two, rarely more). But the same visual isn't the same size on mobile and on a large screen: that's what srcset and sizes are for.

• srcset lists the variants with their real widths (hero-640.webp 640w, hero-1280.webp 1280w, hero-1920.webp 1920w).
• sizes describes the expected display width per context ((max-width: 768px) 100vw, 640px), so the browser can decide before it has even read the CSS.
• Three or four variants are enough; generating ten complicates maintenance with no measurable benefit.
• A decorative banner often gains from being re-cropped for mobile rather than shrunk: a dedicated vertical crop weighs less and reads better.

The point is decisive because most paid traffic arrives on mobile, as we detail in our article on mobile-first design: serving a phone on 4G an image designed for a 27-inch monitor means charging the most constrained visitor the heaviest version.

Compression: lossy or lossless

Lossless compression reduces file weight without altering a single pixel: it suits logos, pictograms, and screenshots, where the slightest blur on text shows. Lossy compression discards information the eye barely perceives; that's what produces the real gains on photographs. A quality setting between 75 and 85 is the usual starting point in WebP or JPEG, but the right method isn't to memorize a number: compare the original against the compressed version at display size, and go down to just before the difference becomes visible.

• Strip metadata (EXIF, GPS data, full color profiles): it adds nothing on the web and bloats every file coming out of a camera.
• Clean up SVGs exported from design tools: hidden layers and editor metadata often multiply their size.
• Automate rather than compressing by hand: a build-time script guarantees nobody skips the step.
• Never recompress an already-compressed file: always start from the original, or you'll stack artifacts.

The three attributes that decide the first screen

Once format and weight are handled, what's left is telling the browser when and in what order to download. That's where most of the points lost on PageSpeed Insights are decided.

loading="lazy": essential below the fold, forbidden on the hero

loading="lazy" tells the browser to download an image only as it approaches the visible area: a clear win for testimonials, secondary screenshots, and footer logos. Applied to the hero, it produces the exact opposite effect — the browser waits until it has computed layout to decide the image is visible, and only then starts the download. You're adding a round trip to the very element that determines your LCP. The rule has no exceptions: never lazy-load anything visible without scrolling. Themes that enable it "on all images" with a single toggle are a frequent cause of a degraded LCP.

width and height: the fix for layout shift

An image with no declared dimensions occupies zero height until it loads, then abruptly shoves everything below it down the page. That's the leading cause of CLS (Cumulative Layout Shift) on a landing page, and the most infuriating one: the button you were about to tap moves at the moment of the click. Always fill in width and height with the file's real dimensions — even if CSS resizes it afterward, the browser infers the aspect ratio and reserves the right space from the very first paint.

fetchpriority="high": jumping the queue

By default the browser discovers images as it walks the HTML and treats them with moderate priority, behind CSS and certain scripts. fetchpriority="high" on the hero image tells it that this particular file goes to the front of the line. Use the attribute once per page: if everything is a priority, nothing is. Combined with no lazy loading and a modern format, it's often what pushes an LCP to the right side of the 2.5-second threshold.

The special cases that escape the rules

CSS background images are discovered late: the browser has to parse the stylesheet before it understands it needs the file. That doesn't matter for a decorative banner low on the page; it's a structural handicap for the hero, since a background-image accepts neither srcset, nor fetchpriority, nor width. Move back to an <img> tag positioned behind the content, or preload the file with a <link rel="preload" as="image">.

Interface screenshots contain fine text, crisp borders, and flat areas: exactly what lossy compression degrades first. Capture at final resolution rather than shrinking a Retina grab, crop to what matters, and check legibility on a phone. Our article on the hero image covers when a screenshot is the right call versus a photo.

Portrait photos, finally, are the most numerous and the worst handled: displayed in a 48-to-96-pixel circle, but loaded as 1,500-pixel files straight from a photo shoot. Ten avatars treated that way can outweigh the hero. Resize, convert to WebP, and defer the ones in the testimonials section. Also spare a thought for the sharing image, which follows different constraints — see our article on the Open Graph image.

Diagnosing and prioritizing: the method

Order matters as much as technique: handling what weighs on the first screen first produces visible results where the other fixes show up nowhere.

1. Open the Network tab in DevTools, filter on "Img," reload with the cache cleared, and sort by descending size: in thirty seconds you have your culprits ranked by severity.
2. Compare file size to display size: the inspector shows intrinsic and rendered dimensions on hover. A gap of three times or more flags a resize to do.
3. Run PageSpeed Insights in mobile mode and read the "Opportunities" section: it names the images to convert, resize, or defer, and identifies the LCP element on a screenshot.
4. Fix the LCP element first: right format, right size, no lazy loading, fetchpriority="high". One single image, and the best effort-to-result ratio on the list.
5. Then take the ten heaviest images on the rest of the page, enabling lazy loading on everything below the fold.
6. Re-measure in real conditions, on a phone over 4G rather than office wifi, checking that the CLS score hasn't moved.

This work has a commercial payoff. A study by Wojciech Stadnik and Ziemowit Nowak, published in 2018 in the proceedings of the ISAT conference, tracked the real behavior of an online store's visitors and concluded that average page load time has a direct effect on the conversion rate and on measured customer satisfaction (study on Google Scholar). The kilobytes you save don't stay inside the technical report: they come back out in the number of forms submitted.

That said, all of this can be automated. Next.js's next/image component generates the size variants, serves WebP or AVIF depending on what the browser accepts, enforces width and height (so it protects against CLS by construction), and enables lazy loading by default — with the priority prop to exempt the hero from it. That's one of the reasons behind the gap measured in our Next.js versus WordPress comparison, and the setup is detailed in our article on deploying a Next.js landing page on Vercel.

It's also the stance behind the LanderKit templates: images already sized, converted, and prioritized, hero excluded from deferred loading, dimensions declared everywhere. On a page like our product e-commerce template, where the visual is the main selling argument, that removes the usual trade-off between a visually rich page and a fast one. The goal isn't the lightest page possible, but the one that shows what sells it the fastest.