How to optimize images for your website

Most "optimized" images are still too heavy

Run your homepage through PageSpeed Insights right now. If your Largest Contentful Paint is above 2.5 seconds, images are almost certainly the reason. On the median e-commerce site, images account for 42-50% of total page weight. A single uncompressed hero image can weigh more than the entire HTML, CSS, and JavaScript combined.

The fix isn't one trick. It's a stack of decisions about format, dimensions, compression, and delivery - each one shaving off bytes that add up to real speed differences.

WebP cuts file size in half compared to JPEG - so why aren't you using it?

WebP delivers 25-34% smaller files than JPEG at the same visual quality, according to Google's own testing. For PNGs with transparency, WebP reduces size by roughly 26% compared to PNG. Browser support hit 97% globally in 2024, which means the "compatibility" excuse is gone.

Here's when to use each format:

• WebP - your default for photographs, product shots, hero images, and banners. Best compression-to-quality ratio available.
• JPEG - fallback for the 3% of browsers that can't handle WebP. Also fine for quick email assets where you don't want to think about it.
• PNG - logos, icons, and anything requiring transparency where SVG isn't an option.
• SVG - icons, logos, and simple graphics. Vector format, so it scales to any size at near-zero file weight.
• AVIF - even smaller than WebP (roughly 20% more compression), but browser support sits around 92%. Worth testing for hero images where every kilobyte matters.

ConversionWax serves images in WebP by default through its CDN, so if you're using it to manage hero images or product banners, the format decision is already handled.

Resize before you upload, not after

Uploading a 4000px-wide photo and relying on CSS to display it at 800px means the browser still downloads the full 4000px file. That's 5-10x more data than needed.

Match your image dimensions to the largest size it will actually display:

• Hero images: 1600px wide covers most desktop viewports. Going beyond 2000px adds weight without visible improvement on 1080p or 1440p screens.
• Blog thumbnails: 600-800px wide is plenty.
• Product images: 1000-1200px wide handles zoom functionality without bloat.
• Social sharing images: 1200x630px for Open Graph.

ConversionWax auto-resizes images per viewport when you set up personalization rules. Upload a single high-resolution source image and it serves the right dimensions for mobile, tablet, and desktop - no manual resizing needed for each breakpoint.

Compression: how far can you push it before it looks bad?

For JPEG and WebP, quality 75-82 is the sweet spot. Below 70, you start seeing artifacts around text and sharp edges. Above 85, file size grows fast with almost no visible improvement.

Two types of compression and when each makes sense:

• Lossy - removes data the human eye barely notices. Use for photos, lifestyle imagery, backgrounds. A hero image at quality 80 looks identical to quality 100 on screen but weighs 60-70% less.
• Lossless - preserves every pixel. Use for logos, screenshots, diagrams, and anything with sharp text.

Tools that work well:

• Squoosh (squoosh.app) - browser-based, lets you compare quality settings side-by-side. Best for one-off images.
• Sharp (Node.js library) - batch processing in build pipelines. We use this for processing hundreds of images at deploy time.
• TinyPNG/TinyJPG - API-based compression if you want a quick drag-and-drop solution. Free tier handles 500 images per month.

Responsive images: stop serving desktop images to phones

A phone on a 375px-wide screen does not need a 1600px image. Using the srcset attribute and sizes attribute together tells the browser exactly which image variant to download.

The pattern looks like this in HTML:

• Create 3-4 variants of each image: 400px, 800px, 1200px, 1600px wide
• Use srcset to list them with their widths
• Use sizes to tell the browser the rendered width at each breakpoint

The browser then picks the smallest image that covers the rendered area. On a phone, that's often the 400px version - roughly 85% smaller than the desktop image.

If you're running ConversionWax, this is handled automatically. The platform detects viewport size and serves the appropriate image variant from its CDN. You upload one source image, tag it in the asset library, and the right version goes to each visitor.

Lazy loading: why would you load images nobody sees?

Images below the fold don't need to load until the user scrolls near them. Native lazy loading is now built into HTML - add loading="lazy" to any img tag and the browser handles the rest.

Two rules:

• Never lazy-load above-the-fold images. Your hero image and any visible-on-load content should use loading="eager" (or just omit the attribute). Lazy loading your LCP image will tank your Core Web Vitals score.
• Do lazy-load everything else: product grids, blog post thumbnails, gallery images, footer logos.

On a page with 30 product images, lazy loading typically reduces initial page weight by 70-80%. The user only downloads what they actually scroll past.

CDN delivery matters more than you think

Without a CDN, a visitor in Sydney loading images from a server in Virginia waits 200-300ms for each round trip. With a CDN, the same image is served from a Sydney edge node in under 20ms.

CDNs also handle two optimization tasks automatically:

• Format negotiation - modern CDNs detect browser support and serve WebP or AVIF when the browser accepts it, JPEG when it doesn't.
• Edge caching - after the first request, subsequent visitors in the same region get cached copies, reducing origin server load.

ConversionWax routes all personalized images through its CDN with sub-1ms latency. If you're swapping hero images based on location, UTM parameters, or viewport, the performance overhead is effectively zero compared to a static image.

Alt text is an SEO signal, not a chore

Google Image Search drives 22% of all web searches. Every image without alt text is a missed ranking opportunity.

Write alt text that describes what the image actually shows, not what you wish it showed:

• Bad: alt="image" or alt="photo"
• Bad: alt="best running shoes for men buy now free shipping"
• Good: alt="Navy blue Nike Pegasus 41 running shoe on white background"

Keep it under 125 characters. Include a relevant keyword when it fits naturally. Skip alt text entirely on decorative images (use alt="" to tell screen readers to ignore them).

Bulk image management gets messy fast

At 10 images, manual optimization is fine. At 500, you need a system. Most teams end up with scattered folders, inconsistent naming, and no way to find the right variant of an image when they need it.

ConversionWax's asset library lets you bulk upload images, tag them by campaign or category, and search across your entire library. When you need a seasonal banner variant for three different viewport sizes, you find it by tag instead of digging through nested folders. The platform also includes AI image generation through Google Gemini - useful for quickly producing image variants when you need location-specific or seasonal alternatives without a photoshoot.

Measure the impact or you're guessing

After making changes, test with these tools:

1. PageSpeed Insights - check your LCP score. Target under 2.5 seconds.
2. WebPageTest - run a filmstrip test to see exactly when images appear during page load.
3. Chrome DevTools Network tab - filter by images, sort by size. Your largest image should be under 200KB after optimization.
4. CrUX data in Search Console - real-user performance data over 28 days. This is what Google actually uses for ranking.

A site averaging 4-second LCP that drops to 2 seconds after image optimization typically sees 15-25% lower bounce rates within two weeks. The speed-to-conversion relationship is well documented - every 100ms of improvement correlates with roughly 1% higher conversion rates for e-commerce sites.