Image Optimization for Ecommerce: The Single Biggest Speed Win Most Thai Stores Skip

Product photography is typically the single heaviest category of content on an ecommerce page — heavier than the JavaScript, heavier than the CSS, often heavier than everything else on the page combined. It's also the easiest category to genuinely fix: unlike a design or UX change, image optimization is close to a pure technical win, with zero visual difference to the shopper when it's done properly. On a market where a meaningful share of traffic is still on 4G rather than fixed broadband, this is usually the single highest-return performance fix available, and it's routinely skipped in favor of flashier changes.

Modern formats cut file size dramatically at the same visual quality

JPEG and PNG are still the default output from most cameras and design tools, but WebP and AVIF compress the same image to a noticeably smaller file size at equivalent visual quality — often 25-50% smaller for WebP, and further still for AVIF, depending on the image. Serving these modern formats instead of legacy JPEG/PNG, with a fallback for the small share of older browsers that don't support them, is close to a free win: the shopper sees the same photo, the page loads faster.

Serving one oversized master image to every device is the most common mistake

A product photo shot and exported at a large master resolution, then displayed at a much smaller size on the actual page — a thumbnail, a thumbnail in a carousel, a mobile-width product image — but still delivered at full resolution, is one of the most common and most costly image mistakes on ecommerce sites. The fix is responsive images: serving multiple sizes of the same photo and letting the browser request the one that actually matches the display size and device pixel density, via srcset and sizes attributes (or the equivalent handled automatically by an image CDN or a framework's built-in image component). A shopper on a phone should never download a 2400px desktop-resolution image to display it at 400px wide.

Lazy loading defers what isn't visible yet, without hurting the shopper's experience

A product listing page with forty product images doesn't need all forty downloaded before the page becomes usable — only the ones currently visible in the viewport do. Lazy loading (native via loading="lazy", or handled by an image CDN/framework) defers loading images below the fold until the shopper actually scrolls to them, which meaningfully speeds up initial page load without the shopper ever noticing a missing image, since it loads just ahead of the scroll reaching it.

The hero image is the one place lazy loading actively hurts

The exception that trips up a lot of otherwise-correct lazy-loading setups: the largest, most prominent image above the fold — a hero banner, the primary product photo — is very often what Largest Contentful Paint (a core Web Vitals metric) actually measures, and lazy-loading it delays exactly the thing that metric is timing. That one image should load eagerly and, ideally, be preloaded, while everything below the fold lazy loads. Applying lazy loading uniformly to every image on the page, including the hero, is a subtle but measurable performance regression disguised as an optimization.

Compression quality has a sweet spot, not a maximum

Aggressive compression trades file size for visible quality loss, and past a certain point the savings aren't worth what the shopper sees — banding, blur, or visible artifacts on a product photo actively hurt trust in what's being sold. The practical target for JPEG/WebP product photography is usually in the 70-85% quality range: well below the wasteful, often-default 95-100% "as if it were print," and well above the point where compression artifacts become visible. This isn't a single universal number — a photo with fine texture or gradients tolerates less compression than a simpler, flatter product shot before artifacts show — but it's a range worth actually testing per template rather than assuming a single default is correct everywhere.

Correct dimensions prevent layout shift, which Core Web Vitals penalizes directly

An image tag without explicit width and height attributes forces the browser to not know how much space to reserve for it until the image actually loads, which causes surrounding content to jump once it does — this is Cumulative Layout Shift, a Core Web Vitals metric that directly affects ranking and is also simply annoying for a shopper trying to tap a button that just moved. Setting explicit dimensions (or using a aspect-ratio CSS value) lets the browser reserve the correct space immediately, before the image has actually downloaded.

An image CDN handles most of this automatically, which is usually worth it

Doing all of the above manually — generating multiple sizes, converting formats, setting up lazy loading, choosing compression levels — for every product image is real, ongoing work. An image-optimizing CDN (Cloudflare Images, Cloudinary, imgix, or a platform's built-in equivalent) typically handles format conversion, resizing, and compression automatically based on the requesting device, turning this from a recurring manual task into a one-time integration. For a catalogue of any real size, this is usually worth the cost on its own, purely from the page-weight savings and the engineering time it removes from the ongoing workload.

What this actually costs a Thai ecommerce store when it's wrong

A product page loading 3-4MB of unoptimized images instead of 400-600KB of properly optimized ones isn't a marginal difference on a 4G connection — it's the difference between a product page that feels instant and one that visibly, frustratingly loads in front of the shopper piece by piece. Given how much of Thai ecommerce traffic is mobile, and how much of that mobile traffic isn't on fast, stable wifi, image weight specifically punishes the majority use case, not an edge case — which is exactly why it's worth fixing before chasing smaller, less impactful optimizations elsewhere on the page.

A practical audit order

1. Check current image format and size on the actual live product pages — a browser's network tab shows this directly, no special tooling needed.
2. Confirm images are served at the size they're displayed at, not a single oversized master serving every breakpoint.
3. Convert to WebP (with AVIF where supported) with a fallback, if not already happening automatically.
4. Apply lazy loading below the fold, and confirm the hero/LCP image is explicitly excluded from it.
5. Set explicit width/height (or aspect-ratio) on every image to eliminate layout shift.
6. Test compression quality per template rather than assuming one default number works for every kind of product photo.

None of this touches design, copy, or the shopping experience itself — it's close to the purest "free" performance win available on an ecommerce site, and the gap between a store that's done this properly and one that hasn't is usually larger than owners expect until they actually measure it.