No. Converting images to WebP addresses one variable, encoding format efficiency, out of at least three that determine an image’s contribution to Core Web Vitals: format, compression quality, and dimensions relative to how the image is actually displayed. A WebP file that is still sized for a 2000px-wide desktop hero image but served unchanged to a 375px-wide mobile viewport wastes the same bytes and decode time it would waste as a JPEG, because oversized dimensions and unnecessary bytes are a separate problem from which codec is being used. Lighthouse itself treats these as two distinct audits, “serve images in next-gen formats” and “properly size images” (efficiently encode images being a third), specifically because they measure different things and a page can pass one while failing the other.
Mechanism: format, compression, and sizing are independent variables
Format (WebP/AVIF vs. JPEG/PNG) determines how efficiently the encoder can compress a given image at a given quality level. WebP generally achieves smaller file sizes than JPEG at visually comparable quality due to more modern compression techniques, which is why web.dev’s guidance recommends next-gen formats. But this efficiency gain is measured relative to a JPEG of the same pixel dimensions and similar quality setting; it says nothing about whether that pixel dimension was the right one to serve in the first place, or whether the quality/compression setting used was reasonable.
Compression quality tuning determines how many bytes are spent encoding a given image at given dimensions. Two WebP files of the identical image and identical dimensions can differ substantially in file size depending on the quality parameter used (WebP, like JPEG, supports a lossy quality range, plus a lossless mode). A poorly-chosen high-quality setting produces a WebP file far larger than necessary for acceptable visual fidelity, and Lighthouse’s “efficiently encode images” audit specifically flags images that could be compressed further at acceptable quality, independent of which format is in use.
Responsive sizing determines whether the pixel dimensions of the delivered file match what’s actually needed for the viewport and display density it’s being shown at. An image element displayed at 400 CSS pixels wide on a standard-density display needs roughly 400 device pixels (more for high-DPI displays, following the device pixel ratio), regardless of format. If the same large master image, say 2400px wide, is converted to WebP and served as-is to every viewport, the browser downloads and decodes a WebP file several times larger than necessary for smaller viewports. The format conversion reduced the byte cost relative to what a JPEG of that same 2400px file would have cost, but it did nothing to address the fact that 2400px of image data is being sent where 400px would suffice.
Because Core Web Vitals, and LCP in particular, are driven by how long it takes to fetch and render the largest visible content element, both bytes-over-the-network and decode time matter, and both are affected independently by sizing and by compression, not just by format. A large, correctly-formatted WebP image can still be a slow LCP element if it’s oversized for the viewport or over-compressed for what’s actually needed. Format conversion alone caps the achievable improvement at “how much better does this codec compress the same oversized asset,” which is a meaningfully smaller gain than what’s available by also correcting size and quality.
A worked example of format conversion alone falling short
Picture a hero image on a landing page: originally a 2400px-wide JPEG at roughly 850KB, serving as the page’s LCP element. Converting it straight to WebP at the same dimensions and a default quality setting brings it down to about 400KB, a real improvement from the format switch alone. But the image is displayed at 600 CSS pixels wide on both desktop and mobile layouts, with no srcset in place, so every visitor, including mobile users on a 375px viewport, still downloads and decodes that full 2400px-wide, 400KB file.
Adding responsive sizing so the browser requests a 600px-wide (or appropriately doubled for high-DPI) variant instead cuts the delivered file to somewhere around 60-80KB for most visitors, and tuning the WebP quality setting for that smaller variant trims it further still. The format conversion alone got the image from 850KB to 400KB; sizing and compression together get the actually-relevant delivered bytes down by another 80% or more on top of that. If LCP is measured against the 400KB WebP-but-unsized version, the page can still land in “needs improvement” territory despite the format switch, which is the concrete version of why format conversion caps the achievable gain rather than closing it out.
Practical implication: what “sufficient” actually requires
Responsive sizing via srcset/sizes (or equivalent responsive image delivery) remains necessary regardless of format. This lets the browser choose from multiple resolution variants of the same image, requesting only the pixel dimensions appropriate to the actual rendered size and device pixel ratio, rather than downloading one fixed-size master file for every viewport. This is orthogonal to format choice: a fully responsive srcset can serve WebP variants at multiple sizes, or JPEG variants at multiple sizes, the responsiveness and the format are independent decisions, and skipping the sizing half while doing only the format half leaves a real, measurable amount of waste on the table, especially on mobile viewports which are exactly what Core Web Vitals mobile scoring weighs most heavily in practice.
Per-image quality/compression tuning remains necessary regardless of format. Applying a sensible, tested compression setting (rather than either a default that’s too conservative or a blanket “maximum quality” setting) to WebP output still matters, in the same way it mattered for JPEG. Automated tools and image CDNs that handle format conversion often also expose or default to reasonable quality settings, but “converted to WebP” and “compressed appropriately” are not automatically the same accomplishment; a pipeline that converts format without any attention to quality settings can still produce unnecessarily large WebP files.
The LCP element specifically deserves individual attention, not just a blanket sitewide format switch. Since Core Web Vitals scoring for LCP cares about one specific element on the page, a hero image, a banner, whatever qualifies as the largest contentful element, that specific image’s total delivered bytes (format, compression, and size all combined) matter far more than the average across every image on the page. A sitewide WebP conversion that improves the average image’s byte count but leaves the actual LCP candidate oversized or over-compressed for its usage won’t move the metric that’s actually being measured.
None of this means WebP conversion is wasted effort. Format conversion is a real, additive improvement, it’s just not a complete one. Lighthouse treats “serve images in next-gen formats,” “properly size images,” and “efficiently encode images” as separate, complementary audits precisely because a site can improve on one axis while still failing another, and the practical implication is to treat all three as required rather than assuming any one of them substitutes for the others. The correct mental model is that format, sizing, and compression quality are three separate levers that all affect the same outcome (bytes and decode time for the actual rendered image), and passing Core Web Vitals reliably requires attending to all three rather than treating format conversion as a single fix that closes out image optimization as a category.
