Images and Core Web Vitals: A Practical Guide to Formats, Sizes and Loading
Images are often the heaviest part of a page. Here is how they affect Core Web Vitals and which fixes make the biggest difference.

On many pages, images make up most of the bytes a visitor downloads, and the largest image is often the element that decides how fast the page feels. This guide covers how images affect Google's Core Web Vitals and which changes help most, roughly in order of impact.
The metrics that involve images
- Largest Contentful Paint (LCP) measures when the largest visible element, frequently a hero image, finishes rendering. Google's guidance treats 2.5 seconds or less as good.
- Cumulative Layout Shift (CLS) measures unexpected movement of page content. Images without reserved space push text down when they load. A score of 0.1 or less is considered good.
- Interaction to Next Paint (INP), which replaced First Input Delay in 2024, measures responsiveness. Images affect it less directly, mainly through heavy decoding work on the main thread.
Core Web Vitals are one of many signals Google uses. Fast pages are better for visitors regardless, but speed does not outrank relevant, useful content.
Related tool: JPG to WebP Converter
Convert JPG photos to WebP in your browser, one or many at a time.
Open JPG to WebP Converter →1. Serve the right dimensions
The biggest waste is usually an image much larger than it is displayed. A 4000 px photo shown in an 800 px column carries roughly 25 times as many pixels as needed. Resize to the largest size the layout actually uses (allowing for high-density screens), and use srcset and sizes so phones get smaller versions. The Bulk Image Resizer can produce a set of sizes from your originals.
2. Pick the format by content
| Content | Good choices |
|---|---|
| Photos | AVIF or WebP, with JPG as a fallback |
| Logos, icons, simple illustrations | SVG |
| Screenshots and graphics with text | PNG or lossless WebP |
| Simple animations | Video formats or animated WebP rather than GIF |
Google's WebP documentation reports lossy WebP files 25 to 34% smaller than comparable JPEGs at equivalent quality. AVIF can often go further, but encoding is slower and support in older software is weaker. Serving modern formats with a fallback through the <picture> element covers everyone.
3. Compress sensibly
Most photos can be saved at a moderate quality setting with no visible difference at display size. Compare before and after at the size the image is shown, not zoomed in. The Image Compressor shows both side by side.
4. Reserve space to prevent layout shift
Always give images width and height attributes, or a CSS aspect-ratio, so the browser can reserve space before the file arrives. This is the most common and easiest CLS fix.
5. Load the LCP image early, and others later
- Do not lazy-load the main image at the top of the page; it delays LCP.
- Consider
fetchpriority="high"on that image so the browser requests it early. - Use
loading="lazy"for images further down the page.
6. Measure
Use PageSpeed Insights or Lighthouse to see which element is your LCP and how large your images are. Field data from real visitors, shown in PageSpeed Insights and Search Console when available, is what Google uses, so check it over time rather than chasing a single lab score.
About AVIF on Image York
Image York's converters rely on your browser's built-in encoders. Many browsers can display AVIF but cannot save it, so the JPG to AVIF page tells you when your browser is unable to encode it. WebP encoding is available in current Chrome, Edge and Firefox.
Frequently Asked Questions
What is a good LCP time?
Should every image be lazy-loaded?
Is AVIF better than WebP?
Article Written By
Ananya P
Reviewed for accuracy by the Image York team