Image SEO in 2023: Compress, Name and Serve Pictures That Actually Rank

Run any page through PageSpeed Insights and nine times out of ten the biggest opportunity sitting at the top of the report is “serve images in next-gen formats” or “properly size images”, worth a megabyte or two of savings you’re leaving on the table. That gap between what you’re shipping and what you could ship is the easiest performance win on the entire site, and it’s also the one almost nobody touches after the upload button gets clicked.

What changed in 2023

The format war that used to complicate every image decision is basically over. WebP now has full support across every browser that matters, so there’s no real reason left to ship JPEG as your primary format. AVIF followed into Chrome and Firefox, and Safari added native support too, starting with Safari 16.4 in March 2023 on macOS Ventura and iOS 16.4, not the earlier Safari 16 point releases you’ll sometimes see credited in older posts. Native lazy loading, the loading="lazy" attribute, has also matured into something you can rely on without pulling in a JavaScript library, and responsive images through srcset are now handled automatically by WordPress on every upload, so you don’t have to build the fallback chains and polyfills that used to eat a whole afternoon.

What’s left is a smaller, more boring set of decisions, made once at upload time and then forgotten. That’s exactly why most sites still get them wrong: you’re thinking about the article, not the picture. The same pattern shows up on site after site I look at:

• Images that are two or three times larger than they need to be
• Files still named things like IMG_4821.jpg
• Alt text that reads like a keyword list rather than a description
• Every image on the page loading at once, even though the reader never scrolls past the second paragraph

Choosing a format

For almost everything you upload, WebP should be the default now. Depending on the compressor and quality setting, it typically shaves somewhere in the region of a quarter to a third off the file size of an equivalent JPEG, at a quality level nobody will ever notice. AVIF goes further again, often another 20 to 30 percent smaller than WebP, but it’s slower to encode and the tooling around it is still less mature, so I only reach for it on the handful of large hero images where the extra saving is worth the extra build time.

PNG still has its place, but it’s a much smaller place than most people think: real transparency, or flat colour and sharp edges like a logo or a diagram. For a photograph, a PNG will run several times the size of the equivalent WebP and won’t look any better.

Format	Best for	Size vs JPEG	Browser support	Fallback needed?
JPEG	Photos without transparency	Baseline	Universal	No
PNG	Logos, diagrams, transparency	Larger than WebP	Universal	No
WebP	Default for almost everything	Roughly 25-33% smaller	Full support in every current browser	No
AVIF	Large hero images	Smaller again than WebP	Chrome, Firefox, Safari 16.4+	Serve WebP or JPEG as a fallback via <picture>

If you do use AVIF, wrap it in a <picture> element with WebP and JPEG sources underneath so older tools, crawlers, and the odd holdout browser still get something they can render.

Compressing images without a developer

You don’t need a build pipeline to get this right, just a repeatable habit before you hit publish. The workflow I use, and the one I’d recommend to anyone running a site solo, is short:

1. Resize the image to the actual width it will display at. A 4000px camera photo squeezed into a 700px content column is wasted weight before compression even starts.
2. Run it through Squoosh or TinyPNG and export as WebP at a quality setting around 75-85. That range holds visible quality while cutting the file size hard.
3. If you’re on WordPress, let a plugin do this automatically on upload. ShortPixel, Imagify, and EWWW Image Optimizer all convert to WebP, strip metadata, and compress without you touching the file manually each time.
4. Spot-check the result at real size on a real screen, not zoomed in at 200%, before you decide the quality setting is too aggressive.

Alt text that does something

Alt text exists for people who cannot see the image, and every other benefit you get from it is a side effect of doing that job properly. The test is simple: read the sentence out loud with the alt text standing in for the picture, and check the paragraph still makes sense. If it does, you’re done. If it reads like a list of search terms, you’ve written something that helps nobody, and search engines have been discounting exactly that pattern for the better part of a decade.

• Describe what’s actually in the image, not what you wish it ranked for
• Keep it under roughly 125 characters, since that’s where most screen readers stop reading anyway
• Skip “image of” or “picture of”, the screen reader already announces that it’s an image
• Use an empty alt attribute (alt="") for purely decorative images so assistive tech skips over them
• Work your target keyword in only where it fits naturally, once, if the image is genuinely relevant to it

The other half of the job is the filename, which the crawler sees before it sees anything else, and which almost nobody bothers with. A file called red-ceramic-mug-on-desk.webp tells a machine something; a file called IMG_4821.webp tells it nothing at all, and no amount of alt text will make up for the signal you threw away at upload time. The convention that works: lowercase kebab-case, hyphens rather than underscores or spaces, three to five descriptive words, and your keyword placed once if it genuinely describes the image rather than forced in. Renaming files is boring work and it’s the cheapest thing on this whole list, so if you’re losing patience with everything else, do this and stop there.

Responsive images and lazy loading

Serving the same 2000px image to a phone and a desktop monitor is the single biggest source of wasted image weight on mobile. The srcset attribute fixes that by giving the browser several sizes of the same image and letting it pick the one that matches the actual viewport, rather than downloading the largest version every time. WordPress generates these automatically for images added through the media library, so on most sites you get this for free the moment you upload through the block editor rather than hardcoding an <img> tag by hand.

Lazy loading is the other half of the same problem: the browser fetching every image on the page immediately, including the six that sit below content nobody scrolls to. Adding loading="lazy" to images outside the first screen defers those requests until the reader actually approaches them, which shortens the initial page weight and generally helps metrics like Largest Contentful Paint. The one thing to watch: don’t lazy-load the image that appears above the fold, since deferring your hero image is what actually delays LCP rather than helping it.

Getting your images indexed

None of the above matters if Google Images never finds the picture in the first place. An XML image sitemap, either a dedicated one or image entries added to your existing page sitemap, gives Google a direct list of images to crawl rather than relying entirely on discovery through the page. Most SEO plugins (Yoast, Rank Math) add this automatically once image sitemaps are turned on, and it’s worth confirming it’s submitted in Search Console rather than assuming it’s on by default.

Beyond crawling, a handful of markup signals influence how the image is