DEV Community: Jaimin Patel

How Responsive Images Work in React: srcSet, sizes, DPR and CDNs

Jaimin Patel — Tue, 22 Sep 2026 13:30:00 +0000

If you have worked on a React application with a lot of images, you have probably seen this problem: the same large image gets downloaded on every device.

A desktop might display an image at 900px, while a mobile device only needs 350px. Sending the same 1600px image to both devices doesn't make much sense.

This is where responsive images help.

The browser can choose an appropriate image based on the image's display size and the device's pixel density. React doesn't need a special API for this — it uses the standard HTML image features.

Let's look at the main pieces.

Responsive Images in React

A basic React image is simple:

<img src="/images/product.jpg" alt="Product" />

There is only one source here, so the browser downloads that image regardless of the screen size.

With responsive images, we can provide multiple versions:

<img
  src="/images/product-800.jpg"
  srcSet="
    /images/product-400.jpg 400w,
    /images/product-800.jpg 800w,
    /images/product-1200.jpg 1200w
  "
  alt="Product"
/>

The 400w, 800w, and 1200w values tell the browser the actual width of each image.

But the browser also needs to know how large the image will be displayed. That's where sizes comes in.

srcSet and sizes

A simple way to remember them:

srcSet → What image versions are available?
sizes → How wide will the image be displayed?

For example:

<img
  src="/images/product-800.jpg"
  srcSet="
    /images/product-400.jpg 400w,
    /images/product-800.jpg 800w,
    /images/product-1200.jpg 1200w
  "
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="Product"
/>

Here, we're telling the browser that the image takes the full viewport width on smaller screens and roughly half the viewport width on larger screens.

If the desktop viewport is 1200px wide, the browser knows the image will be around 600px wide and can choose a suitable source.

That's the important part: srcSet provides choices, while sizes gives the browser information to make that choice.

DPR and High-Density Screens

Another factor is Device Pixel Ratio (DPR).

A device with a DPR of 2 has a higher pixel density than a standard 1x display. For a fixed-size image, you may want to provide a higher-resolution version.

For example:

<img
  src="/images/logo.png"
  srcSet="
    /images/logo.png 1x,
    /images/logo@2x.png 2x,
    /images/logo@3x.png 3x
  "
  alt="Logo"
/>

This can be useful for:

Logos
Icons
Avatars
Other fixed-size images

For images that change size with the layout, width-based srcSet with sizes is generally the more useful approach.

So there are two common patterns:

Responsive layout → width-based srcSet + sizes

Fixed-size image → 1x / 2x / 3x

Where Does a CDN Fit?

If you have many images, manually creating every image size can become difficult.

Instead of maintaining:

product-400.jpg
product-800.jpg
product-1200.jpg

an image CDN can provide different sizes from the same source:

https://cdn.example.com/product.jpg?w=400
https://cdn.example.com/product.jpg?w=800
https://cdn.example.com/product.jpg?w=1200

You can then use those URLs in srcSet:

<img
  src="https://cdn.example.com/product.jpg?w=800"
  srcSet="
    https://cdn.example.com/product.jpg?w=400 400w,
    https://cdn.example.com/product.jpg?w=800 800w,
    https://cdn.example.com/product.jpg?w=1200 1200w
  "
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="Product"
/>

The responsibilities are different:

CDN → Provides the image variant.

srcSet → Tells the browser which variants are available.

sizes → Tells the browser the expected display width.

DPR → Accounts for the screen's pixel density.

A CDN can also provide different image formats such as WebP and AVIF, depending on the setup.

Using Responsive Images in React

If you don't want to manually handle all of these image-loading details in every component, a React image component can provide a higher-level API.

One example is React Smart Image, an open-source React image component I built. It provides responsive images along with features such as lazy loading, priority loading, WebP/AVIF support, blur placeholders, skeleton loaders, retry handling, fallback images, and zoom. It has zero runtime dependencies and works with React 18+.

For example:

import { SmartImage } from "@concatstring/react-smart-image";

<SmartImage
  src="/product.jpg"
  alt="Product"
  responsive
  lazy
/>

It also supports combining responsive images with priority loading for important images such as hero images:

<SmartImage
  src="/hero.jpg"
  alt="Hero"
  responsive
  priority
/>

The package is available on npm, and the project is open source on GitHub.

Website: https://labs.concatstring.com/products/react-smart-image
GitHub Source Code: https://github.com/concatstring-account/react-smart-image
NPM: https://www.npmjs.com/package/@concatstring/react-smart-image
Live Demo: https://react-smart-image.netlify.app/

When Should You Use Each One?

There isn't one setup that works for every image.

Use srcSet

When the same image is displayed at different sizes depending on the layout.

Use sizes

When the rendered image width changes based on the viewport or layout. It works together with width-based srcSet.

Use DPR sources

When an image has a relatively fixed display size but needs to look sharp on high-density screens.

Use a CDN

When you have many images and need dynamic resizing, different formats, or different image variants.

Final Thoughts

Responsive images are not really a React-specific feature. React simply gives us a convenient way to use the browser's existing image capabilities.

The basic idea is straightforward:

srcSet → Available image sources

sizes → Expected display width

DPR → Screen pixel density

CDN → Image variants and transformations

For most responsive content images, start with srcSet + sizes.

For fixed-size assets, 1x/2x/3x DPR sources can be useful.

And if your application has a large image library, an image CDN can make managing those variants much easier.

The goal isn't to add every image feature available. It's to give the browser enough information to download an image that actually makes sense for the device and the layout.

WebP vs AVIF: Which Image Format Is Better for React?

Jaimin Patel — Mon, 14 Sep 2026 18:10:16 +0000

If you are working on a React application, images are usually one of the first things I look at when trying to improve page performance.

A large JPEG or PNG image can easily be hundreds of KB or even a few MB. If a page contains multiple images, that can quickly increase the amount of data the browser needs to download.

This is where modern image formats like WebP and AVIF become useful.

Both formats can reduce image size compared with traditional JPEG and PNG images, but they have some differences.

So, which one should you use in a React project?

Let's look at the practical differences.

What is WebP?

WebP is an image format developed by Google.

The main goal of WebP is simple: provide smaller image files without losing too much visual quality.

WebP supports both lossy and lossless compression, as well as transparency and animation.

The actual size will depend on the original image and compression settings, but WebP can provide a significant reduction compared with JPEG.

One reason WebP became popular is that browser support became very good, making it a practical replacement for many JPEG and PNG images.

What is AVIF?

AVIF is a newer image format based on the AV1 video codec.

Its biggest advantage is compression efficiency.

In many cases, AVIF can produce a smaller file than WebP while maintaining similar visual quality.

If your website contains a lot of photographs or large images, reducing the file size can save a significant amount of bandwidth.

The downside is that AVIF encoding can sometimes require more processing than WebP, depending on the encoder and configuration.

WebP vs AVIF: File Size

If we compare compression efficiency, AVIF will often produce a smaller file.

For example:

Original JPEG: 800 KB
WebP: 500 KB
AVIF: 350 KB

Imagine a product page with 20 images.

Even a small reduction per image can make a noticeable difference in the total amount of data downloaded.

This is especially useful for:

E-commerce websites
Photography websites
News websites
Blogs with many images
Image-heavy React applications

However, smaller file size isn't the only thing that matters.

You also need to consider image quality, browser support and how easily you can generate these formats.

Browser Support

Browser support is another important difference.

WebP has been supported by modern browsers for quite a while, so it is generally a safe choice.

AVIF also has broad support in modern browsers, but if your application needs to support older browsers or different environments, providing a fallback is still a good idea.

One common approach is using the element:

<picture>
  <source srcSet="/images/photo.avif" type="image/avif" />
  <source srcSet="/images/photo.webp" type="image/webp" />

  <img
    src="/images/photo.jpg"
    alt="Example"
  />
</picture>

The browser will choose the first supported format.

So the fallback can look like:

AVIF
↓
WebP
↓
JPEG

This approach lets you use AVIF for browsers that support it while still having a WebP or JPEG fallback.

What About Image Quality?

Both WebP and AVIF can provide very good image quality.

But the format itself isn't the only factor.

The final result depends on things like:

Compression level
Encoder
Image type
Original image quality
Image dimensions

For example, an aggressively compressed AVIF image can look worse than a properly compressed WebP image.

So I wouldn't simply say:

AVIF is better because it is smaller.

A better question is:

Which format gives you the image quality you need at the file size you want?

For large photographs, AVIF can be very effective.

For general website images, WebP may already provide more than enough compression and quality.

Using WebP and AVIF in React

Using modern image formats is only one part of image optimization in React.

For example, you could have a perfectly optimized AVIF image, but if you're loading a 2000px image into a 400px container, you're still downloading more data than necessary.

Responsive images are important too.

For example:

<img
  src="/images/product-800.webp"
  srcSet="
    /images/product-400.webp 400w,
    /images/product-800.webp 800w,
    /images/product-1200.webp 1200w
  "
  sizes="(max-width: 768px) 100vw, 800px"
  alt="Product"
/>

Now the browser can select an appropriate image size based on the user's device and layout.

You can also combine responsive images with AVIF and WebP using

<picture>.

For example:

<picture>
  <source
    srcSet="/images/product.avif"
    type="image/avif"
  />

  <source
    srcSet="/images/product.webp"
    type="image/webp"
  />

  <img
    src="/images/product.jpg"
    alt="Product"
  />
</picture>

This gives you a practical fallback strategy without forcing every browser to use the same format.

Final Thoughts

So, WebP vs AVIF — which one is better?

There isn't a single answer for every React application.

WebP is mature, reliable and provides good compression with broad browser support.

AVIF can provide even better compression and smaller files, especially for photographs and image-heavy websites.

If your project supports it, using both can be a practical approach:

AVIF
↓
WebP
↓
JPEG/PNG

But don't forget that image optimization is bigger than just choosing a file format.

Test your real images, check the file sizes, compare the visual quality, and measure the actual loading performance.

That's usually the best way to decide.

Related React Smart Image NPM

I also created @concatstring/react-smart-image for React applications. It can automatically try AVIF → WebP → the original image when those formats are available.

<SmartImage
  src="/images/banner.jpg"
  format="auto"
  alt="Banner"
/>

If your CDN or image storage provides the corresponding files:

banner.avif → banner.webp → banner.jpg

You can also use it with image services such as Cloudinary or other CDNs that provide optimized image formats.

The package doesn't convert the images itself. It simply uses the available AVIF/WebP versions and falls back to the original image when needed.

Check it out:

NPM: https://www.npmjs.com/package/@concatstring/react-smart-image

GitHub: https://github.com/concatstring-account/react-smart-image

Demo: https://react-smart-image.netlify.app/

How I Made My React Website Load Faster by Fixing Images

Jaimin Patel — Mon, 07 Sep 2026 19:28:55 +0000

The easiest performance win in React isn't always your JavaScript. Sometimes it's your images.

I used to think performance optimization meant splitting bundles, memoizing components, and chasing Lighthouse scores.

Then I opened Chrome DevTools on one of my own React projects.

The result? Images were quietly eating most of the page weight — way more than my JS bundle, my fonts, everything else combined.

A hero banner that looked perfect on my laptop was making mobile users download a multi-megabyte file just to see a heading.

That's when it clicked: image optimization isn't a nice-to-have. It's one of the fastest ways to make a React site actually feel faster.

Here's exactly what I changed.

Why Image Optimization Matters

Every extra second of load time costs you something — a visitor who bounces, a search ranking that slips, a bandwidth bill that keeps climbing.

None of that is dramatic on its own. But it adds up fast, and images are usually where it's hiding.

First Rule: Stop Uploading Giant Images

We've all done it.

Designer sends a beautiful 4000×3000 image.

We drop it into React.

Then display it inside a 400px card.

The browser still downloads the full file — every pixel of it, whether you show it or not.

Instead, match your image size to where it's actually displayed:

Device	Image Width
Mobile	400px
Tablet	800px
Desktop	1200px

Your users won't notice the difference in quality. They'll definitely notice the faster loading.

The Two Formats I Use for Almost Every Project

WebP — if you're still serving JPEGs everywhere, you're leaving free performance on the table. WebP usually keeps the same visual quality while shrinking the file size significantly.

Example:

JPEG → 500KB
WebP → around 320KB

That's hundreds of kilobytes saved without changing your design at all.

AVIF — takes compression even further. I've seen hero images drop from 500KB to nearly 200KB with almost no visible quality loss. Browser support is good enough now that it's worth using wherever you can.

Lazy Loading Is Basically Free Performance

One thing I always ask myself now: "Does this image need to load immediately?"

Usually the answer is no.

Gallery images. Blog thumbnails. Testimonials. Footer logos. All of these can wait until users actually scroll near them.

React makes it ridiculously simple:

<img
  src="/gallery/photo.webp"
  alt="Gallery"
  loading="lazy"
/>

One attribute. Less network traffic. Faster initial load.

But Don't Lazy Load Everything

Your hero image is different. If it's the biggest thing users see first, load it immediately — not lazily.

The Hero Image Can Make or Break Your LCP

Google's Largest Contentful Paint (LCP) is often just your hero image, plain and simple.

If it's delayed, your performance score suffers. Instead of this:

<img src="/hero.webp" loading="lazy" />

Use this:

<img
  src="/hero.webp"
  loading="eager"
  fetchPriority="high"
  alt="Hero"
/>

Small change. But now the browser knows this image deserves priority over everything else on the page.

The Page Jump Problem (CLS)

Have you ever tried clicking something and the page suddenly moved because an image loaded underneath your cursor?

That's Cumulative Layout Shift. The browser didn't know how much space to reserve, so it grabbed space the moment the image arrived — shoving everything else out of the way.

Bad:

<img src="/product.jpg" alt="Product" />

Better:

<img
  src="/product.jpg"
  alt="Product"
  width={600}
  height={400}
/>

Or use CSS:

.product-image {
  aspect-ratio: 3 / 2;
}

Now the layout stays stable while the image loads, no matter how slow the connection is.

Mobile Users Don't Need Desktop Images

This is probably the biggest missed opportunity I see in React codebases.

Why send a 1200px image to someone on a 390px phone? That's exactly why srcSet exists:

<img
  src="/image-800.webp"
  srcSet="
    /image-400.webp 400w,
    /image-800.webp 800w,
    /image-1200.webp 1200w
  "
  sizes="(max-width: 768px) 100vw, 800px"
  alt="Responsive"
/>

The browser automatically picks the right version. No complicated logic. No JavaScript required.

The Image Component I Kept Rebuilding

After repeating these optimizations across multiple projects, I noticed I was writing the same image component again and again. Every project needed:

Lazy loading
Blur placeholders
Skeleton loaders
WebP support
AVIF support
Priority loading for hero images
Aspect ratio to prevent CLS

So I turned it into a reusable package.

React Smart Image

Instead of wiring everything manually, I can now just write:

import { SmartImage } from "@concatstring/react-smart-image";

<SmartImage
  src="/hero.webp"
  alt="Hero"
  width={1200}
  height={700}
  priority
  aspectRatio="12:7"
/>

It handles most of these best practices automatically — which saves real time, especially on bigger React projects with hundreds of images scattered across pages.

My Go-To Image Optimization Checklist

Before shipping any React page, I run through this quickly:

Resize images before uploading
Use WebP or AVIF whenever possible
Lazy load below-the-fold images
Prioritize the hero image
Set width and height (or aspect ratio)
Use srcSet for responsive images

Five minutes on this list usually saves users several seconds of loading time. Honestly, it's one of the highest-ROI optimizations I've found in React — full stop.

Try React Smart Image

If you don't want to configure every image manually, check out the package I built.

React Smart Image — lazy loading, blur placeholders, skeleton loaders, WebP & AVIF support, LCP priority loading, responsive images, and CLS prevention, all in one component.

NPM Package: https://www.npmjs.com/package/@concatstring/react-smart-image
GitHub: https://github.com/concatstring-account/react-smart-image
Live Demo: https://react-smart-image.netlify.app/
Product Page: https://labs.concatstring.com/products/react-smart-image

If you're building React apps regularly, these small image optimizations add up — and your users (and your Lighthouse score) will thank you for it.

React Lazy Loading Images: A Simple Guide to Better Performance

Jaimin Patel — Mon, 31 Aug 2026 18:40:39 +0000

Images are important for modern websites, but loading too many images at once can slow down a React application.

If a page contains 30 images, users may only see 4–5 of them initially. There is no reason to load all 30 images immediately.

That's where lazy loading helps.

What Is Lazy Loading?

Lazy loading means delaying the loading of an image until it is needed.

Instead of:

Page loads
↓
Load every image
↓
Show page

Lazy loading works more like:

Page loads
↓
Load visible images
↓
User scrolls
↓
Load images near the viewport

This can reduce unnecessary network requests and improve the initial loading experience.

For more information, see the MDN Lazy Loading Guide.

Why Does Lazy Loading Improve Performance?

Images can be large and consume a significant amount of bandwidth.

Lazy loading helps by:

Reducing initial network requests
Reducing bandwidth usage
Loading important content sooner
Improving the experience on slower connections
Avoiding downloads for images the user never views

However, lazy loading does not make the image file smaller. You should still optimize image dimensions, compression, and formats such as WebP or AVIF

Native Lazy Loading

Modern browsers support native lazy loading through the loading attribute.

<img
  src="/images/product.jpg"
  alt="Product"
  loading="lazy"
/>

The browser decides when to load the image based on its distance from the viewport.

This is usually the simplest solution and doesn't require an additional JavaScript library.

Lazy Loading in React

You can use the same approach directly in React:

function ProductImage() {
  return (
    <img
      src="/images/product.jpg"
      alt="Product"
      loading="lazy"
      width="800"
      height="600"
    />
  );
}

Adding width and height also helps the browser reserve space for the image and can reduce unexpected layout shifts.

For responsive image techniques, see MDN's Responsive Images Guide.

Above-the-Fold vs Below-the-Fold Images

Not every image should be lazy loaded.

Above-the-fold images are visible when the page initially loads.

Examples:

Hero image
Main product image
Important banner

These images generally shouldn't be unnecessarily lazy loaded because they may be important to the initial page experience.

Below-the-fold images are not immediately visible.

Examples:

Product grid images
Blog images further down the page
Gallery images
Footer images

These are good candidates for lazy loading.

A simple rule:

Above the fold
→ Load normally / prioritize

Below the fold
→ Lazy load

When Should You NOT Lazy Load?

Avoid lazy loading an image when it is:

The main hero image
The primary LCP image
Immediately visible to the user
Critical to understanding the page

For example:

// Important hero image
<img
  src="/hero.jpg"
  alt="React performance"
/>

Don't automatically add loading="lazy" to every image.

The goal isn't "lazy load everything."

The goal is:

Load important images early and delay images that aren't immediately needed.

A Practical React Example

A product page might use:

function ProductPage() {
  return (
    <>
      {/* Important image */}
      <img
        src="/hero.jpg"
        alt="Product"
        width="1200"
        height="700"
      />

      {/* Below-the-fold images */}
      <img
        src="/product-1.jpg"
        alt="Product 1"
        loading="lazy"
        width="800"
        height="600"
      />

      <img
        src="/product-2.jpg"
        alt="Product 2"
        loading="lazy"
        width="800"
        height="600"
      />
    </>
  );
}

This gives the browser a clear strategy:

Important image → Load early
Non-critical image → Lazy load

Need More Image Features?

For applications that need more than native lazy loading, React Smart Image provides features such as lazy loading, priority loading, blur placeholders, skeleton loading, WebP/AVIF support, retry handling, image zoom, and aspect-ratio support.

import SmartImage from "@concatstring/react-smart-image";

<SmartImage
  src="/images/product.jpg"
  alt="Product"
  lazy
  width={800}
  height={600}
/>

React Smart Image

Website: React Smart Image
GitHub: View source code
npm: Install from npm
Live Demo: Try the demo

Final Takeaway

Lazy loading is a simple way to avoid loading images that users don't need immediately.

Remember:

Visible and important → Load early
Below the fold → Lazy load
Large images → Optimize
Modern formats → Consider WebP/AVIF

Lazy loading works best when it is part of a complete image optimization strategy—not when it is applied to every image blindly.

React Smart Image: The Free React Image Optimization Library Every Developer Should Try

Jaimin Patel — Thu, 02 Jul 2026 19:47:51 +0000

If you've built more than one React app, you've probably written the same image-loading boilerplate more than once.

A skeleton here. A lazy-loading IntersectionObserver there. A fallback image when the CDN hiccups. A blur placeholder to avoid layout shift. Retry logic for flaky hosts.

Every new React project ends up with the same image-loading code—copied from the last project, tweaked a little, and rarely perfect.

Sound familiar?

@concatstring/react-smart-image brings all of those features together in a single component. Simply swap <img> with <SmartImage> and opt into features like lazy loading, WebP detection, blur placeholders, skeleton loaders, retries, responsive images, and performance metrics—all without changing your existing code.

Getting started only takes a minute:

npm install @concatstring/react-smart-image

Key Features

✅ Drop-in replacement for <img>
✅ Zero runtime dependencies
✅ Fully typed with TypeScript
✅ Responsive image support
✅ Lazy loading
✅ Skeleton loaders
✅ Blur placeholders
✅ Retry with exponential backoff
✅ Error fallbacks
✅ Automatic WebP detection
✅ Image performance metrics
✅ Works with React 18+

🔗 Live Demo

Why We Built React Smart Image

Across multiple React projects, we found ourselves implementing the same image-loading logic repeatedly. Some projects needed lazy loading, while others required blur placeholders, retry logic, responsive images, or skeleton loaders. Maintaining separate implementations for each project quickly became repetitive and difficult to scale.

We wanted a single component that behaves like a normal <img> while providing modern image optimization features only when needed.

That's why we built React Smart Image.

Instead of maintaining multiple utilities across projects, I now use one component everywhere and simply enable the features I need with a few props. The result is cleaner code, a more consistent developer experience, and better image performance out of the box.

Drop-in Replacement

Replacing your existing images is as simple as swapping the component:

import { SmartImage } from '@concatstring/react-smart-image';

<SmartImage src="/photo.jpg" alt="A photo" width={800} height={600} />

className, style, onClick, loading, ref — all forwarded to the real <img>. Nothing new to learn. Enable additional features only when you need them—one prop at a time.

1. Lazy loading that actually waits for the viewport

<SmartImage src="/hero.jpg" alt="Hero" width={1200} height={600} lazy />

Images load 100px before they scroll into view — powered by IntersectionObserver, no scroll listeners, no jank.

2. Skeleton loaders (with dark-mode support)

<SmartImage
  src="/avatar.jpg"
  alt="User avatar"
  width={80}
  height={80}
  skeleton
  skeletonColor="#1f2937"
  skeletonHighlightColor="rgba(255,255,255,0.12)"
/>

An animated shimmer while the image loads — themeable to your brand or dark UI.

3. Blur placeholders — manual or automatic

Pass a tiny base64 LQIP the Next.js way:

<SmartImage src="/landscape.jpg" alt="Landscape" width={1200} height={800}
  placeholder="blur" blurDataURL="data:image/jpeg;base64,/9j/4AAQ..." />

Or skip the base64 entirely. If your CDN resizes by URL (Cloudinary, imgix, CloudFront…), autoBlur derives the preview for you:

<SmartImage src="/landscape.jpg" alt="Landscape" width={1200} height={800}
  placeholder="blur" autoBlur blurWidth={24} />

4. Retry with exponential backoff + fallback

CDNs fail. Handle it declaratively instead of with a tangle of onError handlers:

<SmartImage
  src="/flaky-cdn.jpg"
  alt="Product"
  width={400}
  height={300}
  retry={3}
  retryDelay={500}          // 500ms → 1s → 2s
  fallback="/placeholder.png"
/>

5. WebP auto-detection

Try the modern format first, fall back automatically if it 404s:

<SmartImage src="/photo.jpg" alt="Product" width={600} height={400} webp />

6. Responsive images — two strategies

The default srcset strategy lets the browser pick (DPR-aware). The viewport strategy always serves the smallest bytes per screen, ignoring device pixel ratio:

<SmartImage
  src="/banner.jpg"
  alt="Banner"
  responsive
  strategy="viewport"
  sizes={{ mobile: 480, tablet: 768, desktop: 1200 }}
/>

Screen	`srcset` (default)	`viewport`
Mobile @1×	480w	480w
Mobile @2×	1200w (DPR-aware)	480w
Desktop	1200w	1200w

Host encodes size in the path instead of ?w=? Point it wherever you want with srcSetBuilder:

srcSetBuilder={(src, width) => src.replace(/(\.\w+)$/, `-${width}$1`)}
// /photo.jpg → /photo-480.jpg

Compose everything

The features are orthogonal — stack them:

<SmartImage
  src="/product.jpg"
  alt="Product photo"
  width={600}
  height={600}
  lazy
  skeleton
  webp
  fallback="/placeholder.png"
  retry={2}
  retryDelay={1000}
  onLoadInfo={({ loadTime, fromCache }) =>
    console.log(`Loaded in ${loadTime}ms (cache: ${fromCache})`)
  }
/>

That onLoadInfo callback hands you loadTime, naturalWidth/Height, and a fromCache flag — real performance telemetry per image, for free.

Why not just use `next/image`?

next/image is great — if you're on Next.js. react-smart-image works in any React app: Vite, CRA, Remix, Gatsby, a plain SPA. No image server required, no framework lock-in, no runtime dependencies. Think of it as a modern, framework-agnostic upgrade to the standard <img> element.

Try it

npm install @concatstring/react-smart-image

📦 npm
💻 GitHub
🔗 Live Demo

If React Smart Image saves you from writing the same image-loading code again, I'd really appreciate a ⭐ on GitHub.

Feedback, feature requests, and bug reports are always welcome. If there's a feature you'd like to see, let me know in the comments or open an issue.

Built by the team at Concatstring.

DEV Community: Jaimin Patel

How Responsive Images Work in React: srcSet, sizes, DPR and CDNs

Responsive Images in React

srcSet and sizes

DPR and High-Density Screens

Where Does a CDN Fit?

Using Responsive Images in React

When Should You Use Each One?

Final Thoughts

WebP vs AVIF: Which Image Format Is Better for React?

What is WebP?

What is AVIF?

WebP vs AVIF: File Size

Browser Support

What About Image Quality?

Using WebP and AVIF in React

Final Thoughts

Related React Smart Image NPM

How I Made My React Website Load Faster by Fixing Images

React Lazy Loading Images: A Simple Guide to Better Performance

What Is Lazy Loading?

Why Does Lazy Loading Improve Performance?

Native Lazy Loading

Lazy Loading in React

Above-the-Fold vs Below-the-Fold Images

When Should You NOT Lazy Load?

A Practical React Example

Need More Image Features?

React Smart Image

Final Takeaway

React Smart Image: The Free React Image Optimization Library Every Developer Should Try

Sound familiar?

Getting started only takes a minute:

Key Features

Why We Built React Smart Image

Drop-in Replacement

1. Lazy loading that actually waits for the viewport

2. Skeleton loaders (with dark-mode support)

3. Blur placeholders — manual or automatic

4. Retry with exponential backoff + fallback

5. WebP auto-detection

6. Responsive images — two strategies

Compose everything

Why not just use next/image?

Try it

Why not just use `next/image`?