Core Web Vitals and Images: What Actually Moves the Numbers

LCP and CLS usually move when the images change, and script work often does not. Resize Image and Compress Image act on the file the browser actually paints. Deferring JavaScript might shave 80 ms off Interaction to Next Paint while a 2.4 MB JPEG hero, still at camera resolution, remains the LCP element. Resizing and compressing that hero can drop LCP by 1.8 seconds. On content and tool sites, images are usually the heaviest files on the critical path. Fix those before you spend a sprint on smaller script wins.

Core Web Vitals describe what people feel when a page loads, settles, and responds. They are lab and field measurements of that, with specific thresholds in the tools below.

Where images sit in the three vitals

Google's Core Web Vitals use three measurements:

| Metric | What it measures | Image connection | |--------|------------------|------------------| | LCP (Largest Contentful Paint) | When the main visible content appears | Often a hero image, product photo, or large illustration | | CLS (Cumulative Layout Shift) | Unexpected layout movement | Missing width and height, late-loaded fonts over images, dynamic ad slots | | INP (Interaction to Next Paint) | Responsiveness to input | Less about the image file itself. Decoding several huge images on the main thread can still add cost on a low-end device |

LCP and CLS are where image work and the vitals overlap. Search Console's Core Web Vitals report groups URLs by status. Fixing image delivery can move a batch of URLs from "Needs improvement" to "Good."

LCP: treat the LCP element as its own file

Lighthouse names the element that triggered LCP. On Vertex Solutions tool pages, that is often the workspace preview or a category hero. On a blog post, it is often the featured image or the first large graphic in the article.

Steps that reliably help LCP:

1. Find the LCP element. PageSpeed Insights field data, when it exists, beats a guess.
2. Resize to the display size. A 4000 px image shown at 1200 px wastes bytes and decode time. Resize images for web covers the display-size math.
3. Compress after you resize. The two steps do different jobs. Use Compress Image. How image compression affects quality shows where artifacts show up.
4. Use a modern format for photos. WebP Converter is the conversion step. WebP vs JPG covers the cases where JPG still fits.
5. Preload only the LCP image: <link rel="preload" as="image" href="..." fetchpriority="high">.
6. Do not put loading="lazy" on an above-the-fold hero. That delays the fetch for the metric you are trying to improve.

Retina screens need a modest oversize, typically 1.5× to 2× the display width. A 4× file overserves the screen. Retina images 2x explained covers sharpness against transfer size.

CLS: reserve the box before the image arrives

Layout shift is what people notice, and it adds up in CLS. An image with no dimensions is a common cause.

<img
  src="/blog/hero.webp"
  alt="Diagram of Core Web Vitals image pipeline"
  width="1200"
  height="630"
  fetchpriority="high"
/>

• Set width and height in HTML so the browser reserves the aspect ratio.
• Use CSS max-width: 100%; height: auto; so the image can shrink without dropping that ratio.
• For responsive images, aspect-ratio in CSS, or sizes plus srcset with a consistent ratio, keeps the box from jumping.
• Do not inject an image above existing content with no reserved space. Late ads and consent banners do this often.

Crop Image helps when a card or an Open Graph preview needs a fixed ratio. See image aspect ratios for web.

INP and images

INP replaced First Input Delay as the responsiveness metric. Images rarely dominate INP unless:

• The main thread is busy decoding several huge images at once
• A carousel attaches heavy touch handlers without passive listeners
• A client-side image editor sits on the path of the interaction you are measuring

On a brochure site or a blog, INP work is mostly a JavaScript budget. Still cap decode cost. Twelve uncompressed gallery images on first paint is a lot of decode for a page that has not been touched yet.

Formats, past "use WebP"

Format changes bytes and decode time:

• JPEG: photos, lossy, works almost everywhere
• PNG: screenshots, UI, transparency. Large if you use it for photos
• WebP: a strong default for web photos. See when to use WebP instead of PNG
• AVIF: often smaller still. Test a fallback for older browsers

PNG vs JPG guide still applies when a design tool exports the wrong format.

A picture element for a critical hero:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="..." width="1200" height="630" />
</picture>

One optimized fallback beats three variants that were never resized.

CDN, cache, and headers

An image with no cache headers downloads again on every visit. Set:

• A long Cache-Control on fingerprinted names such as hero.a1b2c3.webp
• immutable when the filename changes on each deploy
• CDN edge caching if the audience is spread out

Vertex Solutions static assets follow that pattern. A content hash in the filename allows a long cache without serving a stale UI.

Responsive images without sending the desktop file

srcset and sizes tell the browser which file to fetch:

<img
  src="photo-800.webp"
  srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="Product detail on white background"
  width="800"
  height="600"
/>

A phone should not download the desktop hero. In DevTools, filter the Network tab to Img and compare transferred kilobytes across viewport sizes.

Compression and the rest of image SEO

A smaller image helps LCP. It does not replace alt text, a descriptive filename, or structured data. Alt text that helps SEO covers accessibility and retrieval.

Image compression for web is the workflow used here before publishing: resize, format, compress, then check in staging.

Mistakes called out in common mistakes when resizing images:

• Compressing before resizing (wrong order)
• Upscaling a small source for "retina," which blurs the image and adds no detail
• Serving a photograph as PNG because "PNG is higher quality"

Measure before and after

1. Record PageSpeed or Lighthouse on the production URL
2. Note the LCP element and its transfer size
3. Change only the images
4. Retest the same URL with the same throttling
5. Watch Search Console's Core Web Vitals report for field data. That window is 28 days

Lab scores move immediately. Field data lags. Plan on about a month of observation for a high-traffic page.

What editors upload

Editors upload camera originals unless the CMS stops them. Constrain the source:

• A maximum upload dimension in the CMS
• Automatic WebP conversion on upload
• A required alt text field. An empty alt hurts accessibility and the context around the image
• A featured-image template with a fixed ratio. Dimensions in crop images for social media often match Open Graph cards

Tool sites that accept user uploads (PDF and image converters) have a different constraint. Processing stays client-side at Vertex Solutions, so the marketing images on those pages still need the steps above.

Related articles

• Image Compression for the Web: the compression workflow end to end
• Alt Text That Helps SEO: accessibility and retrieval, past file size
• Resize Images for Web: display-size math and srcset
• Page Speed and PDF Embeds: when a document, not an image, slows the page

Limits

WebP and AVIF cut transfer size. They do not fix a hero that is still 4000 px wide, lazy-loaded, or missing width and height. INP is mostly JavaScript. Image decode only shows up there when the main thread is busy with huge files. Lab scores move the day you ship. Field data in Search Console can take 28 days. Test the production URL, and keep the original master.

Identify the LCP element, resize and compress that file, reserve space with dimensions, and preload what is on screen first. The score follows those bytes. A script cleanup on top of a 2.4 MB hero does not.