No, format conversion alone isn’t sufficient, and the question actually bundles two distinct concerns that need to be separated to answer honestly. First: converting to WebP or AVIF doesn’t by itself guarantee Core Web Vitals compliance, because format is only one variable in total transferred and decoded bytes, responsive sizing and compression quality still matter independently. Second, and more specific to “image SEO” as distinct from page-speed compliance: for Google Images specifically, visual quality is a real factor in image search relevance and display, so compressing aggressively enough to visibly degrade an image in pursuit of Core Web Vitals byte savings can work against image search performance even while it helps page-speed metrics. The practical answer isn’t zero compression or maximum compression, it’s a quality floor that satisfies both concerns rather than optimizing one at the expense of the other.
The Core Web Vitals half
Web.dev’s documented guidance on image optimization treats “serve images in next-gen formats” and “properly size images” as separate, complementary audits, not a single combined check, precisely because they address different sources of wasted bytes. Converting a correctly-sized image from JPEG to WebP or AVIF typically reduces file size at equivalent visual quality, which helps. But if the image itself is still being served at a resolution larger than the space it’s actually displayed in (a 2000px-wide image displayed in a 400px container, common when responsive srcset/sizes markup is missing or incomplete), the format conversion doesn’t address that waste at all, the oversized image is still oversized, just in a more efficient format. Since LCP specifically depends on the total bytes that need to be transferred and decoded for whatever the largest contentful element is, if that element is an image, both format efficiency and correct sizing need to be addressed together. Format conversion without responsive sizing is real progress, but it’s not the whole fix, and treating it as sufficient leaves a genuine, measurable performance gap on the table.
The image-search-quality half
This is the part of the question specific to image SEO rather than general Core Web Vitals compliance. Google’s Image SEO best practices documentation discusses image quality as a factor relevant to how images perform in Google Images and image-inclusive search results, visual clarity and quality contribute to relevance and user experience judgments the same way page content quality does for text search. This creates a genuine tension with the instinct to compress as aggressively as possible purely to minimize file size for Core Web Vitals purposes: an image compressed hard enough to show visible artifacting, blurring, or banding may load faster, but if it displays as noticeably degraded to a user (and, plausibly, contributes to Google’s own quality assessment of the image), it works against the image-search-relevance side of the equation even as it helps the page-speed side.
Why the two concerns need a balanced answer rather than picking one
It would be inaccurate to conclude “compress as little as possible to protect image quality,” because that ignores real, well-documented Core Web Vitals costs of oversized or poorly compressed images, LCP genuinely suffers from unnecessarily large image payloads, and that’s not a minor or theoretical concern. It would be equally inaccurate to conclude “compress as aggressively as possible since Core Web Vitals is what’s measured and rewarded,” because that ignores the documented role of visual quality in image search performance specifically. The honest, non-fabricated answer avoids asserting a specific compression ratio or quality-percentage threshold as “the” correct number, no such universal figure is documented by Google, appropriate compression levels vary by image content, format, and use case, but the direction of the guidance is clear: find the quality floor below which visible degradation begins for a given image, and compress up to that floor, not past it, rather than treating either “smallest possible file” or “highest possible quality” as the unconditional goal.
A hypothetical illustration of overcorrecting
Consider a hypothetical outdoor apparel retailer, “Timberline Trailwear,” whose site speed team converts the entire product catalog to AVIF at an aggressive compression setting purely to chase a Core Web Vitals score target, without a visual quality check as part of the rollout. LCP scores improve noticeably across the board. A few weeks later, someone on the merchandising side notices that image search referral traffic for the jacket category has softened, and a spot-check shows the compressed jackets displaying visible banding and blurred fabric texture at the sizes shoppers actually view them in. In this scenario, re-encoding just the primary product images at a slightly higher quality floor, while leaving thumbnails and decorative imagery at the more aggressive setting, could plausibly recover much of the visual clarity that matters for image search without meaningfully giving back the Core Web Vitals gains the format switch achieved.
Practical guidance
Address both dimensions rather than assuming one solves the other: convert to next-gen formats (WebP broadly supported, AVIF where beneficial and decode performance is acceptable for target devices) as a genuine improvement, but pair this with actual responsive image markup (srcset/sizes) so images are never transferred larger than their actual display size across device tiers, and use a compression quality setting that’s been visually checked (not just measured by file size) to ensure the image doesn’t show obvious artifacting at the sizes and contexts it’ll actually be viewed in. Testing individual key images (particularly likely-LCP hero images and prominent product/content images likely to appear in image search) at actual target quality settings, rather than applying one blanket aggressive compression preset site-wide without checking the visual result, is the practical way to find that balance rather than guessing at a universal number.
