No matter how clean your code is or how fast your hosting is, images are almost certainly the heaviest thing on your page. Even on a well-optimised site with just a handful of images, they make up the majority of data transferred across the network. On a typical site where image optimisation has been an afterthought? Images account for 70–80% of total page weight.
That number matters for page speed, user experience, and SEO. And most advice on this topic starts and stops at "compress your images." That skips over the decisions that actually make the biggest difference. Compression matters, but it's the last step in the process, not the first.
The Number One Mistake is Uploading Images Straight From the Source
Before we get into formats or compression settings, there's one mistake that outweighs everything else. It's common with small and mid-sized businesses where the person managing the website is tech-savvy but not a web specialist.
The mistake is uploading images directly from a camera, an AI image generator, or a designer's export to the website without any steps in between.
These files are huge. They're made for print, not screens. A single unoptimised camera image can easily be 15 megabytes, sitting on a page where all the other content (text, styles, scripts) totals a few hundred kilobytes. That one image can be thousands of percent heavier than the rest of the page combined.
On a fast desktop connection, a visitor might not notice. But Google will notice. A visitor on a mobile connection will absolutely notice. They'll watch the image paint slowly from top to bottom, if they wait at all. And if you're doing this with one image, you're almost certainly doing it with others.
The same applies to AI-generated images. Tools like Midjourney, DALL-E, and Stable Diffusion produce files that aren't web-ready by default. The image is the image regardless of where it came from. It needs the same preparation before it goes on your site.
The quick check: Look at the images on your site right now. If any of them are the same file size and dimensions as when they came off the camera or out of the generator, you have a problem.
Choosing the Right Image Format
There's a simple decision tree that covers the vast majority of situations.
JPEG is your workhorse for photographs and complex images. It compresses well, it's universally supported, and it handles most standard image use cases on the web.
PNG earns its place when an image needs transparency. Think of a headshot cut out from its background, or a logo that needs to sit over different coloured sections of your site. Without transparency, you'd need separate JPEG versions for every background colour it appears against. A single PNG with a transparent background works everywhere, which is both more efficient and easier to maintain.
SVG is the right choice for icons, logos, and anything made of clean shapes and lines rather than photographic detail. An SVG isn't really an image in the traditional sense. It's a set of instructions that tell the browser "draw a line from here to here, fill this shape with this colour." That means it scales infinitely without losing quality. The same SVG looks sharp on a tiny mobile icon and a massive 4K display, and the file size stays the same regardless. Don't use SVGs for photographs or anything with complex colour transitions.
WebP and AVIF offer better compression than JPEG and PNG. But the benefits are most noticeable when you're compressing hard enough that you'd normally start to see visual degradation (blurriness, artefacts, muddy details). WebP and AVIF handle that heavy compression more gracefully.
| Format | Best for Photos | Transparency | Scales Without Quality Loss |
|---|---|---|---|
| JPEG | Yes | No | No |
| PNG | Limited | Yes | No |
| SVG | No | Yes | Yes |
| WebP / AVIF | Yes | No | No |
If your images need to stay crisp and high-quality (portfolio sites, real estate listings, product photography where customers zoom in) the savings over a well-optimised JPEG are small. You're simply not compressing hard enough for the format advantage to matter. Where these formats earn their keep is on pages with dozens or hundreds of smaller images, or where images support the content but aren't the main focus.
Why Compression Isn't Your First Move
Most SEO advice treats compression as the starting point. It shouldn't be. You'll almost always save more file weight from two other steps: correct sizing and correct aspect ratio.
Size Your Images to Their Display Dimensions
If an image is only ever displayed in a space that's 900 pixels wide, the image file should be about 900 pixels wide. Uploading a 6,000-pixel image and letting the browser scale it down means the user still downloads all 6,000 pixels of data. You can compress that oversized image aggressively and still not save as much as simply resizing it.
One thing worth knowing: high-density displays like Apple's Retina screens use two physical pixels for every display pixel. So if quality is a priority, sizing your image at roughly double the display dimensions (1,800 pixels for a 900-pixel space) accounts for this. For most cases, matching the display dimensions is enough.
Match the Aspect Ratio to the Display Context
This one is less obvious but can save a lot of wasted bandwidth. If your site displays product images as squares, but you upload an image with a 2:1 aspect ratio (twice as wide as it is tall), the site crops it to fit. But the browser still downloads the full image. Roughly 50% of that file's weight is data the user never sees. You could cut it out and the user experience wouldn't change at all, other than the page loading faster.
For sites where the same image appears in multiple contexts (a wide hero banner on one page and a small square thumbnail elsewhere) it's worth creating separate versions cropped for each use case. A hero image might be 16:9. A supporting call-to-action image of the same photo might be cropped to 1:1. Two files, each sized for their context, will always outperform one oversized file forced to do double duty.
Then Compress
Once your image is the right dimensions and the right aspect ratio, then you look at compression. And even here, the approach changes depending on context.
For hero images and large feature images where quality matters, use lossless or minimally lossy compression. The file size savings will be modest, but the image stays crisp. For smaller supporting images (product tiles, thumbnail grids, background textures) you can compress much more aggressively. The images are smaller, they're not the focal point, and slight softness won't be noticed at that scale.
There is almost never a single compression setting that works across an entire site. A blanket rule will either leave your thumbnails too heavy or turn your hero images into a blurry mess. The right approach is always contextual.
Responsive Images: Let the Browser Do the Work
Responsive images (serving different-sized versions of the same image depending on the visitor's device) used to require careful manual work using HTML's srcset attribute. The srcset tells the browser about multiple versions of an image, say an 800-pixel version and a 1,600-pixel version. The browser then picks the right one based on screen size.
If you're using a modern website builder or CMS, this is largely handled for you. Platforms like WordPress with modern builders automatically generate multiple image sizes on upload and serve them with proper srcset markup. As long as you use the platform's built-in image handling the way it was designed, responsive images just happen.
The takeaway: don't fight or bypass your platform's image system. Upload through the media library, use the built-in image components, and let responsive handling do its job.
CDNs: When They Help and When They Hurt
A Content Delivery Network (CDN) hosts copies of your site's assets on servers around the world. When a visitor loads your page, they get images from a server close to them rather than from your origin server, which could be on the other side of the planet.
Standard advice says every site should use a CDN. The reality is more nuanced.
CDNs help when your traffic comes from multiple countries. If you're an Australian business with significant US traffic, a CDN means American visitors load images from a US server instead of waiting for data to travel across the Pacific.
CDNs can hurt when your traffic is mostly local and your site doesn't get heavy, consistent traffic. Here's why. CDNs work by caching your content. When a visitor requests a page, the CDN checks whether it has a recent copy. If it doesn't (either because it's the first request or the cached version has expired) the CDN fetches the content from your origin server, caches it, then delivers it. That extra step makes the load slower than if the visitor had just hit your origin server directly.
On a high-traffic site where pages are requested many times a day, the cache stays fresh and nearly every visitor gets the fast version. On a low-traffic site where pages might only be requested a few times a week, the cache expires between visits and most users hit the slower fetch-then-cache cycle. In that scenario, a CDN is a net negative.
For a local business without international traffic or high daily visit volume, your effort is better spent on the fundamentals (image sizing, format selection, compression) than on CDN infrastructure.
Caching Basics
Caching, in simple terms, is your server storing a pre-built version of your web pages so it doesn't have to construct them from scratch every time someone visits. Most WordPress sites are built dynamically, meaning the server runs code to assemble each page on every request. Caching saves the finished result so the next visitor gets the pre-built page instantly.
For images, caching means a returning visitor's browser can load images from local storage rather than downloading them again.
One practical thing to know: if you update an image on your site and the change doesn't show on the front end, it's almost certainly a caching issue. Clearing your cache forces fresh versions to load. Just know that the first load after clearing will be slightly slower while everything rebuilds.
What Actually Moves the Needle with Image SEO
Google has a long list of guidelines around image SEO. It's easy to go down a rabbit hole. Here's what actually matters, in order of impact.
Alt Text
Of all image-related SEO work, alt text delivers the most consistent value. Good alt text describes the image for visitors who can't see it (screen readers, broken image loads) and gives search engines context about what the image contains.
The simplest way to write it: if someone couldn't see the image, how would you describe it to them? That's your alt text. "Freshly renovated kitchen with white marble countertops and timber cabinetry" is useful. "Kitchen" is too vague. Your target keyword repeated eight times is worse than useless.
One technical note: if an image is set as a CSS background rather than an HTML <img> element, it can't have alt text. If a background image is important enough to need a description, there are techniques to include it as a styled image element instead. This gives you alt text while keeping the visual layout. Small detail, but it matters for images that carry real content.
And here's an underappreciated benefit of good alt text: when an image breaks or fails to load, the alt text shows in its place. Combined with a descriptive file name, visitors can at least understand what should have been there.
Descriptive File Names
Rename image files before upload. Your camera names files "IMG_7001.jpg." Your AI tool generates something equally meaningless. Change it to something that describes the image: "marble-kitchen-renovation-brisbane.jpg." Search engines use file names as a relevance signal, and it makes your media library easier to manage over time.
Structured Data and Image Sitemaps
Structured data for images (schema markup) is useful in specific contexts. Product images with detailed schema, or images with geographic coordinates for local SEO, can provide meaningful signals. But for a general business site, the return is slim compared to getting the basics right.
Image sitemaps follow the same pattern. If your business depends on images appearing in Google Images (an art gallery, a visual portfolio) an image sitemap is worth building. For a trades business or service company, it's diminishing returns. Spend that time on sizing and alt text.
One thing you can do with structured data is embed longitude and latitude coordinates, which helps build geographic relevance for local search. Worth doing in competitive local SEO markets. Not essential otherwise.
Auditing a Site With Hundreds of Unoptimised Images
If you've built up a large library of unoptimised images, the instinct is to reach for a plugin that promises to fix everything in one click. But you need to be careful with that.
This is because bulk optimisation plugins run on your web server. Servers typically have far fewer hardware resources than even a modest desktop computer. Your server is built to serve web pages, not to process intensive image compression. Running bulk optimisation on your server can slow your site down while it works, and in bad cases, crash it.
A better process:
Start with inventory. Tools like Screaming Frog can crawl your site and report every asset loaded on each page, sortable by file size. If you have direct access to your file directories, you can sort by size there. Either way, the goal is the same: find the biggest offenders.
Don't treat every image the same. Separate your large images into groups based on how they're used. Hero images and feature photography need to stay relatively high-quality. A 1.5 to 2MB image that's meant to be viewed large and examined closely is probably fine. Compressing it into a blurry mess defeats the purpose, especially if the page has zoom functionality.
Product thumbnails, gallery images, and decorative elements are the real candidates for aggressive optimisation. They're smaller on screen, less scrutinised, and there are usually many of them. The cumulative savings add up.
Process locally, not on your server. Download the images, optimise them on your computer with a dedicated tool like ImageOptim, and re-upload. Your computer has more processing power available, which means better compression at higher quality. Even an older computer will outperform most web servers at this task.
If you have thousands of images, group them by type first. Set appropriate parameters for each group and batch-process accordingly. Five minutes spent categorising before you process will prevent the "everything looks terrible" outcome of one aggressive setting applied to everything.
The Pre-Upload Checklist
For every image going onto your site from here on, run through these steps in order.
Determine where the image will live. A full-width hero image gets treated differently from a 200-pixel product tile. The image's role on the page dictates every decision that follows.
Crop to the correct aspect ratio. Match the aspect ratio to how the image will actually be displayed. Square display, square crop. 16:9 banner, 16:9 crop. Every pixel outside the visible area is wasted data.
Resize to the correct dimensions. Scale the image to match (or modestly exceed, for Retina displays) the pixel dimensions it will be rendered at on screen. This step alone often removes more file weight than compression.
Name the file descriptively. Replace the default filename with something that describes the image. Lowercase, hyphens between words, specific.
Choose the right format. JPEG for photographs. PNG if transparency is needed. SVG for icons and logos. WebP or AVIF for lots of smaller images where heavy compression won't be noticed.
Compress for the context. Light compression for large, high-quality feature images. Heavier compression for thumbnails and supporting graphics.
Write meaningful alt text. Describe the image as you would to someone who can't see it. Be specific. Don't keyword-stuff.
The One Rule That Isn't a Rule
Don't try to set one rule for your whole site.
A per-page weight budget, a universal compression setting, a single format for everything. These blanket approaches feel efficient, but they produce mediocre results across the board. Some images end up over-compressed and ugly. Others stay too heavy because the setting was conservative enough to keep the important images looking good.
The actual rule is just to think about each image before you upload it. Where is it going? How will it be displayed? How important is its visual quality to the person viewing it? Actually, considering the image rather than dragging it straight from the source to the site is what separates a fast and polished site from a sluggish one.
It's not glamorous work. That's probably why most sites skip it. But it's one of the highest-return, lowest-cost things you can do for your site's speed, your rankings, and your visitors' experience.