Compress your LCP image once and stop blocking paint

If you run PageSpeed Insights on a typical content site and the report comes back with a yellow or red Largest Contentful Paint score, the offender is almost always one image. Specifically, the hero image at the top of the page that the viewer sees first. The rest of the optimization advice on the report is usually noise. Fix that one image and the LCP score moves measurably.

This is a workflow piece, not a primer on Core Web Vitals theory. The assumption is you already know what LCP is and you want to know exactly what to do about the image causing it.

图像压缩器

批量压缩为 WebP、AVIF、JXL，支持高级参数调节

→

Step zero: confirm the image is actually your LCP element

Before compressing anything, open Chrome DevTools, go to the Performance panel, record a page load, and look at the LCP marker. It will point at a specific element. If that element is your hero image, this article is for you. If it is a hero text block or a background gradient, image compression is not your bottleneck and you should fix that first.

PageSpeed Insights will also tell you the LCP element in the diagnostics section of any audit. Easier than DevTools if you do not feel like loading the panel.

Step one: pick the right format for the role

Hero images on landing pages, marketing sites, blog posts, and product pages are almost always photographs. Photographs compress best in AVIF, second-best in WebP. Skip JPEG XL for production sites because Chrome's decoder still ships behind a flag in 2026.

If you control your templates and can write a <picture> element with sources, serve AVIF as the primary and WebP as the fallback. AVIF will be roughly 30 to 50 percent smaller than equivalent JPEG and 20 to 50 percent smaller than equivalent WebP. The fallback handles the small percentage of users (mostly older iOS) without AVIF support.

If you cannot write <picture> (most CMSes, most newsletter platforms, most embedded contexts), serve WebP and stop. The 25 to 35 percent file size win over JPEG is real and the deployment story is one <img> tag.

Step two: hit a size budget, not a quality target

The right way to think about LCP image compression is "I have 150 KB of byte budget for this hero, what is the best looking image that fits?" not "I want quality 90, what file size do I get?"

A practical budget for a typical hero image:

• Mobile-first hero, 1200 px wide max: aim for 80 to 150 KB.
• Desktop hero, 1920 px wide max: aim for 150 to 300 KB.
• Full-bleed background hero: same as desktop, but use multiple sources via srcset so phone users get the smaller file.

To hit that budget, encode the image, look at the resulting size, and adjust quality down (or up) until you land in the band. The compressor tool shows the original size and the compressed size for every encoding pass, so the iteration loop is fast: drop image, set quality 60, encode, check size, adjust, re-encode.

For most hero photographs, AVIF quality 50 to 65 lands inside the budget. WebP quality 75 to 82 lands close. JPEG quality 80 to 85 with mozjpeg encoding lands in the same range, slightly larger.

Step three: set the size attribute correctly

The most common mistake after compression is forgetting that the browser still has to wait for the image to download before it can paint, and the browser only knows to start the download early if the image is in the initial HTML and has explicit dimensions.

For your LCP image:

• Always include width and height attributes that match the actual encoded dimensions. This prevents layout shift and lets the browser reserve space immediately.
• Add fetchpriority="high" to tell the browser this image is the priority download, not the third script tag in the head.
• Add loading="eager" (or just leave loading off, since eager is the default). Never put loading="lazy" on the LCP image, because lazy loading defers the request until the element scrolls into view, and the LCP element is by definition above the fold.

A typical LCP <img> tag in 2026 looks like this:

<img src="hero.avif"
     srcset="hero-mobile.avif 800w, hero.avif 1920w"
     sizes="100vw"
     width="1920"
     height="1080"
     fetchpriority="high"
     alt="Descriptive alt text">

If you are using <picture> for AVIF-with-WebP-fallback, the fetchpriority and loading attributes go on the inner <img>, not the <source> elements.

Step four: preload only when measurement says you need to

A <link rel="preload"> for the LCP image used to be a near-universal recommendation. Browsers have gotten smarter about predicting LCP images and the preload hint sometimes hurts more than it helps now (it can compete with critical CSS for early bandwidth).

The decision rule:

1. Measure your LCP without preload.
2. If it is already under 2.5 seconds on a 4G profile, do nothing further.
3. If it is over 2.5 seconds and DevTools shows the image waiting on render-blocking CSS or JavaScript, add the preload and re-measure.
4. If LCP improves, keep the preload. If it does not, remove it.

Adding preload without measuring is how sites end up shipping three preload hints that all compete with each other for the early bytes.

Step five: verify after deploying

After you ship the new compressed hero, run PageSpeed Insights again on the live URL. The LCP score should move. If it doesn't move, two things to check:

1. Is the new image actually being served? (View source, network tab, Cloudflare cache headers, etc.)
2. Is the LCP element still the hero image, or did the layout change push something else into the LCP slot? (Check the diagnostics again.)

The most common "compression did nothing" outcome is a CDN cache that is still serving the old image. Purge it.

What this is not solving

Image compression on the LCP element is the highest-impact change you can make in five minutes. It is not the only thing your Core Web Vitals score depends on. Specifically:

• Time to First Byte from your origin or edge.
• Render-blocking CSS in the head.
• Web fonts loading after the LCP image.
• Layout shift caused by ads, embeds, or late-arriving content.

If your LCP is bad after fixing the hero image, the next suspect is one of those four. Image compression is the cheap win to take first; it is not the entire optimization story.

A quick recap

Pick the right format for the role (AVIF with WebP fallback when you control markup, WebP otherwise). Hit a byte budget, not a quality target. Set explicit width and height on the image tag. Add fetchpriority="high" and never lazy load the LCP element. Measure, ship, verify. The whole loop takes about ten minutes per page and the LCP improvement is usually dramatic.

The compressor on this site is built for exactly this pass: drop the source image in, encode it three ways at different qualities, watch the byte counter, pick the version that fits the budget. Then ship.

Z.Tools·z.tools

Image Compressor · Z.Tools

Batch compress to WebP, AVIF, JXL with advanced controls