Image Optimisation: Rank Higher, Load Faster, and Boost User Engagement

Image Optimisation for SEO, Speed and Accessibility

Image optimisation is the process of delivering each image in the right format, dimensions, quality and loading order while preserving what the image is meant to communicate. Compression matters, but it is only one part of the job. A smaller hero image can still delay the page if the browser discovers it late; a sharp image can still waste bandwidth if every phone downloads the desktop version; and an image can be fast yet inaccessible if its text alternative does not match its purpose.

The useful goal is not “make every image as small as possible”. It is to send no more image data than the visitor needs, make important images discoverable early, reserve their layout space, and give users and search engines the right context. These changes can improve page experience and image discoverability, but they do not guarantee higher rankings.

What to Fix First

Start with the image that affects the user most, then diagnose why it is slow. Recompressing every asset is rarely the best first move.

1. Find the real bottleneck: Identify the likely Largest Contentful Paint (LCP) image and check whether the delay comes from a slow document response, late image discovery, a long download or a gap between download and rendering.
2. Fix critical delivery: Keep the likely LCP image in the initial HTML, do not lazy-load it, and use priority hints or preload only when the browser would otherwise discover it too late.
3. Remove transfer waste: Find large files displayed at much smaller dimensions, especially assets repeated across templates, category pages or product listings.
4. Reserve layout space: Add correct intrinsic width and height values so the browser can calculate the aspect ratio before the file arrives.
5. Preserve meaning and access: Correct missing, misleading or keyword-stuffed alt text. Keep alt="" where an image is genuinely decorative.
6. Improve discovery selectively: Review crawlability, responsive markup, preferred-image metadata, image sitemaps and relevant structured data only where they solve a real discovery or search-presentation need.

There is no universal “good” file size for every image. The right target depends on the rendered dimensions, visual purpose, position, format, expected connection and whether the full-resolution asset is actually needed at page load.

Why Image Optimisation Matters

Performance and page experience

Images are frequent candidates for Largest Contentful Paint (LCP), the Core Web Vital that measures when the largest visible image or text block is rendered. The current “good” LCP threshold is 2.5 seconds or less at the 75th percentile of page visits, assessed separately for mobile and desktop. That is a user-experience threshold, not a promise that an image fix will improve rankings.

Oversized files, late discovery, render-blocking dependencies and inappropriate lazy loading can delay LCP. Missing dimensions can also contribute to Cumulative Layout Shift (CLS) by allowing surrounding content to move when the image appears.

Google says Core Web Vitals are used by its ranking systems, but good scores do not guarantee top rankings and relevance remains central. Treat image performance as a user-experience improvement with potential search benefits, not as a direct ranking switch. See Google’s page experience guidance.

Image discovery and search context

Google can discover images referenced in the src attribute of a standard <img> element, including an <img> fallback inside <picture>. Google does not index CSS background images. Alt text, nearby copy, captions, page titles and other page context can help Google understand what an image represents. A descriptive filename can provide a light clue, but it is not a reason to break an established image URL purely for SEO.

Image indexing and preferred preview selection are related but different tasks. A crawlable <img src="..."> helps discovery, while metadata such as primaryImageOfPage, an appropriate image property on the page’s main entity, or og:image can help indicate which representative image you would prefer Google to consider for certain previews. The choice remains automated.

Google supports image formats including JPEG, PNG, WebP, SVG and AVIF. The correct format still depends on the asset and the quality required. Review Google’s image SEO best practices for current discoverability, metadata and supported-format guidance.

Accessibility

Alt text is a replacement for the image’s information or function, not a field that must contain a keyword. The right value depends on context: informative images need a concise description of their essential meaning; linked or button images need text describing the action or destination; decorative images should normally use alt=""; and complex charts need a fuller text equivalent nearby. The W3C’s image accessibility tutorial provides a purpose-based decision framework.

Diagnose and Choose the Right Treatment

Diagnose the LCP delay before changing the file

An image can be compressed successfully without improving LCP. web.dev breaks LCP into four parts: the document’s Time to First Byte, the delay before the LCP resource starts loading, the resource’s download duration, and the delay between download completion and the element being rendered. Review the browser waterfall and performance trace before deciding which fix applies.

• The request starts late: Put the image URL in the initial HTML, remove inappropriate lazy loading, and reduce avoidable JavaScript or CSS discovery. Consider preload only when the resource cannot be made readily discoverable in markup.
• The request starts early but downloads slowly: Resize, compress, select a better format, inspect the image host and caching, and confirm the browser is not choosing an oversized responsive candidate.
• The image finishes downloading but paints late: Inspect render-blocking CSS, synchronous scripts, client-side rendering, hidden-state logic, experiments and long main-thread tasks. More compression may merely increase the post-download render delay.
• Everything starts late: Investigate the document response and redirects. A slow Time to First Byte is not an image-encoding problem.

See web.dev’s LCP optimisation workflow for the underlying timing model.

Choose formats by asset, not fashion

• Photographs and complex raster images: Test AVIF and WebP against the current JPEG or PNG. Keep the version that delivers acceptable visual quality with the lowest practical transfer cost.
• Lossless graphics and screenshots: PNG can remain appropriate where exact pixels or workflow compatibility matter, although WebP or AVIF may still be smaller. Compare the actual outputs rather than assuming one format always wins.
• Logos, icons and simple illustrations: SVG can scale cleanly without multiple raster sizes when the artwork is genuinely vector-based and safely produced.
• Existing small assets: Do not add a complicated conversion pipeline when the saving is negligible. Format conversion is worthwhile only when the delivered result is measurably better.

For a deeper format, responsive-image and CDN decision process, see ScanMySEO’s image delivery guide for WebP, AVIF, responsive images and CDNs.

Serve the size the layout actually needs

Do not rely on CSS to shrink one oversized source for every device. Generate a small set of sensible width variants, provide them through srcset, and describe the image’s expected layout width with an accurate sizes attribute. Keep a working src fallback. The browser can then select a suitable candidate for the viewport, layout and pixel density.

Treat the LCP image differently from offscreen images

• Do not apply loading="lazy" to the likely LCP image or another image visible when the page first opens.
• Ensure the critical image URL is discoverable in the initial HTML rather than inserted only after avoidable JavaScript work.
• Use fetchpriority="high" selectively for the likely LCP image when measurement shows that earlier prioritisation helps. Setting loading="eager" restores normal loading behaviour; it does not by itself assign higher fetch priority.
• Use an image preload only when the resource is otherwise discovered late, such as a necessary CSS background or dynamically inserted hero. If the image is already discoverable in the initial <img> or <picture> markup, prefer letting the browser’s preload scanner select it.
• For a responsive preload, keep imagesrcset and imagesizes aligned with the eventual srcset and sizes. Do not preload every format fallback, because that can download multiple versions and compete for bandwidth.
• Use native loading="lazy" for images that are genuinely below the fold, while ensuring they load when they enter the viewport without requiring a click, scroll handler or other user action.

Reserve space before the file arrives

Include numeric width and height attributes that express the source image’s aspect ratio. Responsive CSS can still resize the image, but the browser gains enough information to reserve space and reduce image-driven layout shifts.

Separate discovery from preferred-image metadata

A preferred-image declaration does not make an inaccessible asset indexable. First expose the meaningful image through a crawlable <img src="...">, then use metadata only when the page has a clear representative image. Google currently documents primaryImageOfPage, an image property attached to the main entity, and og:image as possible sources. Choose a relevant, representative, high-resolution image rather than a generic logo, image of text or extreme aspect ratio.

A Practical Image Optimisation Workflow

1. Inventory image problems and record a baseline
   • Use a crawl to identify image URLs, failed responses, file types, alt states, repeated assets and obvious dimension or size problems.
   • Check the homepage, a high-traffic landing page, a product or service page, a listing page and a long article rather than assuming one template represents the whole site.
   • Use PageSpeed Insights and browser developer tools to record the likely LCP element, image request timing, transferred bytes, natural versus rendered dimensions and layout shifts.
   • Keep field and lab evidence separate. Field data describes real-user experience over time where enough data exists; a lab run helps diagnose one controlled page load.
   • Remember that a crawler cannot decide whether an empty alt value is correct without understanding the image’s visual purpose, and the LCP element can change by viewport.
2. Identify which part of the delivery chain is slow
   • Check when the HTML document responds, when the image request begins, when it finishes and when the element is painted.
   • If the request begins late, fix discovery and priority before spending time on marginal compression.
   • If the request begins early but remains in flight, focus on dimensions, encoding, caching, hosting and responsive candidate selection.
   • If the file is ready but the element paints late, inspect render-blocking CSS, JavaScript execution, hidden states and client-side rendering.
3. Prioritise by repeated cost and page importance
   • Fix a delayed or oversized LCP image before a minor icon far below the fold.
   • Fix a bloated logo, card thumbnail or banner used on hundreds of pages before an equally large file used once.
   • Prioritise pages that receive meaningful traffic, support conversions or represent important search landing pages.
   • Separate defects from opportunities: a broken image or blocked URL is a reliability problem, while a modest format saving may be an optimisation opportunity.
4. Resize before compressing
   • Compare each image’s intrinsic dimensions with its largest realistic rendered width.
   • Create a few reusable variants around actual layout needs rather than exporting a different file for every device model.
   • Compress the resized versions and inspect them at the sizes users will see. Stop before text, product detail, faces or diagrams become visibly damaged.
   • For zoomable product photography, load an appropriately sized preview first and fetch the highest-resolution version only when the user requests it.
5. Select the format with a real comparison
   • Test WebP and AVIF for raster assets, but preserve a fallback or existing format where transparency, animation, editing workflow, visual quality or compatibility requires it.
   • Do not compare encoder “quality” numbers as though they are equivalent across formats. Judge the resulting image and byte size.
   • Strip unnecessary embedded metadata when it is not needed, particularly camera and location information carried into public web assets.
6. Implement responsive markup
   • Provide width candidates with srcset and an accurate sizes value that reflects the CSS layout.
   • Keep a valid src fallback, especially when using <picture>.
   • Use <picture> for art direction or format alternatives, not merely because it looks more advanced.
   • Confirm in the Network panel that mobile layouts are not still downloading the largest candidate.
7. Set loading order deliberately
   • Remove lazy loading from the likely LCP image and other immediately visible content.
   • Make the critical image discoverable in the server-rendered or initial HTML wherever practical.
   • Apply fetchpriority="high" only to the most important image after checking that it is not already being prioritised effectively.
   • Use preload as a targeted fallback for late-discovered critical images. Keep a responsive preload aligned with the eventual markup and avoid preloading multiple format alternatives.
   • Lazy-load genuinely offscreen images, but test that JavaScript-based implementations expose a real src when the image becomes visible.
8. Write alt text according to purpose
   • Informative image: Describe the information needed to understand the page, not every visual detail.
   • Functional image: Describe what the linked image or control does, such as “Search” or “View oak dining table”.
   • Decorative image: Use alt="" so assistive technology can ignore it. An empty alt value is not automatically an error.
   • Complex chart or diagram: Use concise alt text and provide the important data or explanation in nearby text, a table or a dedicated description.
   • Avoid phrases such as “image of” unless identifying the medium is genuinely important, and do not repeat surrounding text unnecessarily.

   For broader checks where accessibility and SEO overlap, see ScanMySEO’s accessibility and SEO technical checklist.

9. Make important images discoverable without manufacturing signals
   • Use a standard <img src="..."> fallback for meaningful images that you want search engines to discover.
   • Keep important image URLs crawlable and avoid blocking the image host or CDN path in robots.txt.
   • Use an image sitemap when important assets are otherwise difficult to discover, such as images reached through JavaScript or hosted on a separate verified CDN.
   • Do not copy obsolete sitemap examples containing <image:caption>, <image:geo_location>, <image:title> or <image:license>; Google has removed those tags from its image-sitemap documentation. The image URL belongs in the required <image:loc> element.
   • Where the same asset is reused across many pages, reference it with a stable URL rather than creating needless URL variants.
   • Use primaryImageOfPage, a relevant main-entity image property or og:image only to identify a genuine preferred preview image. These declarations do not replace crawlability or guarantee selection.
   • Use structured data only when it accurately represents the visible page and meets the requirements for that page type, such as Product or Recipe. Structured data does not compensate for an inaccessible image URL.
   • Use short descriptive filenames for new images. Do not rename established image URLs purely to chase a minor filename signal unless you can safely update every reference and manage the old URL.
10. Verify before rolling changes across the site
    • Retest the same page, viewport and connection conditions used for the baseline, then compare field data over an appropriate period rather than expecting an instant real-user shift.
    • Compare request start time, transferred bytes, selected srcset candidate, the LCP timing breakdown, CLS and visual quality.
    • Use Search Console’s URL Inspection rendered HTML to check that important image URLs appear in real src attributes.
    • Use the Performance report’s Image search type to monitor image clicks and impressions over an appropriate period; do not expect immediate indexing or ranking changes.
    • Test key pages with images unavailable or with assistive technology so the text alternatives still communicate the necessary meaning and controls remain understandable.

Implementation Patterns That Avoid Common Regressions

Example: a responsive, high-priority hero image

<img
  src="/images/oak-kitchen-960.webp"
  srcset="/images/oak-kitchen-480.webp 480w,
          /images/oak-kitchen-960.webp 960w,
          /images/oak-kitchen-1440.webp 1440w"
  sizes="(max-width: 720px) 100vw, 960px"
  width="960"
  height="640"
  fetchpriority="high"
  alt="Oak-fronted kitchen with a central island and pendant lights">

This example deliberately omits loading="lazy" because the image is assumed to be the likely LCP element. It also omits loading="eager" because eager is already the normal loading behaviour; fetchpriority="high" is the separate priority hint. The sizes value is only correct if it matches the real CSS layout.

Example: preload only when discovery is otherwise late

<link
  rel="preload"
  as="image"
  href="/images/oak-kitchen-960.webp"
  imagesrcset="/images/oak-kitchen-480.webp 480w,
               /images/oak-kitchen-960.webp 960w,
               /images/oak-kitchen-1440.webp 1440w"
  imagesizes="(max-width: 720px) 100vw, 960px"
  fetchpriority="high">

This belongs in the page <head> only when the critical image cannot be discovered promptly from the initial image markup. Keep the preload and eventual <img> candidates aligned. Do not add separate preloads for AVIF, WebP and JPEG fallbacks, because a supporting browser may fetch more than one file.

Example: an offscreen supporting image

<img
  src="/images/tap-installation-800.webp"
  width="800"
  height="533"
  loading="lazy"
  alt="Installer securing the tap beneath the kitchen sink">

For a decorative flourish that adds no information, the same pattern would use alt="". For a responsive supporting image, add appropriate srcset and sizes values rather than loading one large source at every viewport.

Three mistakes to avoid

• High priority or preload everywhere: Competing hints can consume bandwidth, reduce the value of prioritisation and create duplicate or stale requests.
• Lazy loading everything: Site-wide lazy loading can delay the hero or product image that users are waiting to see.
• Compressing without diagnosing or checking rendering: A smaller file is not an improvement if the request still starts late, the page cannot render it promptly, text becomes unreadable or the wrong crop appears on mobile.

Before and After: Fixing a Product Hero Image

Consider a hypothetical furniture retailer whose main product photograph is inserted by JavaScript as a large PNG CSS background. The same source is downloaded on mobile and desktop, the component delays it as though it were an offscreen image, and the page does not reserve a stable aspect ratio. Because it is a background image, it also has no text alternative and is not treated by Google as an indexable <img> image.

A performance trace shows that the image request begins only after the component JavaScript runs. Re-encoding the PNG as WebP would shorten the download, but it would not remove the larger discovery delay. A stronger implementation would:

• render the meaningful product image as an <img> element in the initial HTML;
• provide an accessible src fallback plus responsive width candidates;
• serve WebP or AVIF only where the tested output is better than the existing format;
• remove lazy loading from this likely LCP image and use high fetch priority only if measurement supports it;
• use a targeted preload only if the application architecture still prevents prompt discovery in the initial markup;
• set intrinsic width and height values with the correct aspect ratio; and
• use alt text that identifies the product and the visually important variation shown.

The improvement is not a promised ranking percentage. It is a clearer delivery chain: the browser can discover the image earlier, select a more appropriate file, reserve its space, and expose its meaning to users and search engines.

Verify the Fix Before Scaling It

Start with one or two representative templates, record a baseline, implement the changes, and repeat the same tests. PageSpeed Insights can show real-user field data where enough Chrome User Experience Report data exists and a Lighthouse lab run for controlled diagnosis. Chrome’s Network and Performance panels can then show which image was selected, when it started loading, how many bytes transferred and whether the delay occurred before, during or after the image download.

Watch for false positives while reviewing results:

• An empty alt value is correct for a genuinely decorative image; the missing attribute and an intentionally empty value are not the same.
• A large original file is not necessarily sent to users if a CDN or responsive image system delivers an appropriately sized variant.
• A high-resolution zoom image may be justified, but it does not need to be loaded before the visitor opens the zoom view.
• A fast image download does not prove the image will paint quickly if CSS, JavaScript or hidden-state logic delays rendering.
• A strong Lighthouse result does not prove that real users have the same experience, and neither a perfect score nor an image optimisation fix guarantees higher rankings.

Once the sample pages show a genuine improvement without visual or functional regressions, move the fix into shared templates or the image pipeline so future uploads receive the same treatment automatically.

Image Optimisation Checklist

• Identify the LCP element on representative mobile and desktop pages.
• Separate slow document response, late image discovery, slow transfer and late rendering.
• Do not lazy-load images visible when the page opens.
• Make critical image URLs discoverable in the initial HTML.
• Use preload only for a genuinely late-discovered critical image, and keep responsive preload candidates aligned with the eventual markup.
• Resize raster images close to their realistic rendered dimensions.
• Use srcset, accurate sizes and a working src fallback.
• Compare AVIF, WebP and the existing format using actual visual quality and byte results.
• Add correct numeric width and height values.
• Use fetchpriority="high" sparingly for the likely LCP image.
• Lazy-load genuinely offscreen images without requiring user interaction to reveal their URLs.
• Write alt text for the image’s purpose; use alt="" for decoration.
• Keep important image and CDN URLs crawlable and stable.
• Use representative preferred-image metadata, image sitemaps and relevant structured data only where they solve a real need.
• Do not use deprecated image-sitemap caption, location, title or licence tags.
• Verify request timing, transfer size, selected candidate, LCP, CLS, visual quality and rendered HTML after deployment.

Authoritative References

• Google Search Central: image SEO best practices
• Google Search Central: making lazy-loaded content crawlable
• Google Search Central: image sitemaps
• web.dev: optimising Largest Contentful Paint
• web.dev: preloading responsive images
• MDN: responsive images in HTML
• W3C Web Accessibility Initiative: images tutorial