Why images dominate LCP failures

Run PageSpeed Insights on any ten random pages and you will find that the LCP element is an image on at least seven of them. The browser cannot paint that element until the image bytes arrive, decode, and render. Every millisecond spent downloading an oversized JPEG or waiting for a render-blocking resource to clear is a millisecond added to your LCP score. When Google evaluates Core Web Vitals for ranking, that image is the bottleneck.

The problem is rarely a single mistake. It compounds. A 2MB hero image served as a PNG, without explicit dimensions, lazy loaded when it should be eagerly fetched, delivered from an origin server three continents away. Each layer adds latency. Image SEO is not a cosmetic concern. It is the single highest-leverage performance optimization most sites can make.

Images also affect Cumulative Layout Shift when they lack width and height attributes, they affect accessibility when alt text is missing or meaningless, and they represent an entire separate index in Google that most sites leave untapped. Getting images right touches performance, accessibility, and discoverability simultaneously.

Modern image formats: WebP, AVIF, and when to use each

JPEG has been the default for photographic images since the mid-1990s. PNG has handled transparency. Both formats are still universally supported, but they are no longer the right default choice for the web. Two newer formats offer dramatically better compression without visible quality loss.

WebP, developed by Google, consistently produces files roughly 30% smaller than JPEG at equivalent perceived quality. It supports both lossy and lossless compression, transparency, and animation. Browser support is now effectively universal. Every major browser shipped WebP support years ago, so there is no longer a practical reason to avoid it.

AVIF goes further. Based on the AV1 video codec, AVIF achieves roughly 50% smaller file sizes than JPEG for photographic content. It handles gradients and fine detail better than WebP, with fewer compression artifacts at aggressive quality settings. Browser support has matured significantly: Chrome, Firefox, Safari, and Edge all support AVIF. The main trade-off is encoding speed. AVIF encoding is substantially slower than WebP encoding, which matters for on-the-fly generation but is irrelevant for pre-built static assets.

The practical recommendation is straightforward. Use AVIF as your primary format, WebP as the first fallback, and JPEG or PNG as the final fallback. You can do this manually with the picture element or automatically through an image CDN. If you need to compress images manually before deploying, Squoosh is the best free tool. It runs entirely in the browser, supports both WebP and AVIF output, and gives you a real-time visual comparison slider so you can find the quality threshold where artifacts become visible.

Responsive images with srcset and sizes

Serving a single 2400px-wide image to every device wastes bandwidth on mobile and looks blurry when upscaled on retina displays. The srcset attribute lets you provide multiple resolutions, and the sizes attribute tells the browser which one to pick based on the current viewport width and layout.

The browser uses sizes to calculate the rendered width of the image in CSS pixels before downloading anything. It then selects the smallest source from srcset that covers that width at the device's pixel density. This selection happens before layout, which means the browser can start downloading the correct image immediately during HTML parsing.

Here is a real-world example for a hero image that spans the full viewport on mobile but only half the viewport on desktop:

<picture>
  <source
    srcset="
      /images/hero-400.avif 400w,
      /images/hero-800.avif 800w,
      /images/hero-1200.avif 1200w,
      /images/hero-1600.avif 1600w
    "
    sizes="(max-width: 768px) 100vw, 50vw"
    type="image/avif"
  />
  <source
    srcset="
      /images/hero-400.webp 400w,
      /images/hero-800.webp 800w,
      /images/hero-1200.webp 1200w,
      /images/hero-1600.webp 1600w
    "
    sizes="(max-width: 768px) 100vw, 50vw"
    type="image/webp"
  />
  <img
    src="/images/hero-800.jpg"
    srcset="
      /images/hero-400.jpg 400w,
      /images/hero-800.jpg 800w,
      /images/hero-1200.jpg 1200w,
      /images/hero-1600.jpg 1600w
    "
    sizes="(max-width: 768px) 100vw, 50vw"
    alt="Overhead view of the warehouse floor showing
         automated sorting conveyors in operation"
    width="1600"
    height="900"
    fetchpriority="high"
  />
</picture>

The sizes attribute is doing the real work here. On a 375px mobile screen, 100vw means the image renders at 375 CSS pixels. A 2x retina display needs 750 physical pixels, so the browser picks the 800w source. On a 1440px desktop where the image is 50vw, the rendered width is 720px. A 2x display needs 1440 pixels, so the browser picks the 1600w source. Without sizes, the browser has to assume the image is 100vw and will always download the largest source on wide viewports.

Getting sizes wrong is worse than omitting it. If you tell the browser the image is 50vw but it actually renders at 100vw, the browser will download an image half the size it needs and the result will be blurry. Audit your sizes values against the actual rendered widths in Chrome DevTools by inspecting the image and comparing the "Rendered size" and "Intrinsic size" fields.

The fetchpriority hint and LCP images

The fetchpriority="high" attribute is the single most underused performance optimization for images. It tells the browser to prioritize downloading this image over other resources like non-critical scripts or lower-priority images. For the LCP image specifically, this can shave hundreds of milliseconds off the LCP time because the browser no longer has to infer priority from heuristics.

Apply fetchpriority="high" to exactly one image per page: the LCP image. Applying it to multiple images dilutes the signal. Combine it with a preload link in the document head for maximum effect:

<!-- In the <head> -->
<link
  rel="preload"
  as="image"
  href="/images/hero-1200.avif"
  type="image/avif"
  fetchpriority="high"
/>

<!-- In the <body> -->
<img
  src="/images/hero-1200.avif"
  alt="Product packaging line with robotic arms
       placing labels on glass bottles"
  width="1200"
  height="675"
  fetchpriority="high"
/>

When you preload an image, the browser starts downloading it during HTML parsing, well before it encounters the img tag in the body. This is particularly effective when the LCP image is referenced in CSS (as a background-image) rather than in HTML, because CSS-referenced images normally cannot start downloading until the stylesheet is parsed and CSSOM is constructed.

Lazy loading: where it helps and where it hurts

The loading="lazy" attribute defers image loading until the image is near the viewport. For below-the-fold images, this is universally beneficial. It reduces initial page weight, decreases time-to-interactive, and saves bandwidth for users who never scroll to those images.

The mistake nearly every CMS theme and many custom builds make is applying lazy loading indiscriminately to all images, including the LCP image. When the LCP image is lazy loaded, the browser deliberately delays downloading it until after layout, which means LCP cannot complete until well after the page is otherwise interactive. This is the most common single cause of failing LCP scores on sites that have already optimized file sizes.

The rule is simple. The LCP image gets fetchpriority="high" and no lazy loading (or loading="eager" explicitly). Every other image below the fold gets loading="lazy". Images in the initial viewport that are not the LCP element should use the default eager loading and no fetchpriority attribute.

<!-- LCP image: eager load, high priority -->
<img
  src="/images/hero.avif"
  alt="Main product shot on white background"
  width="1200"
  height="800"
  fetchpriority="high"
/>

<!-- Below-the-fold image: lazy load -->
<img
  src="/images/feature-detail.avif"
  alt="Close-up of the brushed aluminum hinge mechanism"
  width="800"
  height="600"
  loading="lazy"
/>

Width and height attributes prevent layout shift

Before CSS and responsive design became dominant, every img tag included width and height attributes. Then developers stopped including them because images needed to be fluid. The problem is that without explicit dimensions, the browser allocates zero vertical space for the image during initial layout. When the image finishes loading, everything below it jumps downward. That jump is measured as Cumulative Layout Shift and it damages both user experience and search rankings.

Modern browsers have solved the fluid-width problem. When you include width and height attributes, the browser calculates the aspect ratio and reserves the correct vertical space even when the image is styled with width: 100%; height: auto;. The attributes define the aspect ratio, not the rendered size. A 1600x900 image with width="1600" height="900" styled to fill a 400px container will render at 400x225 and reserve exactly that space during layout.

The CSS aspect-ratio property achieves the same result and is the preferred approach when you cannot set HTML attributes (for instance, with CSS background images converted to img elements). But for standard img tags, width and height attributes remain the simplest and most robust solution. Check your Core Web Vitals scores after implementing this change. The CLS improvement is often immediate and dramatic.

Alt text that actually helps

Alt text has two audiences: screen reader users who need to understand the image content, and search engines that need text-based signals to index and rank the image. The best alt text serves both audiences by being descriptive, specific, and naturally written.

The most common alt text failure is not missing alt attributes. It is the keyword-stuffed alt text that reads like a spam filter. "Best running shoes 2026 buy running shoes cheap running shoes for marathon" tells a screen reader user nothing about the image and signals to Google that you are trying to game the system. Write alt text as if you are describing the image to someone on the phone. What is in the image? What distinguishes it from a similar image?

Compare these two alt text examples for an ecommerce product photo. "Shoes" is too vague. "Nike Pegasus 41 in midnight navy colorway, side profile showing the React foam midsole and rubber outsole tread pattern" is specific, descriptive, and naturally incorporates the product name and distinguishing features. It also happens to include terms someone might search for in Google Images, but that is a side effect of being descriptive, not the goal.

Decorative images that carry no informational content should use an empty alt attribute: alt="". This is not the same as omitting the alt attribute entirely. An empty alt tells screen readers to skip the image. A missing alt attribute causes screen readers to announce the file name, which is almost always a worse experience. Common decorative images include background patterns, divider graphics, and icons that are already accompanied by text labels.

Using Claude to generate alt text at scale

Ecommerce sites with thousands of product images face a real problem. Writing quality alt text for 10,000 SKU images is not realistic for a human content team, at least not within any reasonable timeline. This is where AI becomes genuinely useful, not as a gimmick but as a practical solution to a scale problem.

Claude excels at this specific task because it can look at a product image and generate alt text that is both descriptive and consistent in style. The approach is to feed Claude each product image along with a prompt that defines your alt text conventions: maximum length, required product attributes to include (name, color, material, key features), and the tone you want (descriptive and factual, not marketing copy). Claude will return structured alt text that a human reviewer can approve in batches rather than writing from scratch.

For sites running Next.js, Shopify, or any headless CMS, you can use Claude Code to build an automated pipeline that reads your product catalog, sends each image to Claude's vision capabilities, generates alt text, and writes the results back to your CMS or database. A single developer can set this up in a day, and the output quality is consistently better than the empty or auto-generated alt text most platforms default to. The key is human review. Run Claude's output through a spot-check process before publishing. Catch any inaccuracies (wrong color described, missing product variant information) and refine your prompt accordingly.

Image file naming conventions

Google reads image file names as a relevance signal. A file named IMG_4392.jpg provides zero context. A file named blue-ceramic-pour-over-coffee-dripper.jpg tells Google exactly what the image contains before alt text is even parsed.

Use hyphens to separate words, not underscores. Google treats hyphens as word separators but treats underscores as joiners, meaning coffee_dripper is parsed as a single token while coffee-dripper is parsed as two words. Keep file names lowercase, descriptive, and concise. Include the most relevant terms first. Avoid stuffing multiple variant keywords into a single file name.

For product images where multiple angles or variants exist, adopt a consistent naming pattern: product-name-color-angle.format. For example: pegasus-41-midnight-navy-side.avif, pegasus-41-midnight-navy-top.avif, pegasus-41-midnight-navy-sole.avif. This consistency helps both search engines and your own internal asset management.

Image sitemaps

Standard XML sitemaps list page URLs but do not surface images to Google. An image sitemap (or image extensions within your existing sitemap) explicitly tells Google about every image on your site that you want indexed. This is especially important for images loaded via JavaScript, CSS background properties, or lazy loading, because Googlebot may not discover them through normal crawling.

The format extends the standard sitemap namespace. Each URL entry can contain one or more image:image elements specifying the image URL, caption, title, and geographic location if relevant. Here is the structure:

<?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://example.com/products/pour-over-dripper</loc>
    <image:image>
      <image:loc>
        https://example.com/images/blue-ceramic-pour-over-dripper.avif
      </image:loc>
      <image:caption>
        Blue ceramic pour-over coffee dripper on marble countertop
      </image:caption>
      <image:title>Blue Ceramic Pour-Over Dripper</image:title>
    </image:image>
    <image:image>
      <image:loc>
        https://example.com/images/pour-over-dripper-in-use.avif
      </image:loc>
      <image:caption>
        Hot water being poured through the ceramic dripper
        into a glass carafe
      </image:caption>
    </image:image>
  </url>
</urlset>

Submit your image sitemap through Google Search Console and Bing Webmaster Tools. Monitor the "Sitemaps" report in Search Console to confirm that Google is successfully parsing your image entries and that the images are being indexed. If you see a large gap between submitted and indexed image URLs, check that the images are accessible (not blocked by robots.txt), properly formatted, and served with appropriate HTTP headers.

Image CDNs and automatic format negotiation

An image CDN does more than cache files at edge locations. Modern image CDNs like Cloudinary, ImageKit, and Cloudflare Images provide on-the-fly format conversion, resizing, and compression. You upload a single high-resolution source image, and the CDN automatically generates optimized variants based on each visitor's browser capabilities, screen size, and network conditions.

Automatic format negotiation is the most valuable feature. The CDN reads the browser's Accept header, which lists supported image formats, and returns the optimal format without any changes to your HTML. A Chrome user gets AVIF. An older Safari user gets WebP. A legacy browser gets JPEG. This eliminates the need for the picture element entirely, reducing HTML complexity and making content authoring simpler for non-technical teams.

The trade-off is cost and vendor dependency. Image CDNs charge based on transformations, storage, or bandwidth. For small sites, the free tiers are generous enough. For large ecommerce sites serving millions of product images, CDN costs become a real line item. Evaluate whether the engineering time saved by automatic optimization justifies the ongoing infrastructure cost. For most teams, the answer is yes, because manually generating and maintaining multiple format and size variants for thousands of images is not sustainable.

Auditing image performance

The best starting point for any image audit is Google Search Console. Filter the Performance report by "Search type: Image" to see which of your images appear in Google Image search results, which queries trigger them, and your click-through rates. This data tells you which images are already working and which pages have untapped image search potential.

For performance-specific audits, run your key landing pages through PageSpeed Insights. Look specifically at the LCP element identification (PSI tells you exactly which element is the LCP), any "Properly size images" or "Serve images in next-gen formats" opportunities, and the total image transfer size. Use our Image SEO Checker to evaluate alt text coverage and identify missing attributes across your pages.

Chrome DevTools' Network panel filtered to "Img" shows every image request, its format, transfer size, and loading timing. Sort by size to find the largest images and check whether they are being served in modern formats. The Performance panel's filmstrip view lets you see exactly when the LCP image appears, making it easy to identify whether preloading or priority hints would help. If your Core Web Vitals show LCP issues, start your investigation with the LCP image's network timing in this panel.

Building an automated image optimization pipeline

Manual image optimization does not scale. Every new blog post, product listing, or marketing page introduces new images that need compression, format conversion, responsive variant generation, and alt text. An automated pipeline handles this at build time or upload time, ensuring consistent quality without relying on every content author to remember the rules.

A typical pipeline works as follows. When a content author uploads an image to the CMS, a serverless function or build step triggers. It generates AVIF, WebP, and JPEG variants at multiple widths (400, 800, 1200, 1600 pixels). It compresses each variant to a target quality level. It writes the generated file paths to the content record so templates can reference them in picture elements or pass them to an image CDN. For alt text, it sends the original image to Claude, which returns a descriptive alt text string that gets stored alongside the image metadata.

Claude Code makes this pipeline straightforward to implement. You describe the pipeline requirements in plain language, and Claude Code generates the build scripts, the serverless functions, the CMS integration hooks, and the HTML template changes. For a Next.js site, this might mean configuring the next/image component with a custom loader that points to your CDN, combined with a pre-build script that generates the image variants and metadata. The entire setup, from concept to working pipeline, typically takes a day or two of implementation and eliminates image optimization as an ongoing concern. If you want a team to build and maintain this for you, our technical SEO service includes performance engineering.

Common mistakes and how to fix them

The most damaging image SEO mistake is lazy loading the LCP image. Look at your hero section. If the primary image there has loading="lazy", remove it immediately and add fetchpriority="high" instead. This single change frequently improves LCP by 500ms or more.

The second most common mistake is serving uncompressed images. Developers upload a 4000x3000 photo directly from a camera, and it ends up on the production site at 3-5MB. Even with a fast connection, decoding a massive JPEG takes significant CPU time. Resize images to the largest dimension you actually display (typically 1600px wide for full-width content images) and compress them. A well-compressed AVIF at 1600px wide should be under 100KB for most photographic content.

Missing width and height attributes cause layout shift on every page load. This is especially visible on blog and editorial pages where images intersperse with text. The text renders, the user starts reading, then every image loads and pushes the text down. Add width and height to every img element. If you are using a framework like Next.js, the built-in Image component requires these attributes and will warn you if they are missing.

Serving all images from your origin server instead of a CDN adds latency for users far from your data center. Even without a dedicated image CDN, a general-purpose CDN like Cloudflare significantly reduces image delivery times by caching at edge locations worldwide.

Finally, ignoring Google Image search as a traffic source means leaving real traffic on the table. Run an SEO audit that includes image search performance. Many sites discover that certain product images or infographics already rank in Image search and could be optimized to capture significantly more clicks with better alt text, file names, and structured data.

Putting it all together

Image SEO is not a one-time project. It is an ongoing discipline that touches every new piece of content your site produces. The fundamentals remain stable: serve modern formats, deliver responsive sizes, load above-the-fold images eagerly with high priority, lazy load everything else, always include width and height attributes, write descriptive alt text, and submit image sitemaps.

The difference between sites that do this well and sites that struggle is usually automation. Manual processes break the moment a new team member joins or a deadline gets tight. Build the pipeline once, enforce it through tooling and code review, and image optimization becomes invisible. Every new image automatically gets compressed, converted, sized, and described. Your Core Web Vitals stay green, your images rank in Image search, and your users see pages that load quickly regardless of how many images they contain.

If your site has significant image SEO debt, thousands of unoptimized images, missing alt text, no responsive variants, start with the highest-traffic pages. Fix the LCP image on your top 20 landing pages first. Then expand to category pages, product pages, and blog content. Use Claude to generate the alt text backfill and Claude Code to build the tooling that prevents the debt from accumulating again. For sites where this represents a significant engineering effort, our content strategy and technical SEO teams handle end-to-end image optimization programs.

Frequently Asked Questions