This guide explains how responsive images, srcset,
sizes, device pixel ratio (DPR), modern image formats,
lazy loading, caching, and image optimization tools work together.
It also covers how to interpret Lighthouse image warnings without
sacrificing visual quality for an audit score.
Lighthouse estimates image waste using a specific test viewport, network profile, device pixel ratio, and page state. Real visitors use different screens, devices, connections, and DPR values. Treat Lighthouse image warnings as investigation prompts rather than absolute image budgets.
For every image, answer four questions:
Those answers determine image dimensions, responsive candidates, loading priority, encoding, compression, and cache lifetime.
A web layout is measured in CSS pixels, while an image file is measured in source pixels. The difference matters when deciding how large an image should be.
On a DPR 1 screen, a 550 CSS-pixel-wide image slot needs roughly 550 source pixels to provide one physical pixel per CSS pixel. On a DPR 2 screen, the same slot can use roughly 1,100 source pixels for equivalent native sharpness.
DPR 3 screens exist too, but that does not mean every visitor should automatically receive a 3x image. The additional sharpness may not justify the bandwidth cost, particularly for small thumbnails and below-the-fold content.
This is why a 1280×720 image can be reasonable on a high-density display while still appearing oversized in a Lighthouse audit for a roughly 550×310 CSS-pixel slot.
The solution is usually responsive image selection with a sensible upper limit based on the image's importance. It is rarely necessary to remove every high-density image candidate.
src, srcset, and sizes Work TogetherResponsive image optimization depends heavily on three HTML attributes: src, srcset, and sizes.
src provides the fallback image URL and may act as the default candidate. srcset gives the browser alternative image resources. When width descriptors such as 480w, 768w, and 1280w are used, the browser also needs sizes to estimate how wide the image will actually appear.
<img
src="/images/hero-1280.webp"
srcset="/images/hero-480.webp 480w,
/images/hero-768.webp 768w,
/images/hero-1024.webp 1024w,
/images/hero-1280.webp 1280w"
sizes="(max-width: 768px) 100vw, 50vw"
width="1280"
height="720"
alt="Application dashboard displayed on a screen"
>In this example, the image is expected to occupy the full viewport width below 768px and approximately half of the viewport above that breakpoint.
A 390px-wide DPR 2 phone therefore needs a resource near 780 pixels wide. A 1440px-wide DPR 1 desktop displaying the image at half the viewport needs something near 720 pixels wide.
The browser uses this information, along with its own resource-selection logic, to choose a useful candidate. It does not simply download every candidate or blindly download the src resource after choosing one from srcset.
Accurate sizes values are often more valuable than adding many nearly identical image widths.
There are two main ways to describe responsive image candidates in srcset: width descriptors and density descriptors.
Width descriptors such as 480w, 768w, and 1280w are generally the better choice for fluid responsive layouts. They allow the browser to select an image according to the expected rendered width.
Density descriptors such as 1x and 2x are more appropriate when an image has a predictable, fixed CSS size.
<img
src="/images/logo-24.png"
srcset="/images/logo-24.png 1x,
/images/logo-48.png 2x"
width="24"
height="24"
alt="Company logo"
>For responsive cards, banners, product images, and content images, width-based candidates usually provide better control. For small fixed-size icons or similar assets, density descriptors can make more sense.
There is no universal rule that every image needs a 2x or 3x version. A below-the-fold thumbnail may be perfectly acceptable with a lower maximum resolution, while a prominent hero or product image may benefit from higher-density candidates.
Choose based on the image's role, actual layout size, visual importance, and bandwidth cost.
Modern frameworks, CMS platforms, CDNs, and image transformation services can generate responsive image variants automatically. Instead of manually creating every size, you provide a source image and request appropriately resized or encoded variants.
A typical responsive image component might look conceptually like this:
<ResponsiveImage
src="/images/example.webp"
width="640"
height="360"
sizes="(max-width: 1024px) 100vw, 33vw"
quality="80"
format="webp"
alt="Example responsive image"
/>The exact syntax depends on the framework or image service, but the underlying browser behavior remains the same.
width and height establish the intrinsic aspect ratio. sizes describes the expected layout width. CSS determines the actual rendered size, and the generated srcset gives the browser resources to choose from.
These pieces should agree. If CSS changes a desktop grid from three columns to two columns but the image's sizes configuration still describes a three-column layout, responsive image selection becomes inaccurate.
For reusable image components, avoid hard-coding 100vw when images appear in different layouts. Whenever possible, let the component or template that understands the surrounding layout provide the appropriate sizes value.
Most importantly, inspect the final rendered HTML. The browser responds to the actual <img>, srcset, sizes, and network request—not the abstraction used by your framework.
The principles above are framework-independent, but it helps to see what they look like in a real implementation. If you use Nuxt, the Nuxt Image module provides responsive image components and can use IPX to transform images into appropriately sized variants.
You do not need to use Nuxt or IPX to apply the ideas in this section. The important concepts are the same in Next.js, Astro, a CMS image CDN, or a custom image pipeline: generate useful image sizes, tell the browser how large the image will appear, and let it select an appropriate resource.
Instead of serving one large image to every visitor, a Nuxt application can use <NuxtImg> to describe how the image should be delivered:
<NuxtImg
src="/images/example.jpg"
width="640"
height="360"
sizes="sm:100vw md:50vw lg:33vw"
format="webp"
quality="80"
loading="lazy"
alt="Example responsive image"
/>This is the Nuxt-specific layer. The browser still receives normal image markup underneath it. Depending on the configuration, Nuxt Image can generate the required image URLs and responsive candidates while IPX handles transformations such as resizing and format conversion.
The useful mental model is:
That final point matters. Nuxt can generate excellent responsive markup, but the browser can still request an unnecessarily large image if the declared image sizes do not accurately represent the layout.
sizes Property Still Matters in NuxtConsider a card image that occupies the full width of a phone, half of a tablet layout, and roughly one-third of a desktop layout.
<NuxtImg
src="/images/card.jpg"
width="640"
height="360"
sizes="sm:100vw md:50vw lg:33vw"
format="webp"
alt="Article card image"
/>The important part is not simply that sizes exists. It needs to reflect the real CSS layout.
If the image actually occupies one-third of a large desktop viewport but the generated markup effectively tells the browser to expect something close to the full viewport width, the browser may choose a much larger candidate than necessary.
That can lead to the familiar Lighthouse warning that an image is larger than its displayed dimensions.
The same problem exists outside Nuxt. Whether you use Nuxt Image, Next.js Image, a CDN, or hand-written srcset, inaccurate sizing information can cause unnecessary image downloads.
IPX can generate transformed versions of an image rather than requiring every possible width and format to be created manually ahead of time.
Conceptually, an original image might be transformed into several resources such as:
Original image
↓
480px WebP
768px WebP
1024px WebP
1280px WebPThe browser does not need all four files. Responsive image markup allows it to choose the resource that best fits the current layout and device.
This is particularly useful for sites with many content images because developers can maintain a suitable source image while the image pipeline produces optimized delivery variants.
However, dynamic transformation is not a substitute for good responsive image configuration. Generating a perfectly compressed 1600px image does not help much if the browser only needed a 500px image.
Nuxt users can also account for higher-density displays, but the same bandwidth trade-off discussed earlier still applies.
For example, an image displayed at roughly 500 CSS pixels wide could reasonably use a resource near 1,000 pixels wide on a DPR 2 display. That does not automatically mean every 500px image needs a 1,500px DPR 3 candidate.
For a prominent image where fine detail matters, providing higher-density candidates may be worthwhile. For a small card thumbnail far down the page, limiting the maximum delivered resolution may provide a better balance.
The framework should make responsive delivery easier, but it should not make the decision for you about how much image quality is worth the additional bytes.
An important image near the top of the page should usually be treated differently from a lazy-loaded card image.
<NuxtImg
src="/images/hero.jpg"
width="1280"
height="720"
sizes="sm:100vw md:100vw lg:1200px"
format="webp"
loading="eager"
fetchpriority="high"
alt="Main page hero image"
/>If this image is likely to become the page's LCP element, loading it eagerly and giving it a higher fetch priority can be appropriate.
That does not mean every image above the fold should receive fetchpriority="high". Reserve additional priority for resources that genuinely matter to the initial render.
Images farther down the page generally do not need the same treatment:
<NuxtImg
src="/images/article-thumbnail.jpg"
width="640"
height="360"
sizes="sm:100vw md:50vw lg:33vw"
format="webp"
loading="lazy"
alt="Article thumbnail"
/>Lazy loading allows the browser to delay fetching these images until they are closer to the viewport, reducing competition with more important resources during the initial page load.
When debugging image performance in Nuxt, do not stop at the Vue component.
Open the rendered page in your browser's developer tools and inspect the final image element. Check:
src;srcset;sizes value;This is one of the most useful debugging habits for Nuxt Image and IPX. A component configuration can look reasonable while the generated HTML or selected network request reveals that the browser is receiving more pixels than expected.
It is tempting to keep reducing widths, quality settings, or responsive candidates until Lighthouse stops reporting image savings. That can solve the audit while making the actual website worse.
A better process is to test the rendered result at realistic mobile and desktop sizes. Compare visual quality, transferred bytes, LCP, and the candidate selected by the browser.
If Lighthouse reports that a Nuxt/IPX image could be smaller, first investigate whether sizes matches the layout. Then check whether a slightly smaller candidate would still look good at the relevant DPR.
Only after that should you start aggressively reducing source dimensions or image quality.
One of the simplest image performance improvements is reserving space before the image arrives.
Supply numeric width and height attributes that represent the image's aspect ratio. If dimensions genuinely cannot be known, use CSS aspect-ratio or another reliable method to reserve the correct space.
<img
src="/images/example.webp"
width="640"
height="360"
class="responsive-image"
alt="Example image"
>Width and height attributes do not necessarily force an image to display at those exact dimensions. Responsive CSS can still make the image fluid. Modern browsers use the dimensions to calculate the aspect ratio and reserve layout space before the resource finishes loading.
This helps reduce unexpected movement and contributes to better Cumulative Layout Shift (CLS) performance.
Use object-fit: cover only when cropping is intentional. If the focal point of an image matters, consider art-directed variants or delivery-time cropping where your image service supports it.
A smaller image that removes important visual information is not a successful optimization.
Not every image should have the same loading priority. Loading behavior should reflect when the visitor is likely to need the resource.
| Image Role | Recommended Default | Reason |
|---|---|---|
| Likely LCP or hero image | loading="eager" and potentially fetchpriority="high" |
Allows an important visual resource to begin loading promptly. |
| Other immediately visible image | Browser default or eager when justified | Avoids unnecessarily delaying content visible on initial load. |
| Below-the-fold image | loading="lazy" |
Preserves bandwidth and processing work until the image is needed. |
| Decorative image | CSS background or alt="", with lazy loading when offscreen |
Avoids giving decorative content unnecessary semantic or network priority. |
Avoid assigning fetchpriority="high" to many images. If everything is high priority, the browser has less room to prioritize the resource that actually matters.
Likewise, lazy-loading the image responsible for Largest Contentful Paint (LCP) can create an avoidable performance regression.
Preloading can help when the browser needs to discover an important image earlier, but it should be used carefully. An incorrect preload can fetch a resource that the responsive image system ultimately does not use.
Modern image optimization is not simply a matter of converting everything to one format. Image dimensions, content, quality, browser support, and encoding all matter.
| Format | Good For | Considerations |
|---|---|---|
| AVIF | Photographic images where efficient compression is important | Can produce small files, but important images should still be tested for visual quality and performance. |
| WebP | General-purpose web photography and graphics | A practical balance of image quality, file size, and broad modern browser support. |
| JPEG | Photographic fallbacks and compatibility-sensitive situations | Does not support transparency and can be less efficient than modern formats. |
| PNG | Lossless graphics, screenshots, and transparency | Can be unnecessarily large for photographic content. |
| SVG | Logos, icons, and simple illustrations | Excellent for scalable graphics, although complex SVG files can still become large or expensive to render. |
Format is only one variable. A 1280px WebP image can still be excessive when displayed in a 340px-wide card.
Resize first, then choose format and quality.
Before worrying about responsive sizes, it is also worth optimizing the image itself. I built PicSmash, a browser-based image compression tool, for quickly reducing image file sizes before they enter the rest of the image pipeline. Compression and responsive sizing solve different problems: compression reduces the bytes in a particular image, while responsive delivery helps prevent the browser from downloading more pixels than it actually needs.
For lossy formats, a quality setting around 70–85 can be a useful starting point, but it should never become an unquestioned target. Compare the results at the dimensions visitors will actually see.
Faces, text, screenshots, gradients, dark areas, and flat colors can reveal compression artifacts earlier than visually busy photographs. Image quality therefore needs visual review rather than optimization around a single numeric setting.
Also avoid enlarging a poor-quality source and expecting an image transformation service to restore missing detail. Resizing can increase pixel dimensions, but it cannot recreate information that was never present in the source.
Keep a sufficiently large, clean original as the source for responsive transformations. Deliver smaller variants from that master rather than repeatedly editing already compressed files.
Remove unnecessary metadata, avoid repeated lossy exports, and avoid shipping huge camera originals when a well-prepared master image would provide the same useful detail.
Generated responsive image variants should also be cached where appropriate. CDN and browser caching can reduce repeat downloads and prevent unnecessary image transformation work.
Versioned or content-hashed image filenames can often use very long cache lifetimes because changing the image produces a new URL. Stable filenames that may be replaced without changing their URL require a more careful caching policy or reliable cache invalidation.
Remember that caching does not make the first image request smaller. It improves subsequent requests by allowing browsers and edge caches to reuse resources that have already been generated or downloaded.
A common Lighthouse warning indicates that an image is larger than necessary for its displayed dimensions. This generally means the downloaded resource contains more pixels than the rendered slot requires during that particular audit.
That warning may identify a genuine problem. For example, the browser might be selecting a 1280px-wide candidate for a roughly 550px slot because the sizes value does not match the actual layout.
But the difference can also be intentional. On a DPR 2 screen, a 550 CSS-pixel-wide image can reasonably use a source around 1,100 pixels wide.
Before changing your image code, check:
sizes value accurate for the current layout and breakpoint?A small theoretical bandwidth saving is not necessarily worthwhile if it makes an important image visibly blurry. At the same time, repeated over-delivery across dozens of thumbnails or cards can add substantial unnecessary page weight.
The objective is balance rather than blindly eliminating every warning.
A reliable image optimization process can be reduced to eight steps:
sizes value from real CSS container and grid behavior rather than guessing.width and height or another reliable aspect-ratio reservation.The healthy end state of responsive image optimization is not zero Lighthouse warnings. It is a page where image selection matches the layout, important visuals remain crisp, dimensions prevent unexpected layout movement, offscreen images do not steal early bandwidth, and repeat visits can reuse cached resources.
Start with the rendered size and the role of each image. Configure accurate responsive candidates, reserve layout space, choose appropriate formats, prioritize only what matters, and verify what the browser actually downloads.
When those pieces work together, Lighthouse becomes what it should be: a useful performance guardrail rather than the designer of your website.
Hi, Im a seniour software engineer building web platforms. I write about Nuxt, Typescript, DevOps, AI and engineering decisions behind real products, based on my real experience.