Hero Images: A Practical WebP Delivery Checklist

Hero images carry a lot of responsibility. They are often the first visual asset a visitor sees, the most expensive image on the page, and a likely Largest Contentful Paint candidate. Converting a hero image to WebP can be valuable, but the delivery details decide whether the change is actually good.

A hero-image review should cover visual quality, dimensions, format fallback, discovery, priority, and layout stability. Skipping any of those can turn a good compression result into a poor page experience.

"Convert the hero to WebP to improve LCP" leaves out the delivery checks that decide the result. A hero image can be smaller and still hurt the page if it is discovered late, cropped poorly, lazy-loaded, served with a stale fallback, or selected at the wrong responsive size.

Confirm the Hero's Real Job#

Before converting, define what the image needs to do. A homepage hero may set brand tone. A product hero may need accurate material, color, and texture. A SaaS hero screenshot may need crisp UI text. A campaign hero may contain legal or promotional details that cannot blur.

This matters because acceptable compression varies by use case. A background lifestyle photo may tolerate more loss than a product close-up. A screenshot with small text may need different settings than a photographic banner.

Write the acceptance criteria in plain language before exporting:

• important text remains readable
• product color is not visibly shifted
• fine texture still looks natural
• no obvious banding appears in gradients
• no halo appears around sharp edges

That turns review into a repeatable decision instead of a personal preference debate.

Use a role-specific note:

Hero: homepage Q1 campaign
Job: communicate product positioning and legal offer
Must preserve: headline contrast, product color, offer badge text, mobile subject crop
Can trade off: background texture in outer crop area
Reviewer: growth owner + designer

This gives the image a business context before anyone argues about compression percentage.

Export More Than One Width#

A single oversized hero file is rarely efficient. Desktop, tablet, and mobile viewports need different pixel counts. WebP reduces bytes, but it does not remove the cost of delivering unnecessary pixels.

Use responsive image markup where possible. MDN's responsive images guide explains how srcset and sizes let the browser choose an appropriate candidate.

For a normal marketing hero, a team might prepare several widths such as 640, 960, 1280, and 1600 pixels. The exact set depends on the design, image crop, device mix, and CMS behavior. The important part is to test what the browser actually selects.

For a local conversion pass, write generated files to a publishable output folder:

npx -y getwebp ./hero-source -o ./public/hero-images --recursive --format webp --json

The GetWebP CLI commands reference documents --output, --recursive, --format, and --json, and states that original files are never modified or deleted. That matters for hero work because rejected crops and conversion trials should not overwrite the design-approved source.

Preserve Layout Space#

Hero images can cause layout shifts if the page does not reserve space before the file loads. Converting to WebP does not solve that by itself. The template still needs stable dimensions, aspect ratio handling, and predictable cropping.

Review the rendered page with a slow network profile. The hero area should not jump as the image arrives. If the design uses art direction with different crops on mobile and desktop, each crop needs clear dimensions.

CSS can help, but do not rely on the final image download to define the initial layout. A fast file can still arrive after the browser has already painted a shifting layout.

Record the layout contract:

Hero slot
Desktop aspect ratio: 16:7
Mobile aspect ratio: 4:5
HTML dimensions present: yes
CSS object-fit/object-position checked: yes
Slow-network layout shift: no visible jump
Overlay text collision: none at 360px, 390px, 768px, 1440px

This keeps layout stability tied to the rendered component, not only the image file.

Check Browser Discovery#

The browser cannot download a hero image early if it discovers the URL late. Hero images placed directly in initial HTML are usually easier to discover than images injected after client-side rendering. Background images in CSS can be valid, but they need more careful inspection.

Google's optimize LCP guide discusses the importance of reducing delay before the LCP resource starts loading. For hero images, that means checking the request waterfall, not just final file size.

Look for these issues:

• the image URL appears only after JavaScript executes
• the hero image is lazy-loaded even though it is visible
• a placeholder loads first and swaps late
• CSS or script dependencies delay discovery
• the browser downloads a larger fallback before the intended asset

Fixing discovery can be as important as compressing the file.

Add a discovery check to the review:

LCP resource: /hero-images/home-1280.webp
Discovered from: initial HTML picture element
Lazy loaded: no
Preload used: yes, matches selected candidate
Request start: before main client bundle execution
Unexpected downloads: no larger JPEG fallback downloaded first

If the hero is a CSS background image, note that explicitly and test whether the CSS file delays discovery. If the image is injected by JavaScript, the WebP conversion is unlikely to fix the main LCP delay by itself.

Use Fallbacks Deliberately#

Most modern browsers support WebP, but fallback planning still matters in managed sites, embedded views, older systems, and unusual browser environments. A picture element can serve WebP while preserving a JPEG or PNG fallback.

Keep fallback files organized and named clearly. Review both paths. It is common to test only the WebP output and forget that the fallback may be outdated, oversized, or visually different.

A fallback is not just a compatibility artifact. It is part of the page experience for users who receive it.

For WordPress sites, use the rendered page as the source of truth. GetWebP's Frontend Delivery docs describe picture-tag delivery, PHP rewriting, and preservation of attributes such as loading, width, and height. For hero images, verify that the optimized source is actually present in the rendered <picture> or rewritten src, and that the fallback JPEG/PNG remains current.

Header evidence helps too:

curl -sI https://example.com/wp-content/uploads/hero.webp
curl -sI https://example.com/wp-content/uploads/hero.jpg

Record Content-Type, cache status, and whether the hero URL matches what the browser selected.

Review the Crops, Not Only the Files#

Hero images often crop differently across breakpoints. A conversion review should check the rendered crop at common viewport sizes. A compressed file may look good in isolation but fail if the important subject is cropped out on mobile.

Test at least:

• narrow mobile
• large mobile
• tablet
• common laptop width
• wide desktop

If the design overlays text on the image, test contrast after conversion. Compression can change texture and local contrast enough to affect readability.

Use a crop QA matrix:

Do not approve the file from an image viewer alone. Hero quality is a page-level decision.

Keep a Simple Delivery Record#

For each hero, record the source file, exported widths, format settings, fallback path, and review notes. Include the before-and-after byte sizes, but do not make byte savings the only approval criterion.

A useful note might read: "Homepage hero exported at 640, 960, 1280, and 1600 pixels as WebP, with JPEG fallback. Mobile crop checked at 390 pixels wide. Text overlay remains readable. Largest chosen mobile candidate is 960 pixels."

That level of detail makes future changes easier. When a designer updates the hero later, the team can repeat the same process.

If conversion uses --json, keep the machine-readable evidence with the page review. GetWebP's JSON output reference documents newline-delimited output and per-file fields such as outputPath, originalSize, newSize, savedRatio, quality, qualityMode, and status.

A stronger delivery record looks like this:

Hero delivery review - 2025-12-24
Source: design/hero-q1.psd export
Generated WebP widths: 640, 960, 1280, 1600
Fallback: JPEG retained and current
Conversion evidence: 4 success, 0 failed
Rendered selection: 960w mobile, 1280w laptop, 1600w wide desktop
Discovery: initial HTML, not lazy-loaded
Layout: dimensions and aspect ratio stable
Visual: mobile crop pass, text contrast pass
Open issue: social preview uses separate JPG

This avoids the shallow pattern of equating "hero converted" with "hero delivered well."

WebP is a strong fit for many hero images, but delivery quality depends on more than the format. The reliable workflow is to convert, size, test, and document the actual rendered result.