How to Optimize Images
for the Web

Why Image Optimization Matters for SEO

Google uses Core Web Vitals as a ranking factor. The most image-sensitive metric is Largest Contentful Paint (LCP) — it measures how long it takes for the biggest visible element on a page to load. For most pages, that element is an image. A poor LCP score directly hurts your search ranking.

Beyond page speed, optimized images also appear in Google Image Search, driving additional organic traffic. Images with descriptive alt text help search engines understand your page's topic and improve your rankings for related queries.

Choosing the Right Format: AVIF, WebP, or JPEG

Modern browsers support multiple image formats, each with different trade-offs. The best strategy is to offer the best format first using the <picture> element and let the browser pick what it supports.

AVIF — The Best Compression Available

AVIF (AV1 Image File Format) delivers the smallest file sizes of any format — typically 50% smaller than JPEG and 20% smaller than WebP at equivalent visual quality. It supports HDR color, wide color gamut, and both lossy and lossless compression. Browser support is now above 90% globally. The trade-off is slower encoding, which is why server-side tools like Sharp (used by ImgForge) are ideal.

WebP — The Safe Modern Choice

WebP offers 25–35% smaller files than JPEG with near-universal browser support (Chrome, Firefox, Safari, Edge). It supports transparency (replacing PNG for many use cases) and animation (replacing GIF). If AVIF is unavailable, WebP is your next best option.

JPEG — The Universal Fallback

JPEG remains the most compatible format, supported by every browser and device built in the last 25 years. Progressive JPEG (encoding that loads a blurry version first) improves perceived performance. Always include JPEG as your final fallback in the picture element.

PNG — For Transparency and Lossless Detail

Use PNG only when you need pixel-perfect lossless quality or transparency that AVIF/WebP can't handle in your target browsers. PNG files are large and should not be your primary format for photographs.

Responsive Images with srcset and sizes

Serving a 1920px desktop image to a mobile screen wastes bandwidth and slows your page. The srcset and sizes attributes tell the browser which image to load based on the viewport width and device pixel ratio.

The srcset Attribute

The srcset attribute lists image variants with their widths using the w descriptor. The browser selects the best match — it never downloads more than one.

<!-- List variants with their actual pixel widths -->
<img
  src="hero.jpg"
  srcset="hero_mobile_480.jpg 480w,
          hero_mobile_960.jpg 960w,
          hero_tablet_1024.jpg 1024w,
          hero_desktop_1920.jpg 1920w"
  alt="Hero image"
>

The sizes Attribute

The sizes attribute tells the browser how wide the image will render at each breakpoint — before CSS loads. Without sizes, the browser assumes the image is 100vw (full viewport width) and downloads the largest available variant.

<!-- Tell the browser the rendered width at each breakpoint -->
sizes="(max-width: 480px) 480px,
       (max-width: 1024px) 1024px,
       1920px"

Retina / High-DPI Displays

Devices with high DPI screens (like iPhone Retina displays) have a device pixel ratio of 2x or higher. To serve crisp images on these screens, generate a 2x variant for mobile at double the rendered width. For example, if mobile renders at 480px, your 2x variant should be 960px wide. ImgForge generates mobile @2x variants automatically.

The HTML <picture> Element Explained

The <picture> element is the standard way to serve different image formats to different browsers. Unlike srcset (where the browser chooses freely), <picture> lets you enforce format priority — the browser uses the first <source> it supports.

<!-- ImgForge generates exactly this pattern -->
<picture>
  <!-- Best format: AVIF (smallest file size) -->
  <source
    type="image/avif"
    srcset="hero_mobile_480.avif 480w,
            hero_mobile_960.avif 960w,
            hero_tablet_1024.avif 1024w,
            hero_desktop_1920.avif 1920w"
    sizes="(max-width: 480px) 480px,
           (max-width: 1024px) 1024px,
           1920px">

  <!-- Fallback: WebP (wide support) -->
  <source
    type="image/webp"
    srcset="hero_mobile_480.webp 480w,
            hero_mobile_960.webp 960w,
            hero_tablet_1024.webp 1024w,
            hero_desktop_1920.webp 1920w"
    sizes="(max-width: 480px) 480px,
           (max-width: 1024px) 1024px,
           1920px">

  <!-- Final fallback: JPEG (all browsers) -->
  <img
    src="hero.jpg"
    srcset="hero_mobile_480.jpg 480w, ..."
    sizes="(max-width: 480px) 480px, ..."
    alt="Descriptive alt text here"
    width="1920"
    loading="lazy"
    decoding="async">
</picture>

The width and implicit height attributes on <img> are critical for preventing Cumulative Layout Shift (CLS) — another Core Web Vitals metric. They allow the browser to reserve space for the image before it loads.

Lazy Loading vs. Eager Loading

Not all images should load the same way. The correct loading strategy depends on whether the image is visible when the page first loads.

Above the Fold: Eager + Preload

Your hero image or any image visible in the initial viewport should load as fast as possible. Use loading="eager" and fetchpriority="high", plus a <link rel="preload"> in the <head> to start downloading before the browser even parses the <body>.

<!-- In <head> — preload the hero image -->
<link
  rel="preload"
  as="image"
  href="hero_desktop_1920.avif"
  imagesrcset="hero_480.avif 480w, hero_1024.avif 1024w, hero_1920.avif 1920w"
  imagesizes="(max-width: 480px) 480px, (max-width: 1024px) 1024px, 1920px"
  fetchpriority="high">

<!-- In <body> -->
<img ... loading="eager" fetchpriority="high">

Below the Fold: Lazy Loading

Every image that is not visible in the initial viewport should use loading="lazy". This defers the download until the user scrolls near the image, saving bandwidth and improving initial page load speed. All modern browsers support native lazy loading — no JavaScript required.

Stripping EXIF Metadata

EXIF (Exchangeable Image File Format) data is embedded in photos by cameras and smartphones. It can contain:

• GPS coordinates — exact location where the photo was taken
• Device information — camera make, model, and serial number
• Timestamps — exact date and time of capture
• Copyright notices — embedded rights information

EXIF data adds unnecessary bytes to your files (typically 5–130 KB per image) and poses a privacy risk — uploading an unstripped photo to your website reveals your location and device to anyone who downloads the file.

ImgForge automatically strips all EXIF data from every generated variant while preserving the sRGB color profile to ensure colors render correctly across devices.

How to Use ImgForge Step by Step

ImgForge is a free, browser-based image optimization tool. Here's how to go from a raw photo to production-ready, Lighthouse-optimized HTML in under a minute.

Final Image Optimization Checklist

Before publishing any page with images, verify each of the following:

• ✅ Format: AVIF or WebP served to modern browsers; JPEG as fallback
• ✅ srcset: Multiple widths provided covering mobile, tablet, and desktop
• ✅ sizes: Breakpoints match your actual CSS layout widths
• ✅ Retina: 2× variant provided for mobile (960px if mobile renders at 480px)
• ✅ Alt text: Descriptive, under 125 characters, no keyword stuffing
• ✅ Width/height attributes: Set on every <img> tag to prevent CLS
• ✅ Loading: eager + fetchpriority="high" for LCP image; lazy for all others
• ✅ Preload: <link rel="preload"> in <head> for above-fold images
• ✅ EXIF stripped: No GPS, device, or personal metadata in output files
• ✅ Color profile: Converted to sRGB for consistent cross-device rendering
• ✅ decoding="async": Set on all non-critical images