Your product page has loaded its price, reviews, and purchase button. The main photo is still missing. A shopper waits while a 3,000-pixel JPEG downloads into a space barely 400 pixels wide. Then the image appears and pushes the purchase button down. That oversized asset has delayed the page’s largest contentful paint, and its arrival has made the interface harder to use.

Replacing that JPEG with WebP can reduce the download. But the format change is only part of the fix. You also need appropriately sized files, markup that helps the browser choose between them, and reserved space that keeps the layout steady. Here is how to ship those pieces as one coherent change.

Start With the Product Image That Delays the Page

Open the product page with browser developer tools recording a fresh load. Use the performance trace to identify its largest contentful paint, usually shortened to LCP. Confirm that the main product image is actually the measured element. A large heading or another image could take that role at a different viewport.

Next, inspect the image request in the network panel. Record its encoded size, pixel dimensions, request start time, and download duration. Compare its dimensions with the space it occupies on screen. A large mismatch gives you a clear starting point.

Keep the baseline repeatable. Use the same viewport, network throttling, and cache conditions for each comparison. Run several loads rather than trusting one result. Network variation can make a small improvement look larger than it is.

Also check when the request begins. If the browser waits for JavaScript to render the product gallery, smaller files will leave that initial delay intact. Put the primary image in the initial HTML where your rendering architecture allows it.

Prepare WebP Variants From a Reliable Source

Work from the highest-quality source you have. Repeatedly compressing an already damaged JPEG preserves its defects and can add new ones. Keep the source outside the delivery pipeline so future exports do not depend on yesterday’s compressed output.

During asset preparation, JPG to WebP lets you convert a JPEG and adjust quality and output dimensions. Use an initial conversion to compare the format against your current asset. For a large catalog, carry the approved settings into a repeatable build or image delivery workflow.

Choose widths from the component’s real display sizes. For a product image that occupies roughly 360 to 600 CSS pixels, candidates at 480, 800, 1200, and 1600 pixels might be a useful starting set. These are example widths, not a universal recipe. High-density screens need more image pixels than their CSS width alone suggests.

Generate each candidate from the source. Keep the same crop and aspect ratio across the set. A browser selecting a larger file should not accidentally select a different composition.

• Inspect fabric, grain, hair, and fine edges for lost detail.
• Check printed labels and small lettering for compression damage.
• Compare shadows and gradients for banding or blocky patches.
• Check product color against the approved source in a consistent color workflow.

Judge the output at its intended display size and at full pixel resolution. Pixel inspection helps locate defects. The rendered product page tells you whether those defects affect the shopping experience. Quality values are encoder settings, not interchangeable guarantees across formats.

Measure every exported file. WebP often produces smaller photographic assets, but the saving varies with content and settings. Keep the version that meets your visual standard with a sensible byte budget.

Make Srcset and Sizes Describe the Actual Layout

The browser needs two separate pieces of information. srcset lists available image files and their widths. sizes describes the image’s expected rendered width under different viewport conditions. Neither attribute replaces your layout CSS.

Consider a product layout with 16-pixel gutters on mobile. At 768 pixels, it changes to two columns with 24-pixel outer gutters and a 32-pixel gap. The container stops growing at 1232 pixels, leaving each column 600 pixels wide.

.product-layout {
  display: grid;
  gap: 32px;
  width: calc(100% - 32px);
  max-width: 1232px;
  margin-inline: auto;
}

.product-image {
  display: block;
  width: 100%;
  height: auto;
}

@media (min-width: 768px) {
  .product-layout {
    width: calc(100% - 48px);
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

For that layout, the matching image markup can look like this:

<img
  class="product-image"
  src="/images/chair-800.webp"
  srcset="
    /images/chair-480.webp 480w,
    /images/chair-800.webp 800w,
    /images/chair-1200.webp 1200w,
    /images/chair-1600.webp 1600w
  "
  sizes="
    (min-width: 1280px) 600px,
    (min-width: 768px) calc((100vw - 80px) / 2),
    calc(100vw - 32px)
  "
  width="1600"
  height="1200"
  alt="Oak dining chair with a woven seat, viewed from the front"
  loading="eager"
  fetchpriority="high"
>

Each width descriptor must match the actual width of its file. The mobile slot is the viewport minus 32 pixels. The desktop calculation subtracts both outer gutters and the column gap before dividing the remaining space in half.

The browser evaluates the conditions in order and uses the first matching size. It then considers that slot width, display density, and its selection policy when choosing a candidate. At a 600-pixel slot on a display with a device pixel ratio of two, a 1200-pixel candidate is a reasonable expectation. Selection remains the browser’s decision.

A common mistake is leaving sizes="100vw" on an image that occupies half the page. That overstates the slot and can trigger an unnecessarily large download. Treat changes to the component’s gutters, columns, or maximum width as reasons to review its image markup.

Reserve Space Before the Image Arrives

The width and height attributes in the example describe a 4:3 image. They give the browser an aspect ratio before the file finishes loading. The CSS still allows the image to scale with its column.

The documented behavior of image dimensions supports reserving that space before download, which helps prevent layout shifts when the image appears.

All candidates in this example must share that ratio. The 800-pixel version should be 600 pixels tall, for instance. If one candidate has a different crop, the reserved space may no longer match the rendered image.

If the design requires a fixed crop, define that box deliberately. A wrapper with aspect-ratio: 4 / 3 and an image using object-fit: cover can keep a gallery stable. Check that the crop preserves the product details shoppers need.

Responsive selection and art direction solve different problems. Use srcset for different resolutions of the same composition. Use picture when a breakpoint needs a different crop or your browser requirements call for a format fallback. If the crop changes ratio, reserve the appropriate space at each breakpoint too.

Give the Main Photo a Clear Loading Path

The primary product image should start loading without waiting for a scroll. Avoid lazy loading an image that is visible immediately and likely to become LCP. The example makes eager loading explicit and assigns a high fetch priority.

Priority is a hint. It does not remove server latency, delayed HTML, or rendering work. Assign it to the image that deserves early attention rather than every image in the gallery.

Images farther down the page can use loading="lazy". Keep their dimensions explicit as well. Lazy loading changes when the request starts; it does not reserve their layout space for you.

Add a preload only after the trace shows a discovery problem that it can solve. A preload pointing to a fixed large asset can waste bandwidth if the image markup selects another candidate. Any responsive preload needs candidate and size hints that agree with the image.

If you provide JPEG fallback through picture, keep the fallback responsive too. Put alternative format candidates on source, and retain the actual img element with its alt text, dimensions, and loading attributes. Format fallback does not rescue a missing WebP file that the browser already selected, so verify every asset path.

Validate the Files the Browser Actually Uses

Do the final checks on a staging page served through your production image path. Local files will not reveal CDN transformations, incorrect cache headers, or stale assets. Test the selected image, not just the files you intended to serve.

1. Load representative mobile and desktop viewports with a cold cache and controlled throttling.
2. Inspect currentSrc to confirm the selected candidate and compare it with the rendered slot width.
3. Record transferred bytes, request timing, response status, and content type in the network panel.
4. Compare the rendered image with the approved source, including zoomed product details.
5. Record a performance trace to check LCP and image-related layout shifts.

This console snippet makes the selected URL and current display conditions easy to inspect:

const image = document.querySelector(".product-image");

console.log({
  selectedAsset: image.currentSrc,
  renderedWidth: image.getBoundingClientRect().width,
  devicePixelRatio: window.devicePixelRatio
});

Read the requested file’s actual pixel dimensions from your asset inventory or network preview. Do not rely only on naturalWidth for width-descriptor candidates, because it can reflect density-corrected intrinsic dimensions.

Reload between selection tests. A browser may retain a larger downloaded candidate after you narrow the viewport. Resizing a warm page can therefore give you a misleading impression of what a fresh mobile visitor receives.

• The selected candidate provides acceptable sharpness at the tested display density.
• Transferred bytes fall without unacceptable damage to product detail.
• The main image request starts early and loads successfully.
• The gallery reserves its space before images appear.
• Fallback paths, where provided, serve valid responsive assets.

Compare LCP across repeated baseline and updated runs. Smaller transfers may shorten download time while another bottleneck limits the overall improvement. A late request start or delayed paint deserves its own fix. Also test a warm visit to understand caching behavior.

Ship a Faster Photo With a Steady Purchase Button

Release the image change with evidence attached: approved visual comparisons, candidate widths, measured transfer sizes, and repeatable loading results. Version the asset URLs so caches cannot mix old files with new markup.

After release, watch real-user performance by device group and page type. A desktop improvement can hide a mobile regression if responsive hints are wrong. Keep the original assets available for rollback until the new delivery path has proven reliable.

The finished product page should feel uneventful in the best way. The photo arrives early. Its details remain clear. The price and purchase button stay where the shopper expects them. WebP earns its place through that complete result: fewer bytes, appropriate resolution, and a layout that holds steady.