How should an online shop deliver product images across mobile and desktop?

Start with the buying decision

A product image is part of a buying decision: a buyer may need to inspect the shape, finish, connection ports or included pieces. Optimisation must preserve that evidence. Begin with a short inventory of image roles rather than one blanket compression setting. A small catalogue thumbnail, the primary product photograph, a zoom view and a lifestyle image have different display sizes and detail needs. Record the image's intended display width on a narrow phone and a desktop layout, whether it appears in the first viewport, and whether the viewer can open a larger view. Keep the underlying photograph faithful to the product; a faster file that obscures a material detail creates a different customer problem. Google recommends high-quality images while also applying responsive techniques for speed.

Responsive delivery usually means preparing several sizes of the same photograph and telling the browser what each file actually contains. With width descriptors in srcset, a candidate marked 800w must really be 800 pixels wide. The sizes attribute describes the width the image will occupy under the page layout; it does not resize the image by itself. CSS still controls the rendered box. The browser combines that declared slot with device information, including pixel density, to choose a candidate. Keep a normal src fallback so basic clients and crawlers have an image URL. A content team should verify the CMS or image service generates matching files, not merely paste attributes around one oversized original.

Suppose a shop displays a ceramic cup photo at about 360 CSS pixels wide on a phone and around 620 on a desktop product page. The exact numbers here are example layout assumptions, not measured site data. The shop might prepare several source widths spanning those display needs and dense screens, then check which one the browser selects at each viewport. There is no universal list of breakpoints: a two-column tablet view, a zoom affordance and the photo's crop may change the needed candidates. If the thumbnail and product page use the same file URL despite very different boxes, inspect the download before assuming the CMS is efficient. The goal is enough detail for the task with no gratuitous transfer of pixels.

Reserve space and choose loading priority

Set meaningful width and height attributes or an equivalent aspect ratio so the browser can reserve a box before the image arrives. This is especially important on a product page where price, variants and the purchase button sit beneath or beside the photograph. If the page shifts while a customer is trying to tap a variant, the experience feels unstable even if the image eventually looks good. The declared ratio must match the intended source family. If a narrow-screen art-directed crop has a different ratio, handle that case deliberately rather than stretching it into the desktop shape. Review the rendered page with images arriving slowly; a static screenshot after full load will not reveal the shift.

Lazy loading is a selective tool. Google's web.dev guidance says images visible in the initial viewport, especially an image that may be the Largest Contentful Paint element, should generally load eagerly. Offscreen catalogue photos can use loading=lazy, but applying it indiscriminately to the hero product image can delay the very picture the buyer came to inspect. Likewise, preloading every image defeats prioritisation. Mark the likely primary visual, then test on a real product page with the actual template, not a synthetic empty page. A shop with a narrow phone header may put the primary image farther down than a desktop view, so confirm viewport behaviour instead of hard-coding an assumption for all devices.

File format and compression are choices within a quality budget, not an excuse to change the subject. Export representative photos in formats supported by the storefront and compare the visible finish, fine print on packaging when it matters, and bytes transferred at the same display size. Transparent packshots may have a different need from photographs. Keep an original master outside the delivery pipeline so later crops can be recreated without repeatedly re-encoding a lossy file. If an image service transforms files on demand, verify cache keys and generated variants still correspond to the intended product and colour. Do not show a different colour or accessory just because a cached crop looked sharp in a performance report.

Test the delivered result

Open a representative category page and product detail page at phone, tablet and desktop widths. In browser developer tools, record the rendered image dimensions, currentSrc URL, intrinsic file dimensions, transferred bytes and whether the image appears before or after scrolling. These are local observations for the shop to collect; no number in this article is a claim about a live Astera client. Check a dense-screen phone as well as a standard display, because the browser can rationally choose a larger candidate than the CSS box. The useful comparison is selected file against its rendered purpose, not simply the largest available file. Repeat for a slow connection and a returning visit to see both initial experience and caching behaviour.

Use a small acceptance sheet for each image role. For the main product view, the buyer should see a stable, sharp photo promptly and be able to inspect important details. For catalogue thumbnails, scrolling should not trigger avoidable large transfers, and each card should reserve its photo space. For zoom, a higher-detail version should load when requested without silently replacing the normal page image with an oversized asset on every visit. Include both language versions where the layout differs, but the image's technical selection does not need to change just because a caption is Chinese. An accessible alternative description remains important for meaning, yet choosing words for alt text is a separate editorial task from choosing file sizes.

Google's image guidance also says standard HTML img elements help crawlers discover images, and recommends a src fallback when using picture or srcset. That matters to a shop whose product photos are intended to be publicly discoverable. Check that the chosen image URL responds correctly and that the product page gives it accurate surrounding context. Avoid hiding every important photo solely in a CSS background when it represents the merchandise. After a change, re-check at least one unusual product: a very tall item, a dark surface, or a product with small connectors. Such cases often reveal a crop or compression decision that looks fine on the ordinary sample. Record the chosen variant and any exception for the content team.

A practical workflow begins when a new product is photographed. Name the master by product identity, record the approved crop and colour, then create derivative files through a documented process. If colours share a template, keep the variant-to-image mapping explicit; an optimisation should never substitute a blue product image for a black one. Check a sample after every bulk import, because image services can fail on an unusual orientation or filename. Content editors need a mobile crop preview before publishing, while developers need to inspect the selected network resource. These checks answer different questions: whether the photo tells the truth, and whether the page delivers it efficiently. Both belong in release acceptance, with a named owner for correcting an image that fails either test.

When evidence is mixed, choose a reversible change. Start with high-traffic templates only if your own analytics identifies them; otherwise use a representative product family without calling it a traffic winner. Compare before and after under the same device and connection assumptions, and preserve screenshots and network records. If bytes fall but customers can no longer distinguish a material texture, restore quality or provide a better zoom route. If a mobile image looks sharp yet arrives late, inspect priority and server response before another compression pass. A measured outcome should name the URLs, devices, dates and conditions observed. Without that evidence, describe the expected mechanism and a test plan, not a claimed speed improvement. Recheck after a template or image-service change, because an earlier result may no longer apply.