Image optimization for SEO and speed: a practical guide

Image optimization for SEO and speed

Images are usually the heaviest part of a page, often accounting for 50-80% of total page weight on modern websites. When you ignore image optimization, you're not just hurting your Core Web Vitals and user experience—you're also leaving SEO performance on the table. In this post, we'll walk through the practical steps to compress, resize, and describe images so they work harder for both your users and search engines.

Why images matter for SEO and performance

Before diving into tactics, let's establish the baseline. Google's ranking algorithm now heavily weights page experience metrics, which include visual stability, interactivity, and loading performance. When a 4 MB JPEG causes your Largest Contentful Paint (LCP) to exceed 3 seconds, you're already losing ranking position and traffic.

Images also provide rich semantic context. A well-named, properly described image with solid alt text helps search engines understand what your page is about—which feeds into topical authority and relevance signals. And on the flip side, poor image practices create friction for users on slow networks or with accessibility needs, driving bounces and engagement issues that search engines track.

The math is simple: optimize images, and you win on speed, accessibility, and SEO at the same time.

Modern formats — AVIF and WebP are much smaller than JPEG and PNG

If you're still serving JPEG and PNG as your primary formats in 2024, you're leaving 30-50% of file size savings on the table. Modern formats like WebP and AVIF offer dramatically better compression without visible quality loss for most images.

WebP has broad browser support (over 95% globally) and reduces file sizes by 25-35% compared to JPEG at the same visual quality. AVIF is newer but increasingly supported (Chrome, Firefox, Edge, and most modern mobile browsers) and can deliver 50-60% smaller files than JPEG.

The practical approach is to serve WebP as a fallback for older browsers, with AVIF as your primary format:

<picture>
  <source srcset="diagram.avif" type="image/avif">
  <source srcset="diagram.webp" type="image/webp">
  <img src="diagram.jpg" alt="System architecture diagram showing microservices flow">
</picture>

Most image CDNs (Cloudinary, ImageKit, Fastly) support on-the-fly conversion, so you upload once in your source format and the CDN serves the optimal version based on the browser's Accept header. This removes the need to maintain multiple file versions in your repository.

If you're processing images on-server, use a tool like Sharp (Node.js) or ImageSharp (.NET) to convert during build time or as part of your asset pipeline. For example, a typical optimization workflow reduces a source JPEG from 2.4 MB to 400 KB in WebP and 280 KB in AVIF—that's a 6-8x improvement in total bytes served.

Right size — Serve dimensions close to display size with srcset

Serving a 3840×2160 desktop image to mobile users wastes bandwidth and processing power. Responsive images using srcset and sizes let you serve the right dimensions to each device, dramatically reducing waste.

Consider a hero image that's 1200 pixels wide on desktop but only 400 pixels wide on mobile. Without optimization, a user on a 375-pixel mobile screen still downloads a 1200-pixel image—wasting ~60% of the bytes.

Here's a practical setup:

<picture>
  <source media="(max-width: 640px)" srcset="hero-480w.avif 480w, hero-640w.avif 640w" sizes="100vw" type="image/avif">
  <source media="(max-width: 1024px)" srcset="hero-768w.avif 768w, hero-1024w.avif 1024w" sizes="100vw" type="image/avif">
  <source srcset="hero-1200w.avif 1200w, hero-1600w.avif 1600w" sizes="100vw" type="image/avif">
  <img src="hero-1200w.jpg" alt="Product showcase" loading="lazy">
</picture>

The browser picks the best image candidate based on the device's actual width and pixel density. A phone on a 3G network gets a smaller file; a desktop on fiber gets the full quality. The sizes attribute tells the browser what percentage of the viewport the image will occupy, enabling smart download decisions.

For real-world impact: a mid-range mobile user downloading a hero image might go from 800 KB to 150 KB—a 5x reduction that directly improves LCP and Time to Interactive.

Use build-time tools to generate these variants. Sharp can batch-convert a single source image into 6-8 optimized versions in seconds. Store them alongside your source or in a CDN bucket and reference them in your template.

Descriptive file names — dotnet-output-caching-diagram.webp beats IMG_2041.png

Search engines treat file names as a weak but real ranking signal. A descriptive file name reinforces topical relevance and helps crawlers understand image context when alt text is missing.

Instead of:

• IMG_2041.png
• screenshot-1.jpg
• image.webp

Use:

• dotnet-output-caching-diagram.avif
• postgres-query-performance-chart.webp
• aws-vpc-architecture-overview.png

Separate words with hyphens (not underscores or camelCase, which search engines treat as single words). Keep file names concise but specific—aim for 3-5 words that describe what's actually in the image.

This has a secondary benefit: developers reviewing your codebase can immediately understand what an image contains without clicking through. It's a small win for code clarity.

When hosting on a CDN with query parameters for resizing (e.g., diagram.avif?w=800&q=75), keep the base file name descriptive. The optimization params won't hurt your SEO; the base name carries the semantic weight.

Alt text — Describe the image for users who can't see it

Alt text serves two audiences: users with screen readers and search engines. Good alt text describes what's in the image in a way that makes sense even if the image fails to load.

Common mistake: stuffing keywords into alt text. alt="best dotnet caching strategies caching optimization performance" is spammy and unhelpful. Instead, write what you'd say to someone on a phone call.

Better approaches by image type:

• Diagrams and charts: Describe the structure and key relationships. alt="Architecture diagram showing three microservices (API, Worker, Cache) connected to a PostgreSQL database and Redis layer"
• Screenshots: Describe what's shown and why it matters. alt="VS Code performance profiler output showing 45% CPU usage in the serialization function"
• Logos and icons: Keep it functional. alt="Expona logo" is fine; repetitive alt text on every page for the same logo is not.
• Data visualizations: Summarize the main insight. alt="Line chart comparing page load time across four compression formats, with AVIF showing a 40% improvement over JPEG"

Make alt text 100-125 characters—long enough to be useful, short enough to be scannable. Think of it as a caption you'd read aloud on a podcast.

In your templates, don't leave alt empty or omit the attribute. Even decorative images should have alt="" (empty, not missing) to signal to assistive technology that they can be skipped.

<!-- Decorative divider -->
<img src="divider.svg" alt="" aria-hidden="true">

<!-- Content image -->
<img src="redis-memory-chart.avif" alt="Memory usage over 24 hours showing spikes during peak traffic at 14:00 UTC">

Tooling and automation

Manual optimization doesn't scale. Automate image conversion and validation in your build pipeline:

• Sharp (Node.js): Convert, resize, and optimize in-process. Handles batch operations efficiently.
• ImageSharp (.NET): Similar capabilities for C# and ASP.NET projects. Integrates well with middleware pipelines.
• ImageMagick: CLI tool for preprocessing; slower but widely available.
• CDN-based solutions: Cloudinary, ImageKit, and Fastly all support on-the-fly optimization and format selection based on Accept headers.

A practical CI/CD step: validate that all images are in modern formats, have descriptive names, and are below size thresholds. Reject PRs that introduce unoptimized images.

Common mistakes

• Skipping responsive images. Serving one size fits all means most users download larger files than necessary.
• Over-optimizing quality. A JPEG at q=60 often looks identical to q=80 on screen but is 30% smaller. Experiment to find your quality floor.
• Forgetting lazy loading. Add loading="lazy" to off-screen images to defer download until they're about to enter the viewport.
• Not setting explicit dimensions. Missing width and height attributes cause layout shift. Always include them, even with responsive images.
• Using alt text for SEO instead of usability. Write alt text for a screen reader user, not a search engine. Keyword stuffing backfires.
• Ignoring format support. Testing your picture element in older browsers (or at least in Chrome without WebP support) catches fallback issues early.

Key takeaways

• Images account for 50-80% of page weight; optimizing them has outsized impact on speed and SEO.
• Use AVIF and WebP instead of JPEG and PNG. Modern formats cut file sizes by 30-60% at the same visual quality.
• Serve responsive images with srcset and sizes to match device capabilities and network conditions.
• Use descriptive file names like redis-memory-usage-chart.avif—it helps both search engines and developers.
• Write alt text for users with screen readers; it also signals image context to search engines.
• Automate image conversion and validation in your build pipeline. Manual work doesn't scale.
• Combine modern formats, responsive sizing, and semantic metadata to improve Core Web Vitals, SEO ranking, and accessibility at once.