Ecommerce Image Performance: Diagnose Image Weight, LCP and Delivery Problems

Fix the bottleneck, not just the file format

On an ecommerce site, image performance depends on more than whether a product photo is JPEG, WebP or AVIF. A page can serve a modern format and still be slow because the file is far larger than its displayed size, the browser discovers the main product image late, a gallery downloads every slide immediately, or the responsive markup points mobile devices at desktop-sized assets.

The practical order is: identify the image request that is expensive or late, understand why the browser chose it, fix that cause, then verify the result. Converting every image to a newer format before doing this can save bytes while leaving the real Largest Contentful Paint (LCP) problem untouched.

LCP measures loading performance, and an image can be the LCP element on product and category pages. Google recommends aiming for an LCP of 2.5 seconds or less for a good user experience, assessed at the 75th percentile of page loads. Core Web Vitals are used by Google's ranking systems, but Google also makes clear that good Core Web Vitals do not guarantee high rankings. Treat image performance as a user-experience and technical-quality issue, not as a guaranteed ranking lever. See Google's Core Web Vitals guidance.

What “image weight and delivery” actually means

Image weight is the amount of image data a visitor has to download. Image delivery is the process that determines which image URL is discovered, which variant the browser selects, when it is requested, how it is cached and how quickly it reaches the visitor.

For ecommerce teams, it helps to separate four different questions:

• Asset efficiency: Is the image encoded at a sensible quality and dimensions for the job?
• Responsive selection: Does the browser receive appropriate candidates for the actual display slot through srcset and sizes?
• Loading priority: Is the main above-the-fold product image discovered promptly while offscreen gallery and recommendation images are deferred?
• Search discoverability: Can Google find important product imagery in standard HTML, and do the page context and alt text describe it accurately?

These are related but not interchangeable. A 120 KB image requested too late can hurt LCP more than a 180 KB image discovered immediately. A perfectly compressed 1600-pixel image is still wasteful if it is displayed in a 400-pixel slot. And an aggressively lazy-loaded product image may save initial bandwidth while delaying the most important visual content.

Google's current image SEO best practices recommend standard HTML image elements, responsive image techniques and a usable src fallback. Google also supports WebP and AVIF in Image Search. That is a discoverability recommendation; it does not mean that changing format alone improves rankings.

Diagnostic checklist: pinpoint the expensive or late image request

Start with representative templates rather than a random URL: at minimum, inspect a product detail page, a category or collection page, and any homepage or campaign template with prominent photography. Use browser developer tools, Lighthouse or PageSpeed Insights to identify the LCP element and the image requests that dominate transfer size.

Do not use a universal “maximum image size” as the diagnosis. The right transfer size depends on the visual content, dimensions, format, quality requirements and connection. Instead, look for avoidable waste: far more pixels than the layout can display, multiple high-resolution variants downloaded at once, duplicate requests, or a critical image that starts late.

For each important request, record its URL, transfer size, intrinsic dimensions, rendered dimensions, MIME type, request start time and whether it becomes the LCP element. That gives a developer a specific problem to fix rather than a generic instruction to “optimise images.”

Workflow for image optimisation and delivery fixes

Apply the smallest change that addresses the measured bottleneck. On large catalogues, fix the template or image pipeline that generates the problem rather than manually editing individual product files.

Step 1: Resize and encode for the actual display slot

Generate image widths that reflect the layouts your store really uses. A category card, a product hero image and a zoom view do not need the same source dimensions. The old habit of uploading one enormous master image and sending it to every device wastes bandwidth even if the file has been converted to WebP.

For photographic product imagery, JPEG, WebP and AVIF are all viable depending on your pipeline and browser-support requirements. WebP and AVIF can often reduce transfer size compared with older formats, but there is no universal winner for every asset. Compare visual quality and file size using representative products, especially images with fine texture, gradients, transparent backgrounds or colour-critical details. For logos and simple vector artwork, SVG may be a better fit; for lossless transparency, PNG or lossless modern formats may still be appropriate.

There is no defensible rule such as “reduce every source to 33%.” Resize to the sizes your layout can actually request, keep a sufficiently large source for zoom or high-density screens where the product experience needs it, and avoid shipping that high-resolution asset during the initial page load unless it is genuinely required.

Step 2: Give the browser real responsive choices

srcset provides candidate image files; sizes tells the browser approximately how wide the image will be in the layout. With width descriptors, the HTML specification requires sizes, and inaccurate values can cause the browser to choose a larger candidate than necessary.

This example is suitable for a prominent product image when the image is likely to be above the fold. The exact widths and sizes values must match your own CSS rather than being copied blindly:

<picture>
  <source
    type="image/avif"
    srcset="/images/boot-480.avif 480w,
            /images/boot-800.avif 800w,
            /images/boot-1200.avif 1200w">
  <source
    type="image/webp"
    srcset="/images/boot-480.webp 480w,
            /images/boot-800.webp 800w,
            /images/boot-1200.webp 1200w">
  <img
    src="/images/boot-800.jpg"
    srcset="/images/boot-480.jpg 480w,
            /images/boot-800.jpg 800w,
            /images/boot-1200.jpg 1200w"
    sizes="(max-width: 700px) 92vw, 50vw"
    width="800"
    height="1000"
    fetchpriority="high"
    alt="Black leather Chelsea boot, side view">
</picture>

The src fallback is important for resilience and image discovery. The width and height attributes give the browser the image's intrinsic aspect ratio so it can reserve space before the file arrives, reducing avoidable layout movement. The alt text should describe the image for users who cannot see it; do not turn it into a list of keywords.

If you need a deeper comparison of formats and delivery approaches, use ScanMySEO's image delivery guide covering WebP, AVIF, responsive images and CDNs.

Step 3: Separate critical images from lazy-load candidates

Lazy loading is useful for images that are initially offscreen, but it is counterproductive when applied to the image a visitor is expected to see immediately. web.dev specifically cautions against lazy-loading images that are likely to be in the initial viewport, especially LCP images. For a product detail page, that often means the selected primary product image should load normally while later gallery slides, related products and long-page editorial imagery can be deferred.

Use fetchpriority="high" selectively when you know an image is important to the initial view and the browser would benefit from an explicit priority hint. It is a hint, not a guarantee, and applying it to many images at once defeats the purpose. MDN documents fetchpriority as a relative fetch-priority hint.

For images below the initial viewport, native lazy loading is usually a sensible default:

<img
  src="/images/boot-detail-800.webp"
  srcset="/images/boot-detail-480.webp 480w,
          /images/boot-detail-800.webp 800w"
  sizes="(max-width: 700px) 92vw, 50vw"
  width="800"
  height="1000"
  loading="lazy"
  alt="Close-up of the Chelsea boot elastic side panel">

Do not make important image content depend on a user click or scroll event before the URL exists in a usable form. Google's lazy-loading guidance says relevant content should load when it becomes visible rather than requiring user interaction, because Google Search does not interact with a page like a shopper does.

Step 4: Use an image CDN when automation justifies it

An image content delivery network (CDN) can be useful when a store has many products, variants, breakpoints or frequent catalogue changes. A well-configured service can generate transformations, negotiate formats, cache variants close to users and remove manual image processing from publishing workflows.

A CDN is not automatically a performance fix. Check that the transformation parameters generate the sizes your templates need, that caching is effective, that the correct Content-Type is returned, and that you are not creating many near-duplicate variants that waste storage and cache efficiency. If the same image is reused on multiple pages, Google recommends referencing it consistently with the same URL so it can cache and reuse the image rather than fetching it repeatedly.

If images are hosted on a separate CDN hostname, make sure the files are publicly fetchable and not blocked from Googlebot-Image. Google also recommends verifying the CDN domain in Search Console when you use image sitemaps or want crawl-error visibility for that host.

Ecommerce edge cases that generic image advice misses

Product galleries and carousels

The first selected product image and the tenth gallery image do not have the same loading priority. Load the image needed for the initial product view promptly; defer images the shopper may never open. If changing a colour swatch replaces the main image, make sure the newly selected image can load quickly without forcing every possible variant image into the initial request burst.

Zoom and high-resolution imagery

Zoom can justify a large source image, but that does not mean the zoom asset must be the first file downloaded. A common pattern is to use a responsive display image for the normal page and request the higher-resolution zoom source only when the shopper asks for it. Preserve enough quality for product inspection—performance work that makes texture, colour or detail unreliable is a product-experience regression.

Category grids and infinite scroll

Category and collection pages can multiply small inefficiencies because dozens of tiles may share the same template. Check whether every card is receiving a sensibly sized candidate and whether below-the-fold rows are deferred. With infinite scroll, also test image loading after new products are inserted; a fast first viewport does not prove later batches are efficient.

Image discovery and product context

For important product imagery, use standard <img> elements rather than relying only on CSS background images. Google says it can find images in the src attribute of img, including inside picture, but it does not index CSS background images as images. Descriptive filenames, relevant nearby text and useful alt text can also help Google understand the subject of an image.

An image sitemap can help Google discover images that are otherwise difficult to find, but it does not replace accessible page markup or sensible internal architecture. Treat it as a discovery aid, not as a substitute for fixing the page.

Verify the result with field data and diagnostic tests

Do not judge the change from one Lighthouse score. Lighthouse is a controlled lab test that is useful for debugging, while field data measures real user experiences. PageSpeed Insights can show Chrome User Experience Report (CrUX) field data when enough data exists. Google reports Core Web Vitals using the 75th percentile over a rolling field-data window, so a production improvement may not immediately change the field assessment.

Before and after the change, compare:

• which element is reported as LCP;
• when the LCP image request starts and finishes;
• total image bytes transferred in the initial viewport;
• whether mobile receives an appropriately sized candidate;
• whether offscreen gallery and recommendation images are deferred;
• whether layout movement has been reduced by reserving image space;
• whether product quality, zoom behaviour and variant switching still work;
• field LCP and other Core Web Vitals where representative data is available.

If image bytes fall but LCP does not improve, do not automatically revert the image work. The remaining bottleneck may be server response time, render-blocking CSS, JavaScript, fonts or another resource. The purpose of verification is to identify what changed and what did not, not to force every optimisation to move every metric.

For a broader measurement process, see ScanMySEO's performance verification decision guide.

What to fix first

1. If the main product image is the LCP element and starts late: fix discovery and loading priority before chasing marginal compression savings.
2. If mobile downloads images far larger than their rendered slots: fix candidate generation, srcset and sizes.
3. If a page downloads many images that are initially offscreen: lazy-load the non-critical set while keeping the initial hero or product image eager.
4. If the right-sized image is still unnecessarily heavy: tune dimensions, quality and format using representative visual checks.
5. If the catalogue is too large to manage manually: automate transformations and caching through the CMS, build pipeline or an image CDN, then verify the generated markup rather than assuming the service's defaults are correct.

The best ecommerce image workflow is therefore not “convert everything to WebP.” It is “measure the request, classify the image's role, fix the reason it is expensive or late, and verify the result.” That approach reduces wasted work and makes the performance recommendation specific enough for a developer, platform team or agency to implement safely.