September 29, 2026 · 8 min read
Preparing Images for a Website or Shop So Pages Load Fast
Oversized images are the usual reason a shop feels slow. What dimensions to export, when WebP helps, and how to check whether it made any difference.
When a site feels slow, images are the first place to look. A page of text and CSS weighs a few hundred kilobytes; one product photo straight off a camera can weigh more than that on its own. The good news is that this is the easiest performance problem there is to fix, and unlike most optimisation work you can see the result in a minute.
Almost always the same mistake
The commonest cause is not the format or the compression setting. It's uploading a 4,000-pixel-wide photo into a slot that displays it 600 pixels wide. The browser downloads every one of those pixels and then throws most of them away. Fixing the dimensions usually takes more weight off the page than any amount of clever encoding.
| Where it appears | Export at | Rough target |
|---|---|---|
| Full-width hero banner | 1,920–2,560 px wide | Under 300 KB |
| Product photo, main image with zoom | 1,600–2,000 px | 150–300 KB |
| Product grid thumbnail | 600–800 px | Under 60 KB |
| Blog illustration in a text column | 1,200–1,600 px | Under 150 KB |
| Avatar, logo, icon | Displayed size ×2 | A few KB |
Why ×2 in places: high-density screens draw two device pixels for every CSS pixel, so an image shown at 300 px looks crisper at 600 px. That's the argument for roughly double, not for ten times — which is what a raw camera file gives you.
Formats, and when WebP is actually worth it
- JPEG: photographs. Universal, well understood, perfectly fine when sized correctly.
- PNG: flat graphics, logos, screenshots with text, anything needing transparency. Terrible for photographs.
- WebP: does both jobs. At comparable visual quality it is usually meaningfully smaller than JPEG, and it supports transparency, so it can replace PNG logos too. Supported by all current mainstream browsers.
- AVIF: smaller again, particularly on photographs, with slower encoding and less consistent support in older software and tooling. Worth using with a JPEG or WebP fallback rather than alone.
- SVG: logos, icons, diagrams, anything drawn rather than photographed. Scales to any size for almost no weight.
The honest summary on WebP: switching formats is a real but secondary win. If your images are the right dimensions and sensibly compressed, WebP takes a further slice off. If they are 4,000 pixels wide, WebP just gives you a smaller enormous file. Do the dimensions first.
Resize and re-encode a batch of images in your browser before uploading.
Open the File CompressorLet the platform do the work it already does
Before you build a manual pipeline, check what your stack already handles. Most modern platforms generate sized variants and serve modern formats automatically, and fighting that is wasted effort.
- Shopify, Squarespace and Wix generate multiple sizes and serve WebP where supported. Upload a good-quality source at sensible dimensions and let them derive the rest.
- WordPress creates several sizes on upload; a plugin like ShortPixel or Imagify adds WebP conversion.
- Next.js, Nuxt and similar frameworks have built-in image components that resize, convert and lazy-load for you.
- If you're hand-writing HTML, use srcset and sizes so the browser can pick the right file, and set width and height attributes so the layout doesn't jump while images load.
- Add loading="lazy" to everything below the fold, and leave it off your hero image so it isn't delayed.
A workflow that stays consistent
- Keep full-resolution masters somewhere off the site. You'll want them when the design changes.
- Standardise on one aspect ratio per collection. A product grid with mismatched crops looks amateurish regardless of speed.
- Export at your target dimensions, then compress once. Don't compress an already-compressed export.
- Name files descriptively — brown-leather-satchel-front.jpg, not IMG_4021.jpg. It helps you, and image search reads it.
- Write real alt text. It is what screen readers use and what shows when an image fails to load.
| Tool | Use it for | Note |
|---|---|---|
| Skrubly compressor | Quick resize and re-encode, nothing uploaded | Browser-based, free |
| Squoosh | Comparing formats and quality side by side | Free, from the Chrome team |
| ImageOptim | Batch work on a Mac | Free desktop app |
| TinyPNG | Quick PNG and JPEG reduction | Free tier, uploads your files |
| Sharp / ImageMagick | Automated build pipelines | For developers |
Measure, don't assume
Run your page through PageSpeed Insights or WebPageTest before and after. Both name the specific images that are too large and how much they're costing. In your browser's developer tools, the Network tab sorted by size tells you the same thing in ten seconds. The metric images affect most is Largest Contentful Paint — usually the hero or the first product photo — so that's the one to watch, and it's the one that tells you whether the work paid off.
- Test on a throttled mobile connection, not your office wi-fi.
- Check the actual delivered file in the Network tab: platforms sometimes serve the original if a setting is off.
- Look at total page weight as well as individual files. Twenty well-optimised images can still add up.
Presentation still matters more than bytes
A fast page of badly lit photos will not sell anything. Consistent framing, a clean background and honest colour do more for a shop than the last 20 KB — and clean cutouts on a plain background are what make a product grid look like a real store rather than a folder of phone pictures.
Confused by HEIC files off your phone? What to convert and when.
HEIC vs JPG explained