Open your browser's DevTools on almost any website and look at the network tab. The largest single asset on the page is, in nine cases out of ten, an image. The hero photo, a product shot, an inline illustration — these files are usually larger than your HTML, CSS, and JavaScript combined.
That makes images the single biggest lever you have. They affect both SEO (alt text, file naming, image search results, schema) and Core Web Vitals (Largest Contentful Paint, Cumulative Layout Shift, total page weight). Yet they are also one of the most neglected areas of technical optimisation. Designers upload high-resolution PNGs from Figma, developers wire them in with no width or height, and editors paste filenames like IMG_4738.jpg into the CMS.
Ready to find SEO issues on any website?
Try WebSEO Auditor free — run your first audit in seconds.
Try it freeThis guide unifies image SEO and image performance into one practical workflow. By the end, you will know exactly what to fix on your site, in what order, and how to verify it.
Why Images Are the #1 Hidden SEO and Performance Lever
Images touch almost every metric Google cares about:
- Alt-text indexing: Google reads alt attributes to understand what is on the page and what each image depicts. Missing or generic alt text means lost ranking signals.
- Google Images: A surprising amount of organic traffic still arrives through image search. Descriptive filenames and alt attributes are the entry ticket.
- LCP (Largest Contentful Paint): The hero image is the LCP element on most content pages. A slow hero equals a poor LCP score, which directly affects rankings.
- CLS (Cumulative Layout Shift): Images without explicit dimensions cause the layout to jump as they load, hurting CLS and frustrating users.
- Total page weight: Unoptimised images inflate page weight by megabytes, which slows TTFB, increases data costs on mobile, and degrades the experience for everyone outside fibre internet.
Fix images and you fix five problems at once. Ignore them and your audit reports will keep showing the same orange and red bars no matter what you do elsewhere.
Image SEO Fundamentals
The basics of image SEO have not changed dramatically in a decade, but most websites still get them wrong. Here is what matters.
Descriptive File Names
Filenames like IMG_0042.jpg, DSC9382.png, or Screenshot 2026-05-23 at 14.32.png tell Google nothing. Rename your files before uploading. A descriptive filename uses hyphens, lowercase, and short relevant keywords:
- Bad:
IMG_0042.jpg - Better:
red-running-shoes-side-view.jpg - Best:
red-running-shoes-side-view-nike-air-zoom.jpg
Do not overdo it with twenty-word filenames stuffed with keywords. Aim for three to seven descriptive words.
Alt Text That Serves Two Purposes
Alt text has two jobs: it describes the image for users with screen readers, and it tells search engines what the image depicts. Good alt text does both naturally.
Write alt text as if you were describing the image to someone over the phone, while keeping in mind the topic of the page. If the image is decorative — a divider, an icon next to text that already describes the same thing — use an empty alt attribute (alt=""), not a stuffed keyword phrase.
The single most common alt-text mistake is leaving it blank on meaningful images. The second most common is stuffing it with keywords. Both signal a lack of care to search engines, and both fail screen reader users.
Captions, Titles, and Surrounding Text
Google uses the text around an image as additional context. A photo of a product placed in a paragraph that describes the product is far better understood than the same photo dropped onto a blank page. Use captions where they add value. Avoid the title attribute — it provides little SEO benefit and adds an unhelpful tooltip on desktop.
Structured Data: ImageObject
For important images — your logo, primary product photos, recipe images, article hero shots — add ImageObject structured data. At minimum include contentUrl, license, and creator. This unlocks richer image search results and helps AI systems use your images correctly.
The LCP Connection: Hero Image = LCP Element
Largest Contentful Paint measures how quickly the largest visible element finishes loading. On the vast majority of content pages, that element is the hero image — the photo at the top of an article, the product image on a PDP, or the banner on a landing page.
This means your hero image deserves treatment that is fundamentally different from the rest of the images on the page.
How LCP Is Calculated
The browser measures the time from navigation start until the largest visible element is rendered. For an image, "rendered" means the bytes have downloaded and the image is painted. The clock starts ticking the moment the URL is entered.
Google's threshold for "good" LCP is 2.5 seconds. A hero image that is 800 KB and not prioritised will frequently miss that mark on mid-range mobile devices on 4G.
Special Treatment for the Hero
Three modern techniques transform LCP performance:
fetchpriority="high"
Adding fetchpriority="high" to the hero image element tells the browser to download it before other resources. This single attribute can shave 500-1500 ms off LCP on slow networks.
Preload Hints
If your hero is selected from a srcset, the browser cannot start downloading it until the layout is calculated. A <link rel="preload" as="image" imagesrcset="..." imagesizes="..."> in the head solves this by telling the browser to fetch immediately.
Eager Loading (NOT Lazy)
Never lazy-load the hero image. loading="lazy" on an above-the-fold image is one of the most common causes of poor LCP. Eager loading is the default — make sure no global script or CMS template is overriding it for your hero.
Modern Image Formats: AVIF, WebP, JPEG XL
Photos delivered as JPEG and graphics delivered as PNG are leaving 30-70% of file size on the table. Modern formats — AVIF, WebP, and JPEG XL — produce dramatically smaller files at the same visual quality.
| Format | Typical Savings vs JPEG | Browser Support (2026) | Best For |
|---|---|---|---|
| AVIF | 50-70% | Chrome, Edge, Firefox, Safari 16.4+ | Photos, hero images, anything large |
| WebP | 25-35% | Universal (98%+) | Reliable fallback before AVIF |
| JPEG XL | 40-60% | Limited (Safari only by default) | Not yet practical for production |
| JPEG | baseline | Universal | Final fallback for ancient browsers |
Fallback Strategy with the picture Element
The cleanest delivery strategy uses <picture> with multiple sources. The browser picks the first source it can decode:
<picture>
<source type="image/avif" srcset="hero.avif">
<source type="image/webp" srcset="hero.webp">
<img src="hero.jpg" alt="..." width="1200" height="675">
</picture>
AVIF first, WebP as a fallback, JPEG as the last resort. Every visitor gets the smallest format their browser supports, with no JavaScript and no compatibility risk.
Responsive Images Done Right
A 2400 px wide hero image is overkill for a 360 px phone screen. Responsive images send the right size to each device.
srcset and sizes
The srcset attribute lists multiple resolutions. The sizes attribute tells the browser how wide the image will be displayed at different breakpoints, so it can pick the right resolution before downloading.
<img
src="hero-800.jpg"
srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="..."
width="1600"
height="900">
Why Default Browser Logic Fails Without sizes
Without a sizes attribute, the browser assumes the image will fill the viewport. For a sidebar image that is actually 300 px wide on a 1440 px screen, the browser may download the 1600 px version when the 400 px version would have been correct. The result is wasted bandwidth and slower LCP.
Always include sizes when you use srcset. Calculate the actual display width at each breakpoint and write it as a CSS-like media query list.
Lazy Loading: When To Use It and When NOT To
Native lazy loading — loading="lazy" — defers an image until it is near the viewport. This is brilliant for long pages with many below-the-fold images. It is catastrophic for the hero.
Use Lazy Loading For
- Images more than one screen below the fold
- Long-form articles with many illustrations
- Product grids beyond the initial visible area
- Footer logos and decorative images at the bottom
Never Lazy-Load
- Hero images and banners above the fold
- Logo in the header (it is always visible)
- The first product image on a PDP
- Any image that is or could be the LCP element
IntersectionObserver vs Native
Native loading="lazy" is supported everywhere and should be the default. Only fall back to JavaScript IntersectionObserver if you need fine-grained control over the threshold or want to trigger animations alongside the load.
Preventing CLS From Images
Cumulative Layout Shift measures unexpected layout jumps. Images without explicit dimensions are the most common cause. When an image loads, the browser suddenly knows its size and pushes everything below it down — every link the user was about to click jumps out of reach.
Always Set width and height
Every <img> element should have width and height attributes that match the intrinsic aspect ratio of the file. The browser uses these to reserve space before the image downloads.
Use CSS aspect-ratio
For responsive layouts where the image stretches to fill a container, pair width and height attributes with aspect-ratio in CSS. The element reserves space proportionally, and the image fills it as it arrives.
Low-Quality Placeholders
For an even smoother experience, render a tiny blurred placeholder (an LQIP or BlurHash) that is replaced when the full image loads. Frameworks like Next.js and Astro include this out of the box.
CDN and Image Optimisation Services
Optimising images by hand for every page is unsustainable. A modern stack delegates this to a service or build pipeline.
Image CDNs
- Cloudinary: Mature, feature-rich, expensive at scale. Excellent transformation URLs.
- ImageKit: Lower cost, similar features, easier onboarding.
- Cloudflare Images: Flat-rate pricing, deep integration with Cloudflare CDN, simpler API.
- imgix: Long-established, popular with media sites.
Build-Time Pipelines
For static sites, generate optimised images at build time using sharp (Node) or ImageMagick. Astro, Next.js, and Nuxt all expose image components that handle AVIF, WebP, and responsive variants automatically.
Which Should You Choose?
If your image library is large and updated frequently, use a CDN. If you have a static set of images and want maximum performance with zero per-request cost, use a build pipeline. Many sites use both — build-time for hero and product images, CDN for user-uploaded content.
A 10-Step Image Audit Checklist
- List every image on your homepage and most-trafficked pages.
- Check filenames — rename anything that looks like
IMG_orScreenshot. - Audit alt text — fill in missing ones, simplify keyword-stuffed ones.
- Identify your LCP element. Run PageSpeed Insights and verify it is your hero image.
- Confirm the hero has
fetchpriority="high"and is not lazy-loaded. - Verify all images have
widthandheightattributes. - Check the formats served — are you delivering AVIF/WebP to supporting browsers?
- Inspect the
srcsetandsizesattributes. Is the right resolution being chosen? - Test on a real mobile device on 4G, not just on your fast desktop.
- Add
ImageObjectstructured data for your most important images.
What to Fix First
If you can only do three things this week, do these:
- Fix the hero. Add
fetchpriority="high", remove lazy loading, and convert it to AVIF with a WebP fallback. This single change often moves LCP from poor to good. - Add width and height to every image. CLS often drops to near zero overnight.
- Audit alt text on your top ten pages. Write descriptive, useful alt for every meaningful image.
Everything else — CDN migration, build pipelines, JPEG XL adoption — can wait. Those three actions deliver the bulk of the benefit.
Ready to see how your images score? Run a free audit at webseoauditor.com/try to get a prioritised list of image issues across SEO, accessibility, and Core Web Vitals — with the specific files and pages that need attention.