The Image Mistake That's Tanking Your Core Web Vitals
Most sites chase Core Web Vitals fixes in the wrong place: minifying scripts, trimming third-party tags, tuning server response time. On the large majority of real pages, none of that touches the actual bottleneck. The 2024 Web Almanac found images are the Largest Contentful Paint element on 83.3% of desktop pages and 73.3% of mobile pages — meaning the single biggest lever on most sites' Core Web Vitals score is a photo, not a script.
Brass-SEO's page audits find the same pattern often enough that it's worth separating from general "image SEO" advice: which image is the LCP element, what actually delays it, and the specific mistake — enabled by a well-intentioned performance setting — that makes it worse.
Quick Navigation
- Which Image Is Actually the Problem
- The Lazy-Loading Mistake
- Real Format Adoption on the Web
- The Discovery Layer: What Google Actually Reads
- The Size Rule for Rich-Result Eligibility
- Visual Search Is Already a Real Channel
- Frequently Asked Questions
Which Image Is Actually the Problem
Not every image on a page affects Core Web Vitals. Google's official LCP documentation limits which elements are even eligible to be measured as the Largest Contentful Paint: <img> elements, the image inside an <svg>, a <video> element's poster frame, elements with a CSS background-image set through url(), and block-level elements containing text. A thumbnail buried in a footer or a lazy carousel three screens down almost never qualifies — it's the largest visible image in the first viewport, on both desktop and mobile, that decides the score.
That's a narrower target than most audits treat it as. Fixing every image on a page is unfocused work; fixing the one image the browser paints first, on the device size that matters most for the audience, is the actual task. Brass-SEO's page audit identifies that specific element rather than flagging every image indiscriminately.
The Lazy-Loading Mistake
Lazy loading is good performance advice applied to the wrong element often enough that it shows up as its own line item in the research. The 2024 Web Almanac Media chapter found 9.5% of the images responsible for a page's LCP were marked with loading="lazy" — the exact setting that tells the browser to wait before requesting it.
The logic behind lazy loading is sound for images far down a page: don't spend bandwidth on something the user hasn't scrolled to yet. Applied to the largest image in the first viewport, the same setting delays the one asset the browser needs immediately to finish painting. It's the correct optimization, misapplied to the one image where it actively works against the metric it's meant to improve. The fix isn't removing lazy loading site-wide — it's excluding the above-the-fold hero image specifically, so it loads eagerly while everything below it still loads lazily.
Real Format Adoption on the Web
Format choice compounds the loading-priority issue. The 2024 Web Almanac found WebP reached 12% of all mobile image requests, up three percentage points since 2022, while AVIF reached 1.0% — nearly four times its share two years earlier. Both remain a minority of total image requests, which means most sites are still shipping JPEG or PNG files that are measurably larger than a WebP or AVIF equivalent at comparable visual quality.
Native lazy-loading itself — the loading="lazy" attribute — is used on 33% of sites, up from roughly 25% two years earlier, so adoption of the feature responsible for the LCP mistake above is also still growing. Both trends point the same direction: format modernization and lazy-loading adoption are each becoming more common, and each needs to be applied correctly rather than uniformly to avoid the exact mistake the data shows 9.5% of sites currently making.
The Discovery Layer: What Google Actually Reads
Before an image's speed matters, it has to be discoverable at all. Google's Image SEO documentation names five signals it uses to understand an image: filename, alt text, the text and captions surrounding it, the page's title and meta tags, and structured data. It also states directly that Google doesn't index CSS images — a background image applied purely through CSS, no matter how well the surrounding text describes it, is invisible to Google Images because it was never placed in an <img> element.
That last point catches sites that built a visually polished hero section using a CSS background for performance or design flexibility. The section can look identical to a real <img> tag in a browser and still be structurally absent from Google's image index.
The Size Rule for Rich-Result Eligibility
Google's structured-data documentation for Article and BlogPosting content gives a specific, checkable number most sites never verify: a recommended minimum of 50,000 total pixels — width multiplied by height — in one of three aspect ratios, 16x9, 4x3, or 1x1. A featured image below that pixel count can have flawless alt text and still fail to qualify for the enhanced visual placement Google offers eligible articles.
That threshold sits underneath the schema.org ImageObject type, which inherits contentUrl, encodingFormat, and dimension properties from the broader MediaObject type and author, datePublished, and license from CreativeWork. Getting the size and aspect ratio right is a production decision made before an image is ever uploaded, not something structured data can fix after the fact.
Visual Search Is Already a Real Channel
Google's own October 2024 disclosure states Google Lens "is now used for nearly 20 billion visual searches every month." That's a first-party company figure, not a marketing estimate, and it reframes image optimization as a search channel in its own right rather than a secondary concern behind text-based ranking.
An image that's correctly sized, properly formatted, and discoverable through the five signals Google names isn't only competing for a spot in Google Images results. It's also the raw material a camera-based or screenshot-based visual search has to work with, which makes the same optimization checklist do double duty.
Frequently Asked Questions
Is an image usually the reason a page fails Core Web Vitals?
Yes, most of the time. The 2024 Web Almanac Performance chapter found images are the Largest Contentful Paint element on 83.3% of desktop pages and 73.3% of mobile pages. For most sites, image optimization is the primary lever on Core Web Vitals, not a secondary one.
Does marking an image as lazy-loaded help or hurt performance?
It depends entirely on which image. The 2024 Web Almanac found 9.5% of LCP-responsible images were incorrectly marked lazy-loaded, delaying the exact image the browser needs first. Lazy loading helps images below the first viewport and actively hurts the one image driving LCP.
What image size does Google recommend for article rich results?
A minimum of 50,000 total pixels — width multiplied by height — in one of three aspect ratios: 16x9, 4x3, or 1x1. That's a specific, checkable production spec from Google's own Article structured-data documentation, not a general best practice.
What signals does Google actually use to understand what an image shows?
Five, all text-based: filename, alt text, the surrounding page text and captions, the page's title and meta tags, and structured data. Google's documentation also states it doesn't index CSS background images — only images placed inside an <img> element are eligible.
Every source in this post — Google's Image SEO documentation, the LCP specification, and the Web Almanac data — is fact-checked and linked in the Image SEO & Visual Search entry of the Brass-SEO Research Index. For the full image optimization walkthrough, see Image SEO: How Google Finds and Ranks Your Pictures.