13 min read · Technical SEO · Last updated July 2026
Quick answer: Images are typically the largest elements on a page and the most common cause of poor LCP (Largest Contentful Paint) scores. The optimization stack is: convert to WebP or AVIF, compress to the lowest acceptable quality, implement lazy loading for below-fold images, use
srcsetfor responsive delivery, write descriptive alt text, and serve via a CDN. Done correctly, this typically reduces image payload by 60–80%.
Introduction
Images account for roughly 60–75% of total page weight on the average web page, according to HTTP Archive data from 2025. A hero image served as a 1.2MB PNG is single-handedly responsible for more LCP failures than any amount of JavaScript or CSS inefficiency. Yet image optimization remains one of the most neglected areas of technical SEO implementation.
The compounding effect works against you: unoptimized images increase page weight, page weight increases load time, load time increases LCP, poor LCP fails Core Web Vitals, failed Core Web Vitals reduce the Page Experience ranking signal, and users who hit a slow page bounce at higher rates — reducing engagement signals. The entire cascade starts with an image that was exported at the wrong format and size.
This guide gives you the complete image optimization stack: format selection, compression benchmarks, lazy loading implementation, responsive image markup, alt text strategy, image sitemaps, and CDN delivery patterns.
What you’ll learn:
– WebP vs AVIF: when to use each, and the actual file size differences
– How to compress images without visible quality degradation
– Lazy loading implementation and which images should never be lazy-loaded
– srcset and sizes attributes for responsive image delivery
– Alt text that serves both SEO and accessibility goals
– When and how to create an image sitemap
– CDN delivery and how to configure image optimization at the edge
Table of Contents
- Why Images Are Your Biggest Page Speed Problem
- WebP vs AVIF: The Format Decision
- Compression Without Quality Loss
- Lazy Loading: The Right Way
- Responsive Images with srcset
- Alt Text Strategy for SEO
- Image Sitemap: When and How
- CDN Delivery and Edge Optimization
- Frequently Asked Questions
- Conclusion
Why Images Are Your Biggest Page Speed Problem
The numbers tell the story clearly. According to HTTP Archive data (2025), the median desktop web page transfers 2.4MB of data. Of that, approximately 980KB is images — 41% of total page weight. On mobile, the proportion is similar with a smaller total, but mobile connections are slower, making the image weight impact even more pronounced.
An unoptimized product page with 8 product images at 400KB each = 3.2MB of image data. The same images optimized to WebP with compression: approximately 560KB total — an 83% reduction with no visible quality difference to users.
For LCP specifically, images are the LCP element for over 70% of pages on the web (the LCP element is typically either a hero image, a featured product image, or a large text block — but text LCP is already fast by nature). Optimizing your LCP image directly improves your most important Core Web Vitals metric.
Three things are true about every image on your site:
1. It can be smaller in file size than it currently is
2. It could probably be in a more efficient format
3. If it’s not in the viewport on load, it shouldn’t be requested until it is
Fixing all three for every image is what image optimization means in practice.
WebP vs AVIF: The Format Decision
Two modern formats have replaced JPEG and PNG as the default for web images:
WebP — developed by Google in 2010, now supported by 97%+ of browsers. Typically 25–35% smaller than JPEG at equivalent quality for photos, and 25–45% smaller than PNG for images with transparency. Both lossy and lossless modes are available. Supported by all browsers since 2022, including Safari (which was the last holdout).
AVIF — based on the AV1 video codec, standardized in 2018. Even more efficient than WebP: 30–50% smaller than JPEG at equivalent quality, and 20–35% smaller than WebP for most images. Better handling of fine gradients and complex textures. Browser support reached ~95% in 2024. Encoding is slower than WebP (matters for automated pipelines but not for users).
The recommended approach: AVIF first, with WebP fallback, with JPEG/PNG as the ultimate fallback using the <picture> element:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Descriptive alt text" width="1200" height="600">
</picture>
The browser picks the first format it supports. AVIF-capable browsers get AVIF. WebP-capable browsers get WebP. The small remaining percentage of browsers get JPEG. This fallback chain maximizes compression savings for the majority while ensuring compatibility for all.
When to use PNG: Only when the image has hard edges, text, or icons that would degrade under JPEG/WebP lossy compression, and the image has no animated requirements. Logos, screenshots with text, flat-color illustrations. Convert these to WebP PNG mode (lossless) for typical 30–50% size reduction.
When to use GIF replacement: Replace animated GIFs with WebP (animated) or MP4 video. An animated GIF at 1.5MB becomes a WebP animation at approximately 400KB or an MP4 at approximately 150KB.
Compression Without Quality Loss
“Without quality loss” is an aspirational description — technically, all lossy compression loses some data. The practical meaning is: compressed at a quality level where no human viewer can detect the difference in a normal browsing context.
JPEG quality settings:
– Quality 85: Typical default. Usually an unnecessary starting point for web images.
– Quality 75: Industry standard for web. Looks identical to Q85 for most images. ~30% smaller.
– Quality 60–65: Acceptable for non-hero, non-product images. Not for images users examine closely.
For WebP:
– Quality 80: Equivalent to JPEG Q85 visually, ~30% smaller file.
– Quality 70–75: Equivalent to JPEG Q75, good for most web images.
For AVIF:
– Quality 60–70: Equivalent visual quality to WebP 80, often 20–35% smaller.
Tools for compression:
Command line (best for pipelines):
– cwebp -q 80 input.jpg -o output.webp — Google’s WebP encoder
– avifenc --quality 60 --speed 4 input.jpg output.avif — libavif encoder
– squoosh-cli --webp '{"quality":80}' input.jpg — Squoosh CLI
Online tools:
– Squoosh.app: Best tool for manual compression with instant visual comparison. Adjust quality slider while comparing original vs compressed side-by-side.
– Cloudflare Images: Automated optimization and AVIF conversion at the CDN level.
WordPress:
– ShortPixel: Automatic conversion to WebP/AVIF on upload, bulk optimization, CDN delivery. Starts at $4.99/month.
– Imagify: Similar to ShortPixel, integrates with WP Rocket.
– Smush: Free tier compresses up to 50 images/month.
E-commerce specific:
– Shopify: Built-in WebP conversion (Shopify converts uploaded images to WebP automatically). No configuration needed.
– WooCommerce: Requires a plugin (ShortPixel or Imagify) for WebP conversion.
Lazy Loading: The Right Way
Lazy loading delays the download of below-fold images until they’re about to scroll into the user’s viewport. Since these images aren’t needed immediately, not downloading them upfront reduces initial page weight and allows critical above-fold resources to load faster.
The HTML implementation:
<!-- Above-fold images: NO lazy loading -->
<img src="hero.webp" alt="Hero image" width="1200" height="600" fetchpriority="high">
<!-- Below-fold images: lazy load -->
<img src="product-1.webp" alt="Product name" width="400" height="400" loading="lazy">
<img src="product-2.webp" alt="Product name 2" width="400" height="400" loading="lazy">
The loading="lazy" attribute is supported natively in all modern browsers. It tells the browser: “Don’t download this until the user is about to scroll to it.” For a product listing page with 20 products, this can eliminate 15+ unnecessary requests on initial load.
Critical rule — never lazy-load your LCP image. Your LCP image is the largest element in the viewport on initial load. It’s the one image that must load immediately. Adding loading="lazy" to your hero image or first product image delays the most important visual element and directly increases LCP time.
Identify your LCP image by running PageSpeed Insights — it shows which element is the LCP element and how long it took to load. That specific image should have fetchpriority="high" instead of loading="lazy".
The threshold — when does lazy loading trigger? By default, the browser preloads lazy images when they’re within ~1.5 screen heights below the viewport on desktop (varies by browser). This means images 1–2 screens below the fold start loading before users reach them, creating a smooth experience.
JavaScript lazy loading (older browsers): The native loading="lazy" attribute covers 97%+ of browsers in 2026. For the rare case requiring JavaScript lazy loading (older enterprise environments), libraries like Intersection Observer with data-src attributes are the standard approach. For modern web development, native is sufficient.
Responsive Images with srcset
The srcset attribute allows you to specify multiple image versions at different resolutions, and the browser selects the appropriate size based on the device’s screen size and pixel density. A 2560px hero image served to a mobile user with a 390px viewport is 6x more data than necessary.
Basic srcset for resolution switching:
<img
src="hero-800.webp"
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w, hero-1600.webp 1600w"
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 80vw, 1200px"
alt="Hero description"
width="1200"
height="600"
fetchpriority="high"
>
How the browser chooses:
1. Reads the sizes attribute to determine the display size at current viewport
2. Matches against srcset to find the smallest image that’s large enough for the display size at the screen’s pixel density
3. Downloads that version only
On a 375px-wide mobile device with 2x pixel density (Retina), the effective needed size is 750px. The browser selects hero-800.webp — the smallest image above 750px. On a 1440px desktop with 1x display, it selects hero-1600.webp.
sizes attribute guidance:
– Full-width images: sizes="100vw"
– Images constrained by layout: sizes="(max-width: 768px) 100vw, 800px" (100% width on mobile, 800px max on desktop)
– Product thumbnails: sizes="(max-width: 480px) 50vw, 200px" (50% width on mobile, 200px on desktop)
width and height attributes are required. Always specify explicit width and height on <img> tags. This allows the browser to reserve the correct space for the image before it loads, preventing Cumulative Layout Shift (CLS) — which is another Core Web Vitals metric.
Alt Text Strategy for SEO
Alt text serves two masters: accessibility (screen readers describe the image to visually impaired users) and SEO (search engines read alt text to understand image content). Good alt text serves both.
The core rule: Describe what the image actually shows, in natural language, with relevant keywords where they fit naturally. Don’t keyword-stuff. Don’t write the same alt text for every image.
Good alt text examples:
– Product image: alt="Merino wool running socks in black, size M-L, folded pair" — descriptive, specific, includes the product name and relevant attributes
– Blog post image: alt="Google Search Console Coverage report showing 247 indexed pages" — describes what the screenshot shows, includes the tool name
– Team photo: alt="Ignited Nepal SEO team at a client strategy session in Kathmandu" — describes the people, the activity, and the location
Bad alt text examples:
– alt="image" — describes nothing
– alt="socks socks merino socks running socks buy socks" — keyword stuffing
– alt="" — empty (correct only for decorative images)
Decorative images: Images that are purely decorative — dividers, background patterns, icons that have adjacent text labels — should use alt="" (empty alt attribute, not missing). This tells screen readers to skip the image, and tells search engines there’s no content to index.
Image file names: Google reads image file names as a secondary signal. hero-merino-running-socks-black.webp is better than img-0047.webp. Rename images before uploading, using hyphens between words.
Image titles: The title attribute on images shows a tooltip on hover. Google uses it as a very minor signal. Include it when the image title would differ meaningfully from the alt text, but don’t prioritize it over other optimizations.
Image Sitemap: When and How
An image sitemap (or image sitemap extension within your main sitemap) tells Google about images it might otherwise not discover, particularly images loaded via JavaScript or CSS background images.
When you need an image sitemap:
– Your site relies on image search traffic (photography, e-commerce, real estate)
– Images are loaded via JavaScript (lazy-loaded with JavaScript libraries, loaded on carousel interaction)
– Images are important for your business and you want to maximize their indexing
When you don’t need one:
– All your images are in standard <img> tags in your HTML
– Images are not a significant traffic source for your niche
Format:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://yoursite.com/products/merino-running-socks</loc>
<image:image>
<image:loc>https://yoursite.com/images/merino-socks-black-pair.webp</image:loc>
<image:title>Merino Wool Running Socks - Black</image:title>
<image:caption>Premium merino wool running socks, featuring arch support and moisture management</image:caption>
</image:image>
<image:image>
<image:loc>https://yoursite.com/images/merino-socks-on-runner.webp</image:loc>
<image:title>Runner wearing Merino Wool Running Socks</image:title>
</image:image>
</url>
</urlset>
For WordPress, Rank Math and Yoast SEO both automatically generate image sitemaps that include images from post content and featured images. Enable in their sitemap settings.
CDN Delivery and Edge Optimization
A CDN (Content Delivery Network) serves your images from geographically distributed edge servers, reducing latency for users far from your origin server. But modern image CDNs go beyond delivery — they also perform real-time format conversion, resizing, and compression at the edge.
Cloudflare Images: Stores and delivers images from Cloudflare’s network. Automatic WebP/AVIF conversion based on browser support. On-the-fly resizing via URL parameters. Cost: $5/month for up to 100,000 images + $1 per 100,000 delivery requests. Integrates with Cloudflare’s existing CDN.
imgix: More feature-rich image CDN with URL-based real-time transformations: image.imgix.net/photo.jpg?w=800&fm=webp&q=75. Handles responsive images at scale. Used by large e-commerce sites. From $10/month.
Cloudinary: Full media management platform with auto-format, auto-quality, and real-time transformations. Free tier allows up to 25GB storage. From $89/month for commercial use.
Bunny.net Optimizer: Add-on to Bunny CDN. WebP conversion, resizing, compression at edge. From $9.50/month. Very cost-effective for traffic-heavy sites.
The edge optimization benefit for SEO: When your CDN converts JPEG to AVIF automatically and serves appropriately-sized images for each device, you get these performance benefits without any changes to your website code or content management workflow. Upload a 2000px JPEG once; the CDN delivers AVIF at 400px to mobile and AVIF at 1600px to desktop — automatically.
Key takeaway: Image optimization is a multiplicative gain across every page load metric. Format conversion (WebP/AVIF) alone typically delivers 40–60% file size reduction. Add responsive images, lazy loading, and CDN delivery, and you’re routinely achieving 70–85% total image payload reduction.
Frequently Asked Questions
Should I convert all existing images to WebP/AVIF, or only new ones?
Both, eventually. For new uploads, set your workflow to output WebP/AVIF automatically — via a plugin (ShortPixel, Imagify) or CDN. For existing images, run a bulk conversion via your plugin’s bulk optimization feature. Prioritize converting images on your highest-traffic pages first. An e-commerce client converted 12,000 product images from JPEG to WebP in 2 hours using ShortPixel bulk mode, reducing total image payload across the site by 54%.
Does lazy loading affect SEO? Can Google see lazy-loaded images?
Google renders pages using JavaScript and can see natively lazy-loaded images (loading="lazy"). Google waits for lazy images to appear in the viewport during its rendering process. So lazy loading doesn’t hide images from Google. JavaScript library-based lazy loading (non-native implementations) can sometimes cause Google not to see images if the library doesn’t fire during Googlebot’s rendering window.
What is the maximum file size for images used in Google Image Search?
There’s no published maximum, but Google recommends images be at least 1200px wide for Google Discover inclusion and for Article schema’s image property to generate rich results. For practical optimization, serve images at the largest size they’ll be displayed at (with appropriate srcset for smaller viewports). A hero image at 1600px at WebP Q80 quality typically comes in at 120–250KB — well within any practical limits.
Does alt text help rank in Google Images?
Yes. Alt text is the primary signal Google uses to understand what an image depicts. Pages with keyword-relevant alt text rank in Google Image Search for those keywords. For e-commerce sites, this can generate meaningful additional traffic from product image search queries.
Is it worth implementing srcset on a low-traffic site?
Yes, for two reasons: (1) it’s straightforward to implement and most CMSs handle it automatically (WordPress generates srcset by default); (2) Core Web Vitals scoring applies regardless of traffic level — a poorly-optimized low-traffic site will still fail CWV assessments and miss any ranking benefit from good Page Experience.
Conclusion
Image optimization is the highest-leverage performance improvement available to most websites. The effort is low (one afternoon for a proper setup), and the gains are compounding: smaller images improve page weight, page weight improves load time, load time improves LCP, LCP passes Core Web Vitals, and every page on the site benefits simultaneously.
The checklist above covers the complete implementation. Start with the “High Priority” items: WebP/AVIF conversion, lazy loading, fetchpriority="high" on your LCP image, and explicit width/height attributes. Those five changes alone will improve LCP on most sites by 30–50%.
Then add srcset for responsive images, descriptive alt text, and CDN delivery. The total result: dramatically better Core Web Vitals scores, better user experience, and images that are now discoverable and rankable in Google Image Search.
Let Ignited Nepal Handle This
→ Request a Free Technical SEO Audit
Written by the Ignited Nepal SEO team. We build organic search systems for businesses across Nepal, Australia, UAE, USA, UK, and beyond. ignitednepal.com