BlogImage Compression

How to Compress Images for Fast Mobile Loading

Q: Does srcset compress an image?

No. srcset only gives the browser a set of existing image candidates. You must resize and encode those files before publishing them.

Learn how to resize, compress, and serve responsive images with AVIF, WebP, srcset, and practical mobile performance checks.

July 30, 2026

Updated: July 30, 2026

To compress images for faster mobile loading, resize each image for its real CSS display slot, encode it in one or more efficient formats, deliver responsive candidates with srcset and sizes, and verify what a phone actually downloads. Resizing and compression solve different problems: resizing removes pixels the layout cannot display, while compression reduces the bytes used to represent the remaining pixels. This matters because images were the Largest Contentful Paint element on 68% of mobile pages in the HTTP Archive's 2024 crawl. Compression can shorten image download time, although server response time, resource discovery, request priority, and rendering work also affect LCP.

Key Takeaways

Resize before compressing, using the image's CSS slot width and a deliberate device-pixel-ratio target.
Compare AVIF, WebP, and an appropriate fallback at the same dimensions and visual quality.
Use srcset and sizes to offer responsive files; these attributes do not create or compress images.
Do not lazy-load the probable LCP image. Consider high fetch priority only after identifying that image.
Test the requested URL, dimensions, format, byte size, visual quality, lab LCP, and real-user LCP separately.

What Makes Images Slow on Mobile?

A mobile image can be inefficient in four distinct ways:

Excess dimensions: The encoded image contains more pixels than the rendered slot needs.
Excess bytes per pixel: The format or compression setting is inefficient for the content.
Late discovery: The browser finds the image only after processing CSS, JavaScript, or client-rendered markup.
Incorrect delivery: Missing or inaccurate responsive markup causes the browser to choose a larger candidate than the layout requires.

Reducing file size mainly improves the resource download portion of LCP. It cannot compensate for every other delay. For example, a small hero image may still appear late if JavaScript hides it until hydration finishes.

Resize Images Before You Compress Them

Start by measuring how wide the image appears in the layout, in CSS pixels. Then choose the highest device pixel ratio you intend to serve:

Required source width ≈ CSS slot width × target DPR

For example, an image displayed in a 390 CSS-pixel slot needs about 780 source pixels for a 2x target or 1,170 source pixels for a 3x target. These are upper-bound calculations, not mandatory export sizes. The browser may choose among nearby candidates according to the slot, display density, available candidates, and other conditions.

Build candidate widths from your actual layouts:

Layout observation	Candidate strategy	Example only
Image is nearly full-width on small phones	Include a candidate close to the mobile slot × target DPR	`480w`, `800w`
Article column has a fixed maximum width	Stop adding candidates once they cover that maximum at the chosen DPR	`800w`, `1200w`
Image changes width across breakpoints	Add candidates around the resulting slot sizes	`480w`, `800w`, `1200w`
Thumbnail always renders in a small fixed box	Export close to that box at 1x and 2x	`200w`, `400w`
Simple logo or icon can remain vector	Consider SVG and test its final byte size	No raster width set

Do not treat 480/800/1200 as a universal standard. Inspect the page's computed layout at its real breakpoints and remove candidates that no target slot is likely to use.

Choose a Format by Image Type

No format wins every comparison. Content, transparency, animation, encoder behavior, and the quality threshold all influence the result.

Image type	Formats to test	Fallback approach	What to inspect
Photograph or detailed hero	AVIF and WebP	Responsive JPEG candidates	Faces, texture, gradients, color
Screenshot with text	WebP, PNG, or AVIF	PNG or JPEG as appropriate	Text edges and color fringing
Transparent product image	AVIF, WebP, or PNG	PNG where required	Alpha edges and shadows
Simple logo or icon	SVG first; raster if needed	PNG for a raster fallback	SVG complexity and sharpness
Animated content	Animated WebP, AVIF, or video	Depends on required support	Playback, controls, total bytes

A Google compression study found WebP files were, on average, 25%–34% smaller than JPEG at an equivalent SSIM score for its test datasets and tools. That is a study result, not a promise for every photograph. AVIF can also produce substantial savings in suitable cases, but web.dev's AVIF guidance recommends evaluating the format as part of a broader encoding and delivery workflow.

When AVIF Is Not Automatically the Best Choice

AVIF may encode slowly, and a particular image or encoder setting can produce a result that is larger or visually worse than WebP. Small graphics may also gain little after container overhead is considered.

Use the same decision process for every format:

Keep dimensions identical.
Define what acceptable quality means for the image.
Encode representative settings in each candidate format.
Compare at the image's rendered size and on a detailed crop.
Select the smallest output that passes the same visual standard.
Retain a fallback appropriate to your browser requirements.

Quality numbers are encoder-specific. A quality value of 70 in one tool or format is not directly equivalent to 70 in another.

Compress Once, Then Inspect the Output

For each source image:

Remove unnecessary dimensions by generating the responsive widths your layout needs.
Encode each width in the formats you intend to offer.
Preview the outputs at their actual rendered size and at 100% zoom.
Record dimensions, format, byte size, and any visible artifacts.
Reject outputs that damage important details, even if their file size is lower.

A fixed file-size limit is best treated as a provisional budget rather than a publishing rule. For example, a team might test whether a mobile hero can stay near 100 KB, but a complex full-bleed photograph may require more data while a simple illustration may need far less. The useful target is the smallest acceptable image that helps the complete page meet its performance budget.

For a one-off image, use LessMB during the compression step, then verify the output dimensions, format, visual quality, and final byte size before publishing.

Serve the Right Candidate With `picture`, `srcset`, and `sizes`

Compression has limited value if a narrow phone still receives a desktop-sized file. The following example provides responsive AVIF, WebP, and JPEG candidates:

<picture>
  <source
    type="image/avif"
    srcset="
      hero-480.avif 480w,
      hero-800.avif 800w,
      hero-1200.avif 1200w
    "
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 1200px">

  <source
    type="image/webp"
    srcset="
      hero-480.webp 480w,
      hero-800.webp 800w,
      hero-1200.webp 1200w
    "
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 1200px">

  <img
    src="hero-800.jpg"
    srcset="
      hero-480.jpg 480w,
      hero-800.jpg 800w,
      hero-1200.jpg 1200w
    "
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 1200px"
    alt="Mountain landscape at sunrise"
    width="1200"
    height="630"
    loading="eager"
    fetchpriority="high">
</picture>

The widths and sizes values are examples. Replace them with values derived from your CSS.

How the Browser Chooses a Source

According to MDN's documentation for picture, the browser examines each source element's srcset, media, and type information to find a compatible choice. The img element supplies the fallback when none of the offered sources is usable.

Place AVIF before WebP if you want browsers supporting both to consider AVIF first. Reversing those two sources would generally make such browsers prefer WebP; it would not force every browser to use JPEG.

Within the selected source:

srcset lists files that already exist; it does not resize or compress them.
sizes describes the expected CSS slot width.
The browser combines that slot information with candidate widths and device conditions.
If an applicable sizes value is absent, the selection model can assume a 100vw slot and choose a file larger than the layout needs. It does not necessarily choose the largest candidate.

Provide responsive JPEG candidates too when fallback browsers have materially different display slots. Explicit width and height also let the browser calculate an aspect ratio and reserve space, which can reduce layout shift, as described in the MDN img reference.

If the Hero Is a CSS Background Image

An image referenced only in CSS may be discovered later than an image present in the initial HTML. If the hero conveys content, an img or picture element is usually easier to make responsive, accessible, and promptly discoverable.

If a CSS background must remain:

Inspect the network waterfall to see when its request begins.
Ensure the relevant stylesheet is discovered early.
Use responsive CSS image selection where appropriate.
Consider preloading only after measurement, and make sure the preload matches the resource the page actually requests.
Re-test after every priority change to avoid competing with more important resources.

Test Lab Performance and Real-User LCP

A Lighthouse run and real-user Core Web Vitals answer different questions.

Tool or data source	What it tells you	Important limitation
Browser DevTools	Exact requested URL, content type, transfer size, priority, and timing	Represents the current device and test conditions
Lighthouse	Repeatable lab diagnosis under simulated conditions	Does not prove how most real visitors perform
PageSpeed Insights lab data	A controlled performance test and diagnostics	Can vary between runs
PageSpeed Insights field data or CrUX	Aggregated experience from eligible real Chrome visits	May be unavailable for low-traffic pages and updates over time
Search Console Core Web Vitals	Groups of URLs with field-performance classifications	Not a page-by-page debugging trace

The official “good” LCP target is 2.5 seconds or less at the 75th percentile of page visits, evaluated separately for mobile and desktop. A lab result below 2.5 seconds is encouraging, but it is not equivalent to passing that field-data threshold.

Record Results Without Inventing a Performance Gain

Use the same test page, device profile, cache state, and network conditions when comparing outputs:

Measurement	Before	After
Source dimensions	___ × ___ px	___ × ___ px
Rendered dimensions	___ × ___ CSS px	___ × ___ CSS px
Requested candidate	___	___
Response content type	___	___
Transferred bytes	___	___
Lighthouse LCP, median of repeated runs	___ s	___ s
Field LCP, 75th percentile	___ s	___ s
Visual review passed	Yes / No	Yes / No

Do not fill this table with estimated improvements. Record observed values and note whether field data has had enough time and traffic to become available.

Diagnose a Slow LCP Image

The web.dev LCP optimization model separates the metric into four parts. Check them in order:

LCP component	What to inspect	Typical image-related action
Time to First Byte	Server response and redirects	Improve caching, hosting, or backend response
Resource load delay	When the image request starts	Put the image in initial HTML; remove lazy loading from the LCP candidate
Resource load duration	Download time and transferred bytes	Resize, compress, select a suitable format, and improve delivery
Element render delay	Time between download completion and paint	Remove rendering gates, expensive effects, or JavaScript-dependent visibility

Compression directly targets resource load duration. If that portion is already short, another part of the LCP timeline may offer the larger improvement.

For an image likely to become LCP, do not use loading="lazy". Web.dev explicitly warns that lazy-loading an LCP image creates unnecessary resource-load delay. The default eager behavior is often sufficient; consider fetchpriority="high" for the measured LCP candidate, not for a collection of competing hero images.

Mobile Image Verification Checklist

Common Image-Compression Mistakes

Compressing the original without resizing it: A modern format can still waste bytes when its dimensions far exceed the rendered slot.
Using one fixed file-size limit: Visual complexity and display area vary, so a universal limit can cause artifacts or unnecessary weight.
Comparing format quality numbers directly: Encoder quality scales are not interchangeable.
Omitting responsive fallbacks: A single large JPEG fallback can be wasteful even when AVIF and WebP candidates are responsive.
Writing inaccurate sizes: The browser can only choose well when the declared slot resembles the actual CSS layout.
Lazy-loading the LCP image: This delays a resource that should be discovered early.
Assigning high priority to multiple images: Too many high-priority requests can compete with one another.
Relying on a single Lighthouse run: Lab variability and field behavior require a broader verification process.

Practical Next Steps

Identify the LCP element on a high-traffic mobile page.
Measure the image's CSS slot across real breakpoints.
Generate only the source widths needed for those slots and target DPRs.
Compare AVIF, WebP, and a suitable fallback using the same visual standard.
Add accurate picture, srcset, and sizes markup.
Confirm the requested candidate and transferred bytes in DevTools.
Run several controlled lab tests and record the median result.
Monitor PageSpeed Insights or CrUX field data when the page has sufficient traffic.

FAQ

What is the best image format for fast mobile loading?

AVIF and WebP are strong choices for photographs, but neither format is guaranteed to produce the smallest acceptable file for every image. Encode representative samples, compare visual quality and byte size, and keep a suitable fallback.

How small should mobile images be?

There is no universal file-size limit. Use the smallest file that remains visually acceptable at its actual display dimensions, then confirm that it fits your page-level performance budget under realistic mobile test conditions.

Should I lazy-load the hero image?

Do not lazy-load an image that is likely to become the LCP element. Keep it discoverable in the initial HTML and consider fetchpriority="high" only for the measured LCP candidate.

Does image compression reduce quality?

Lossy compression removes image data, so quality can decline as compression increases. Compare outputs at their rendered size and inspect detailed areas, gradients, text, and edges before choosing a setting.

Does `srcset` compress an image?

No. srcset only gives the browser a set of existing image candidates. You must resize and encode those files before publishing them.

Is AVIF always smaller than WebP?

No. The result depends on the image, encoder, settings, and required visual quality. Compare both formats using identical dimensions and equivalent acceptance criteria.

How do I know which `srcset` image a phone downloaded?

Open the page in browser developer tools, emulate or connect the target device, disable cache, reload, and inspect the image request URL, content type, transfer size, and rendered dimensions.

Is a Lighthouse LCP below 2.5 seconds enough?

It is a useful lab result, but it does not prove that the page passes Core Web Vitals. The official target is based on field data at the 75th percentile of visits, evaluated separately for mobile and desktop.