Development
Image optimization for ecommerce, CDN to alt text
A working pipeline for product imagery: source files, formats, responsive markup, loading priority, feed images and alt text that describes.
By CartKernel · Published
Product photography is the largest thing most stores ship to a phone and the thing shoppers most want to see. Both facts are true at once, which is why image work is a pipeline rather than a setting. Get the four stages right, in order, and the same photograph loads fast, looks correct on every screen, survives a feed submission and is described accurately for anyone who cannot see it.
The four stages are: the source file you upload, the transformation your platform applies, the markup that requests it, and the metadata that travels with it. Most stores fix stage three and leave the other three untouched, which is why the gains disappear.
Upload one master file per shot, sized for the largest use
Decide the largest size any shopper can see. On a product page that is usually the zoom or lightbox view, not the gallery thumbnail. Then upload a master file at that size, in a lossless or lightly compressed format, and let the platform generate everything smaller.
Rules that pay for themselves:
- One aspect ratio per catalog. Mixed ratios force either letterboxing or crops that cut off product edges, and they make collection grids shift as images arrive.
- Consistent subject scale. A shoe that fills 90 percent of the frame in one shot and 40 percent in the next makes a grid look unfinished even when every file is correct.
- No text baked into the photograph. Baked text cannot be translated, cannot be read by assistive technology, and often conflicts with feed image requirements.
- Sensible file names before upload. A name that describes the product beats a camera serial number, and renaming after upload usually breaks existing references.
Master files above the largest displayed size cost storage and nothing else, because the delivered file is generated. Master files below it cannot be recovered later.
Choose the format by what is in the frame
Modern image formats compress the same photograph substantially smaller than the older ones at a quality most shoppers cannot distinguish. Most ecommerce platforms and image CDNs will negotiate the format automatically based on what the browser accepts, so the practical job is confirming that negotiation is happening rather than choosing a format by hand.
A short guide by content type:
| Content | Approach |
|---|---|
| Product photography on a plain background | Lossy compression, automatic modern format, quality tuned per catalog rather than per image |
| Lifestyle and editorial photography | Same, with a slightly higher quality setting where fine texture matters |
| Logos, icons, size charts, diagrams | Vector where the source allows, since it stays sharp at every density and usually weighs less |
| Swatches and color chips | Small vector or CSS, not a photograph |
Test the quality setting once, on the ten products whose texture is hardest to compress, and apply the result catalog-wide. Per-image tuning is a cost that never ends.
Let the markup request the right size
The single biggest waste in ecommerce imagery is a phone downloading a desktop-sized file. Responsive markup fixes it, and it has two halves that must agree:
- A set of candidate files at different widths. Enough steps that the browser can pick something close, typically every few hundred pixels across the range you actually display.
- A description of how wide the image will be at each breakpoint. This is the half stores get wrong. If the description claims full viewport width but the image renders in a three-column grid, the browser downloads roughly three times the pixels it needs.
Check it the same way every time: load a collection page on a phone-sized viewport, look at the transferred size of one grid image, and compare it with the rendered dimensions multiplied by the device pixel ratio. A transferred file much larger than that product is a broken sizes description, not a compression problem.
Give exactly one image priority, defer the rest
The main product image is usually the element that defines Largest Contentful Paint on a product page. It should be discoverable in the initial HTML, requested at high priority, and not lazy loaded. Everything else on the page, including the rest of the gallery, loads lazily.
Common patterns that delay the hero image:
- A carousel library that inserts the first slide with JavaScript after hydration, so the browser cannot find the image while parsing HTML.
- A blanket lazy loading rule applied to every image on the page, including the one above the fold.
- A hero served from a different origin than the page, adding a connection setup before the request starts.
- A large above-the-fold background image set in CSS, where the browser discovers it only after the stylesheet is parsed.
Every image and video slot also needs reserved space, through width and height attributes or a CSS aspect ratio, so arriving media does not push content down the page. Layout stability is cheap to build in and expensive to retrofit. If product templates are already failing on these metrics, Core Web Vitals failing on product pages has the diagnosis order, and Core Web Vitals defines what each number measures.
Alt text describes the image to someone who cannot see it
Alt text has one job: convey what the image shows, in a sentence, to a person using a screen reader or a browser that failed to load the file. Search engines read it as a description of the image, which is why a description written honestly also serves discovery.
Practical rules:
- Describe the subject, the notable attributes and the context. “Walnut dining chair with a woven cane back, shown from the front” beats “dining chair”.
- Do not repeat the product name in every gallery image. Vary the description to match what each shot actually shows: back view, close-up of the seam, in-room scale shot.
- Leave alt empty for decorative images so assistive technology skips them, rather than inventing text for a background flourish.
- Never write a keyword list. It reads as noise aloud and helps nobody.
- Caption text near the image is read by everyone, so put buying-relevant detail there rather than hiding it in alt.
How many images a page needs, and which shots earn their place, is covered in how many product images should a product page have, and the arrangement of the gallery inside the wider template is in the product page anatomy.
Feed images follow separate rules
The image you show on the site and the image you submit in a product feed are the same file only if the feed’s requirements allow it. Shopping surfaces have their own specifications covering minimum dimensions, permitted content and what may not appear in the frame. Promotional overlays, watermarks, borders and text on the image are commonly restricted, and the primary image is expected to show the item being sold rather than a lifestyle scene.
Two habits keep this clean. Keep a dedicated primary image per product that satisfies the strictest surface you submit to, and use additional image fields for the lifestyle and detail shots. Where the site’s hero shot has a promotional badge burned in, supply the clean file to the feed through a feed rule rather than editing the catalog, which is the approach described in feed rules without catalog changes. Image requirements are part of the wider work in product feed optimization.
The checks that catch regressions
Image quality decays quietly. New products get uploaded at the wrong size, a theme update changes a grid, an app inserts an unoptimized banner. A short recurring check catches all three:
- Sample five recently added products and confirm the delivered file size on a phone-sized viewport matches the rendered size.
- Confirm the main product image is not lazy loaded and appears in the initial HTML.
- Run one collection page and one product page through a lab test and compare with the last recorded numbers.
- Spot check ten alt attributes for descriptions rather than keyword lists.
- Review feed diagnostics for image-related warnings after each catalog upload.
Image work sits inside the wider site speed optimization practice, and the Core Web Vitals checker gives you a current reading per template before and after each change.