Core Web Vitals and Images: What You Need to Know

Featured Image: Core Web Vitals and Images: What You Need to Know

If you’ve checked your site in Google PageSpeed Insights or Search Console and seen Core Web Vitals warnings, there’s a good chance images are involved. The impact on Core Web Vitals from unoptimized images is one of the most common causes of poor scores on ordinary websites — and also one of the most fixable, often without touching a line of code beyond your <img> tags.

This guide covers everything on Core Web Vitals and images — how they affect LCP and CLS specifically, and the practical fixes that make the biggest difference.

What Core Web Vitals Actually Measure

Core Web Vitals are a set of specific, measurable signals Google uses to judge real-world page experience:

  • Largest Contentful Paint (LCP) — how long it takes for the largest visible element (very often an image) to fully render
  • Interaction to Next Paint (INP) — how responsive the page feels when someone actually interacts with it (clicking, tapping, typing)
  • Cumulative Layout Shift (CLS) — how much visible content unexpectedly shifts around as the page loads

Images directly affect two of these three — LCP and CLS — which is why they’re such a common culprit when Core Web Vitals scores come back poor.

💡

Want to try it yourself? Compress your images free — no upload, no signup.

Core Web Vitals and Images

How Images Hurt LCP

Your LCP element is whatever visibly loads last among the largest content on the initial screen — on most web pages, that’s a hero image, featured image, or a large photo near the top of the page. If that image is:

  • Too large in file size (an unoptimized, uncompressed original), it simply takes longer to download
  • Not sized to its actual display dimensions (e.g., a 4000px-wide source image displayed at 800px), the browser downloads far more data than it needs
  • Lazy-loaded when it shouldn’t be — as covered in our lazy loading guide, delaying your most prominent image can directly hurt LCP, since the browser doesn’t even start fetching it until later

The fix for all three is the same core practice: compress your images properly, resize them to the dimensions they’re actually displayed at, and make sure your most important above-the-fold image loads eagerly, not lazily.

How Images Affect INP (and Why It’s Usually Not Your Biggest Concern)

Interaction to Next Paint measures how responsive your page feels when someone actually clicks, taps, or types — it replaced the older First Input Delay metric in 2024 and is now one of the three official Core Web Vitals.

Unlike LCP and CLS, images themselves rarely cause INP problems directly. A photo or a hero image doesn’t respond to clicks, so it isn’t part of the interaction chain Google is measuring. Where images can indirectly affect INP is through JavaScript competing for the browser’s main thread — for example, a heavy image gallery script, a lightbox plugin, or client-side image processing running at the same moment a visitor tries to interact with the page.

This is actually a case worth understanding correctly rather than assuming the worst: browser-based tools that process images locally (compression, resizing, format conversion) only run when a visitor actively initiates that action — clicking a button, dropping in a file — not passively in the background while someone’s trying to interact with the rest of the page. As long as image processing isn’t blocking the main thread during an unrelated interaction elsewhere on the page, it has no meaningful INP impact.

The practical takeaway: for most content pages — blog posts, product pages, galleries — INP problems are usually caused by something other than images: heavy third-party scripts, poorly optimized JavaScript, or too much work happening on page load. If your LCP and CLS scores are good but INP is poor, look at your scripts and plugins before assuming it’s image-related.

How Images Cause Layout Shift (CLS)

This one surprises people, since it’s not really about image quality at all — it’s about whether the browser knows the image’s dimensions before it finishes loading.

If you don’t specify width and height attributes (or an aspect-ratio via CSS) on an <img> tag, the browser doesn’t know how much space to reserve for it while it’s loading. The moment the image finishes downloading, the page layout suddenly jumps to make room for it — pushing text and other elements down. This is exactly the kind of jarring shift CLS is designed to catch, and it’s one of the most common CLS problems on ordinary content sites.

The fix is simple: always include explicit width and height attributes on your <img> tags (or use CSS aspect-ratio), so the browser reserves the correct space immediately, before the image has even started downloading.

<img src="photo.jpg" width="1200" height="630" alt="Description">

Even if the image is later resized responsively via CSS, having the original width/height attributes present is enough for the browser to calculate and reserve the correct aspect ratio in advance.

A Practical Checklist

  • [ ] Compress every image before uploading — don’t rely on your CMS or platform to do it for you, since results vary widely
  • [ ] Resize images to their actual maximum display dimensions rather than uploading full-resolution originals
  • [ ] Include explicit width and height attributes on every <img> tag
  • [ ] Make sure your primary above-the-fold image is NOT lazy-loaded
  • [ ] Lazy-load everything else below the fold
  • [ ] Use a modern format (WebP or AVIF) where your audience’s browser support allows it
  • [ ] Check your actual Core Web Vitals data in Google Search Console periodically, since lab tools (like PageSpeed Insights) and real-world field data can sometimes disagree

Browser Support and Ease of Implementation

None of the fixes above require modern or experimental browser features — that’s part of why they’re worth prioritizing first.

  • Explicit width/height attributes — supported everywhere, including very old browsers. Zero compatibility risk, and the easiest fix on this list to implement (a five-minute template change in most cases).
  • Native lazy loading (loading="lazy") — supported in all modern browsers (Chrome, Firefox, Edge, Safari). Older browsers simply ignore the attribute and load the image normally, so there’s no broken-experience risk in adding it — it just won’t help visitors on very outdated browsers.
  • WebP — supported by every browser in current use. AVIF has slightly less universal support but degrades gracefully with a fallback format, so it’s low-risk to adopt.
  • Resizing to actual display dimensions — not a browser feature at all, just a workflow change on your end, so there’s no compatibility question here whatsoever.

In practice, this means the highest-impact Core Web Vitals fixes for images are also the lowest-risk and fastest to implement — there’s no trade-off between “do it properly” and “do it easily” here, which isn’t always true for web performance work.

How to Check Your Current Scores

Two tools give slightly different, complementary information:

  • PageSpeed Insights (a single-page lab test) — good for diagnosing a specific page in detail right now, with a breakdown of exactly what’s contributing to each score
  • Google Search Console’s Core Web Vitals report (real-world field data) — shows how your pages actually perform for real visitors over time, which can differ from a lab test since it reflects a mix of real devices and connection speeds

If PageSpeed Insights shows a good score but Search Console’s field data is worse, it usually means real visitors (especially on mobile connections) are having a meaningfully different experience than the lab test simulates — worth investigating on a mobile device over a throttled connection specifically.

Ready to shrink your images?

Compress and resize JPG, PNG, and WebP files for free, right in your browser. No uploads, no signups, no waiting.

Compress Images Now →

Frequently Asked Questions

What is included in Core Web Vitals?

Three metrics: Largest Contentful Paint (LCP), which measures loading speed and is very often determined by your largest image; Interaction to Next Paint (INP), which measures how responsive the page feels to clicks and taps; and Cumulative Layout Shift (CLS), which measures visual stability — the layout-jumping issue caused by images loading without reserved space, covered earlier in this post.

Are Core Web Vitals still relevant?

Yes — they remain one of Google’s active page experience signals in 2026, and Interaction to Next Paint (INP) has fully replaced the older First Input Delay (FID) metric as of March 2024, so any advice still mentioning FID is outdated. Core Web Vitals aren’t the dominant ranking factor, but they act as a meaningful tiebreaker between pages of otherwise similar quality — and image optimization remains one of the most common ways sites fail them.

What is a good Core Web Vitals score?

A page passes when at least 75% of real visits hit the “good” threshold for all three metrics: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. All three need to pass together — strong LCP and CLS won’t offset a poor INP score, since Google evaluates each metric independently rather than averaging them into one number.

How to see Core Web Vitals?

Google Search Console’s Core Web Vitals report shows real-world data from actual visitors over a rolling 28-day window. PageSpeed Insights gives a quicker single-page lab test, useful for testing a specific fix immediately rather than waiting for real-user data to accumulate. The two can show different results, since one reflects real visitor conditions and the other simulates a single test run.

Do Core Web Vitals directly affect SEO rankings?

Google has confirmed page experience signals, including Core Web Vitals, are one of many ranking factors — not the dominant one, but a real one, and increasingly relevant as more sites reach acceptable content quality and technical factors become more of a differentiator.

Is it possible to have perfect Core Web Vitals scores with image-heavy pages?

Yes — the goal isn’t fewer images, it’s properly optimized ones. Plenty of image-heavy sites (photography portfolios, e-commerce catalogs) achieve good Core Web Vitals scores through correct compression, sizing, and lazy loading practices.

How often should I re-check Core Web Vitals?

Checking after any significant change (new theme, new images, plugin updates) is more useful than checking on a fixed schedule — Search Console’s field data also naturally updates on a rolling basis as it collects more real-user data over time.

Get your images compressed and correctly sized for Core Web Vitals, free and instantly, with our browser-based tool — no upload required, everything happens in your browser.

Scroll to Top