Largest Contentful Paint Images: Convert, Resize, or Preload?

When a page has a slow Largest Contentful Paint, image work often becomes the first suspect. That is reasonable: hero images, product photos, and article covers are common LCP candidates. But the right fix is not always the same. Sometimes the image should be converted to WebP. Sometimes it should be resized. Sometimes the browser needs to discover it earlier. Sometimes the real bottleneck is server response time or JavaScript.

The review question is not "Should we optimize images?" It is "Which part of this image's loading path is actually slow?"

"Convert the LCP image to WebP" can be right, but it can also miss the real bottleneck. LCP image work needs a before-and-after record that separates server delay, resource discovery, transfer size, image dimensions, decode/render behavior, and visual approval.

Confirm the LCP Element#

Start by confirming which element is counted as LCP. Google's LCP documentation explains how the metric represents the render time of the largest visible content element in the viewport. On many marketing and ecommerce pages, that element is an image. On other pages, it may be a heading, poster frame, or block of text.

Do not optimize the wrong file. If a page has a large below-the-fold gallery but the LCP element is a text heading, gallery conversion may reduce total page weight without moving the measured LCP.

Use browser DevTools, PageSpeed Insights, or a trace to identify the actual candidate before changing assets.

Write down the candidate before editing files:

Page: /pricing/
Measured LCP element: hero image
LCP URL: /images/pricing-hero.jpg
Rendered size: 760 x 430 on tested mobile viewport
Intrinsic size served: 1800 x 1020
Discovery: initial HTML, not JavaScript
Lazy loading: no
Main issue suspected: oversized candidate and transfer size

This prevents the team from optimizing a nearby image that does not define the metric.

Convert When Bytes Are the Problem#

Convert the LCP image when the current file is larger than it needs to be for its visual role. A photographic JPEG hero, a large PNG banner, or an uncompressed export may be a strong candidate for WebP.

Review these signals:

• the image is downloaded early enough, but transfer takes too long
• the displayed quality can survive WebP compression
• the original dimensions are already close to the displayed dimensions
• the image is served repeatedly across important pages

Conversion is strongest when it reduces transfer cost while preserving the look users need. If a product hero needs visible fabric texture or fine detail, compare the output at the same zoom level used by shoppers, not only in a tiny preview.

For a controlled conversion trial, keep the generated files separate:

npx -y getwebp ./lcp-source -o ./lcp-candidates --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 is the right workflow for LCP testing because an image can pass byte review and still fail crop, text, or product-quality review.

Resize When Dimensions Are the Problem#

If a 2400-pixel image is displayed at 900 pixels on desktop and 390 pixels on mobile, format conversion alone leaves waste in the pipeline. A smaller WebP is still oversized if the browser receives far more pixels than it can display.

Responsive images are often the better first fix. MDN's responsive images guide explains the role of srcset, sizes, and art direction. The practical goal is simple: the browser should be able to choose a source close to the user's viewport and pixel density.

For LCP images, document:

• source dimensions
• rendered dimensions
• chosen candidate in DevTools
• desktop and mobile behavior
• whether the CMS creates extra sizes

If the browser consistently chooses a much larger image than necessary, resizing and responsive markup may beat another compression pass.

Use a sizing table:

This table makes it clear whether the fix is compression, candidate generation, or sizes correction.

Preload When Discovery Is Late#

Preloading can help when the browser discovers the LCP image too late. This can happen when the image is introduced by late JavaScript, buried in CSS, swapped by a framework, or hidden behind a component that renders after other work.

Preload is not a general image-speed setting. It asks the browser to prioritize a specific resource earlier. Used on the wrong file, it can compete with more important work. Used on too many files, it creates noise.

Consider preload only after confirming:

• the image is the measured LCP candidate
• it is required above the fold
• it is discovered late in the waterfall
• the URL and responsive behavior are stable enough to target
• the page is not already network-saturated by other critical assets

For many sites, improving HTML discovery or removing unnecessary lazy loading on the primary hero is cleaner than adding preload.

Preload review should be specific:

Preload considered: yes
Reason: LCP URL discovered only after CSS background was parsed
Target URL stable across mobile/desktop: no
Action: move hero into HTML picture element instead of preloading one desktop URL
Result to re-measure: resource start time and selected candidate

Do not add preload as a ritual. It is only useful when the measured problem is late discovery and the target resource is stable enough to prioritize.

Check Lazy Loading Carefully#

Lazy loading is useful for below-the-fold images, but it can hurt if applied to the LCP image. A hero image visible on initial load should usually not wait for lazy-loading heuristics.

Review templates and CMS output. Some image components apply lazy loading by default to every image. That default may be fine for cards and galleries, but not for the primary visual element at the top of the page.

If you change lazy loading, measure again. The goal is not to remove lazy loading everywhere. The goal is to avoid delaying the one image that defines the initial view.

For WordPress sites, inspect rendered output because plugins and themes can add image attributes after the editor saves content. GetWebP's Frontend Delivery docs note that delivery rewrites src and srcset while preserving attributes such as loading, width, and height. Confirm that the LCP image is not lazily delayed, that dimensions remain present, and that the optimized source is the one selected in the browser.

Use a Simple Decision Order#

A practical order looks like this:

1. Confirm the LCP element.
2. Check whether the image is discovered early.
3. Check whether the served dimensions match the rendered size.
4. Convert or compress only after the sizing problem is understood.
5. Consider preload only when measurement shows late discovery.

This order keeps the team from treating every LCP problem as a compression problem.

Add a result record after each change:

Change 1: added 960w and 1280w WebP candidates
Measured effect: mobile selected 960w instead of 1800w
Visual review: pass
Remaining issue: resource still starts after CSS

Change 2: moved hero source into initial HTML
Measured effect: resource start moved earlier in waterfall
Remaining issue: server response time unchanged

This avoids giving image conversion credit for unrelated fixes, and it keeps future performance work honest.

Report the Fix Honestly#

A strong before-and-after note might say: "The LCP image was 1800 pixels wide but rendered at 760 pixels on the tested mobile viewport. We added a smaller responsive candidate and converted that candidate to WebP. Transfer size dropped by 210 KB. The image remains visually approved at product-detail zoom."

That statement is specific. It gives credit to resizing and conversion separately, and it leaves room for further LCP work if server timing or render blocking remains.

If conversion used --json, keep the structured output with the performance note. GetWebP's JSON output reference documents newline-delimited events and per-file fields including outputPath, originalSize, newSize, savedRatio, quality, qualityMode, and status.

Example evidence:

LCP image fix - 2025-12-21
File: pricing-hero.jpg
Generated: pricing-hero-960.webp, pricing-hero-1280.webp
Conversion status: success
Savings: recorded from JSON output
Rendered selection: 960w on mobile, 1280w on laptop
Discovery: initial HTML picture element
Lazy loading: removed from LCP image only
Visual approval: product color and headline contrast pass
Remaining non-image issue: server response time still high

That is the level of specificity that separates evidence-based guidance from generic performance advice.

For LCP images, the best result usually comes from combining the right file size, the right dimensions, and the right discovery timing. WebP conversion is a useful tool inside that review, not a substitute for it.