next/image - out of the box blur support for external images

[akratzel]

Describe the feature you'd like to request

As of now, using placeholder="blur" only works out of the box for statically imported images. Otherwise we would have to define a blurDataUrl property which would load a small version of that very image - but this placeholder image would have to be served via a custom server using e.g. blurhash.

Describe the solution you'd like

Passing placeholder="blur" should be enough for the user in order to enjoy the blur up effect - even for external hosted images (e.g. headless CMS).

<Image
  src="https://path.to/external/image.jpg"
  alt="using placeholder without blurDataUrl should work"
  placeholder="blur"
  layout="fill"
/>

Describe alternatives you've considered

Alternatives atm are using a custom server as described above. Next.js mentions blurha.sh which would be fine, but stilll - it causes an additional overhead that might not be necessary.

[JohnDeved]

my quick workaround for now (this works right now):

<Image
  src={imageURL}
  placeholder="blur"
  blurDataURL={`/_next/image?url=${imageURL}&w=16&q=1`}
  ...
/>

I know it's not optimal, since a base64 string embedded in the html wouldn't have to be loaded at all. but having a placeholder image that is only ~3kb to load is better than nothing

[JohnDeved]

optimally what the Image component maybe should be doing is if no blurDataURL param is passed, it should check if it is currently running on the server or client side.
if running on server (in case of SSR or static prerender), embed a base64 string in the html.
if running on client (in case of dynamically added image by JS), use /_next/image api to fetch a tiny (cached) placeholder image

[timneutkens]

This approach will severely affect loading performance of your application (FCP, LCP).

[JohnDeved]

@timneutkens If you mean the workaround, I agree. it's definitely not optimal and will affect LCP. If you cant get a blur b64 of the image on SSR, it's just a quick way to reduce image poping on the page.

I think it would be a good idea for nextjs to handle the placeholder image generation for you on SSR, since it can get messy doing that yourself inside getStaticProps/getServerSideProps yourself for dynamically generated content pages.

the base64 string embedded is obviously only supposed to be a small placeholder image, the same kind you would pass to blurDataURL yourself to be included in the image background CSS.
In a way it would be the same as getting the blurData in getStaticProps/getServerSideProps and passing it to the Image component, only that nextjs would take care of that step for you.

& using a tiny image as a placeholder served from the nextjs image API for dynamically added elements is a good enough fallback I think, better than nothing. it may affect LCP a tiny bit (not if it happens in runtime), but it's better than image poping on the site imo.
maybe that could be opt-in.

[adityaa72]

This will not work in production mode

[joe-bell]

In the meantime, you could use plaiceholder to get the img attributes and base64 (blurDataUrl) placeholder.

Demo
https://with-next.plaiceholder.co/base64/single

Code

import * as React from "react";
import { InferGetStaticPropsType } from "next";
import Image from "next/image";
import { getPlaiceholder } from "plaiceholder";

export const getStaticProps = async () => {
  const { base64, img } = await getPlaiceholder(
    "https://images.unsplash.com/photo-1621961458348-f013d219b50c?auto=format&fit=crop&w=2850&q=80",
    { size: 10 }
  );
  return {
    props: {
      imageProps: {
        ...img,
        blurDataURL: base64,
      },
    },
  };
};

const ExamplePage: React.FC<InferGetStaticPropsType<typeof getStaticProps>> = ({
  imageProps,
}) => <Image {...imageProps} placeholder="blur" />;

export default ExamplePage;

[ooloth]

This works great for me (and the placeholders look better than Next's default ones for imported images), so thanks!

[sherry-li-or]

sorry I want use this,
but show ReferenceError: require is not defined,
how can I solved? 😢

[anthonyjacquelin]

"ReferenceError: require is not defined"

Exact same problem.. @joe-bell

[joe-bell]

Sounds to me like you're trying to use Plaiceholder in the client – this is not supported

You can only use it in getStaticProps or other server-side functions

[anthonyjacquelin]

I've done this:

const { withPlaiceholder } = require("@plaiceholder/next");

module.exports = withPlaiceholder({
// your Next.js config
});

and then paste this to an 'example.tsx' file:

import type { InferGetStaticPropsType } from "next";
import Image from "next/image";
import { getPlaiceholder } from "plaiceholder";

export const getStaticProps = async () => {
  const { css, img } = await getPlaiceholder("/path-to-your-image.jpg");

  return {
    props: {
      img,
      css,
    },
  };
};

const Page: React.FC<InferGetStaticPropsType<typeof getStaticProps>> = ({
  img,
  css,
}) => (
  <div style={{ position: "relative", display: "block", overflow: "hidden" }}>
    <div
      style={{
        position: "absolute",
        top: 0,
        right: 0,
        bottom: 0,
        left: 0,
        width: "100%",
        height: "100%",
        transform: "scale(1.5)",
        filter: "blur(40px)",
        ...css,
      }}
    />

    <Image {...img} />
  </div>
);

export default Page;```

According to the documentation for Next.js. Did i wrongly understood the doc ?
Thank you 

[IHIutch]

Ive been playing with this myself and Im running into a similar issue. Maybe I'm not understanding the use case well enough, but my use case is as follows:

1. User can upload an image to my app. When the file input changes I can either generate a base64 string (currently by shortcutting some blurhash functionality), or by using the blurhash functions outright I can get a blurhash string.

2. Then I save the image to by storage bucket and in my DB as {src: 'https://mybucket.com/myimage', hash: 'base64orBlurhashString'}

3. User navigates to where this image would load/display. At the moment I'm not handling this page on the server at all, but will be (is this my problem?). I pull down the blurry image as the placeholder, wait for the image src to load, and then show the image.

   The blurhash string does nothing for me with next/image obviously, so I can use react-blurhash instead. Or I can take the base64 string and use it with next/image. Cool. But I'm not sure I understand the benefit I get from next/image, when it feels like I have to do more just to generate the base64 string initially.

4. The next/image seems to work with placeholder="blur" but although it doesn't transition nicely from blur to full-res.

FWIW, layout="fill" doesn't seem to be working correctly for me either, but that might just be because I haven't explicitly defined the height and width.

@joe-bell I can't seem to get plaiceholder working at all for that use case. I keep getting an fs not found error. Is this for static props/server props only? Should my workflow be different?

Maybe I'm in over my head here. But it seems like it should be way easier to encode a blurry image and decode it with next/image. Even blurha.sh doesn't seem to just "work" out of the box. An example, as I brought up here, would be really helpful. Just to wrap my head around it all.

[joe-bell]

I think you should be able to achieve this just by passing the publicURL as the getPlaiceholder parameter in the example I've provided

[IHIutch]

Yes, that makes sense. I guess I'm still trying to understand the value of that approach over generating the hash at upload time (say, if Im not using getStaticProps). Maybe there is a better place to ask, but that's what I'm wondering about.

Like, if I generate a hash at upload time, I can do it once and save it to my DB. I understand that getStaticProps doesn't really have a performance impact because that would happen "once" too, at build time. But what about something like getServerSideProps or if I'm fetching on the client, etc? It seems like in the case of getServerSideProps, I'd be generating the same hash over and over for each request, even though the image stays the same. For client-side fetching, it seems like I'd already want to have the blur ahead of the fetch request.

In my mind, unless I'm not understanding correctly, those two use cases would have the most to gain out of the blurred placeholder anyway.

[ProSystemLimited]

I think you should be able to achieve this just by passing the publicURL as the getPlaiceholder parameter in the example I've provided

I would like to have an idea on how getPlaiceholder processes the image and returns the data. It's really amazing how well it goes along with the new blur placeholder of nextjs image component and I'm really thankful that I've came across this. However, I'm concerned how much it will affect my initial load time.

My website consists of a lot images and all of them are dynamic content and fetched from external source. I've got it to work just fine but would like to know if there is a better way of implementing this since I've just discovered Plaiceholder.

Basically, I'm querying data directly from my database using getServerSideProps. The image name is stored in this data and I'm looping through it and calling getPlaiceholder to generate the base64 encoded string for each image. I am pushing the string to an array so that I can have all of them stored and then passing it to my component as props. After that I'm being able to access the blurred image through indexing.

Would like to know if I could directly call getPlaceiholder function inside the blurDataUrl attribute and return a base64 string for the placeholder. Or is there a better way which I'm not being able to figure out.

Next Js has sure come up with a wonderful feature but would be better if they could've provided an example use case for dynamic content. But Placeiholder works almost perfect!

[ProSystemLimited]

I think you should be able to achieve this just by passing the publicURL as the getPlaiceholder parameter in the example I've provided

I would like to have an idea on how getPlaiceholder processes the image and returns the data. It's really amazing how well it goes along with the new blur placeholder of nextjs image component and I'm really thankful that I've came across this. However, I'm concerned how much it will affect my initial load time.

My website consists of a lot images and all of them are dynamic content and fetched from external source. I've got it to work just fine but would like to know if there is a better way of implementing this since I've just discovered Plaiceholder.

Basically, I'm querying data directly from my database using getServerSideProps. The image name is stored in this data and I'm looping through it and calling getPlaiceholder to generate the base64 encoded string for each image. I am pushing the string to an array so that I can have all of them stored and then passing it to my component as props. After that I'm being able to access the blurred image through indexing.

Would like to know if I could directly call getPlaceiholder function inside the blurDataUrl attribute and return a base64 string for the placeholder. Or is there a better way which I'm not being able to figure out.

Next Js has sure come up with a wonderful feature but would be better if they could've provided an example use case for dynamic content. But Placeiholder works almost perfect!

Okay so I have just deployed the production build and it takes too long for the route change. It is not feasible to call getPlaiceholder in serverSideProps as all the processing is done on each request.

Really in need of a solution

[joe-bell]

@ahnaf0595 it's not really designed for getServerSideProps usage – it's best for build-time, or for building APIs that would be consumed at build time

An alternate suggestion for you is that you run a Node.js script prior to build/hooking into the build process, and execute a Promise.all that runs getPlaiceholder for each image. You could then store that result in a JS/JSON file, using the URL as a key

[stubar]

I ended up using Jimp in the end to get base64 data in getStaticProps like this

const image = await axios.get(src, { responseType: 'arraybuffer' });
  const jimpImage = await jimp.read(image.data);
    const resized = jimpImage.resize(50, AUTO);
    base64 = await resized.getBase64Async(MIME_JPEG);

I can't help thinking it would be better if next/image took care of this. If you opt into it Next/Image could generate the base64 string at build / runtime on the server. Also perhaps you could opt in to have it cached in .next/cache as our images are generally immutable in the sense that if they change a new url is generated (my build times have swelled crazily since the above code). Also I think it's wasteful that the base64 string is in NEXT_DATA AND the image style tag. If next/image owned base64 it could just put it in the style attribute and not have them cascade down the react tree as props.

Also a question that I'd like to ask, in the server rendered html the src is also a very small gif base64 string. Is there no way the proper src and srcsets can be sent so even without js images properly load?

[sanderkooger]

This might be a daft idea, But if you are talking uploaded images in your app that you host on an external CDN or on S3 or something, write a routine that after the file is uploaded constructs the URL to fetch it via nextjs image processor to a buffer, add mimetype and push it as a data URI into your database? just create an extra column with blur_data_url in your image table.

This way you won't have to fiddle around with sharp or imagic, its just a fetch to buffer and then a crud operation.

[ProSystemLimited]

If the website has a lot of content with lots of images, then the databases would be bloated with long base 64 strings and it would also take up a lot of space. For example, a portfolio website

[sanderkooger]

I checked the strings are not that long.... shorter that most text. It also has the advantage of being able to grab the string in getStaticProps/getServersideProps

here is an example string

data:image/jpeg;base64,/9j/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAALABQDASIAAhEBAxEB/8QAGAAAAgMAAAAAAAAAAAAAAAAAAAgDBgf/xAAkEAACAgEEAQQDAAAAAAAAAAABAgMEEQAFBiESEyIxgUFRcf/EABUBAQEAAAAAAAAAAAAAAAAAAAAC/8QAGBEAAwEBAAAAAAAAAAAAAAAAAAERIRL/2gAMAwEAAhEDEQA/ALTsfEeQJx/d1v2Tbvt0iSTl4vId+39A9d/0aLfA91rbY8MFiKSWzIIfOLziaMM2fLOSeuvjWyU0Qw5KLkk561I0SMQCoxj41SzA43YKbY4jzOxIX2lblisC0fqNY7LoxRvrKn60aaFaVapmOrAkEZJcrGPEZJyTgfknRpC+2f/Z

this is a 20px wide image ( all you need)

I generate it during upload by feeding it to this function and returning the blurdataURL, that url gets inserted in the DB

import sharp = require('sharp');
import convertDataUri from './convertDataUri';

/**
 *
 * @param dataUri put in a base64 image string, and spits out usable parts for uploadImageFromUri function
 * @returns B64 image string
 */

const createBlurDataUri = async (dataUri: string): Promise<string> => {
  const { buffer } = convertDataUri(dataUri); <====== function that takes full b64 string and return the buffer only

  const sharpImg = sharp(buffer);
  const meta = await sharpImg.metadata();
  const placeholderImgWidth = 20;

  let placeholderImgHeight = null;
  if (meta.height && meta.width) {
    const imgAspectRatio = meta.width / meta.height;
    placeholderImgHeight = Math.round(placeholderImgWidth / imgAspectRatio);
  }

  const imgBase64 = await sharpImg
    .resize(placeholderImgWidth, placeholderImgHeight)
    .toBuffer()
    .then((buffer) => `data:image/${meta.format};base64,${buffer.toString('base64')}`);

  return imgBase64;
};

export default createBlurDataUri;

Even IF this would grow out of control it would be because our platform is growing like crazy, in that case it might be a better option to host the thumbnails table of your app in a separate DB anyways.

[leerob]

You can also achieve this with CSS. Here's an example with Tailwind CSS:

import Image from 'next/image';
import { useState } from 'react';
import cn from 'clsx';

function BlurImage(props) {
  const [isLoading, setLoading] = useState(true);

  return (
    <Image
      {...props}
      alt={props.alt}
      className={cn(
        props.className,
        'duration-700 ease-in-out',
        isLoading
          ? 'grayscale blur-2xl scale-110'
          : 'grayscale-0 blur-0 scale-100'
      )}
      onLoadingComplete={() => setLoading(false)}
    />
  );
}

[leerob]

...props is "spreading" the props object onto the Image component. Essentially just forwarding all of the props passed to the BlurImage component, like src for example. Yes, this works with images from external URLs.

[MikevPeeren]

Thanks @leerob,

Is there a way to disable the blur animation when the image is coming from cache ?

Oh and off topic where can i get that mug 🥇

[KrisKnez]

I would not recommend anyone do this. This is literally just an animation.

[DylanBulmer]

@KrisKnez I wouldn't come into this post and say that "I would not recommend anyone do this." Yes, it is an animation, but it provides an alternative way to show an image loading if the image is small/can be loaded fast.

I'm assuming you state that you don't recommend this because it doesn't solve the issue of faster loading times for larger images. The image needs to be loaded for this snippet to work. I think this bit of code is fantastic. But, it doesn't solve the issue that some people coming to this thread are looking to find.

I want to clarify this before people start labeling this snippet of code as "bad." 😄

[zidkim]

This is a great workaround in my case, as there's no overhead in terms of cost ($$) -- especially at scale.
Concerned that with the future remote blur support, Vercel will charge for this as well (already quite costly at scale).

Regarding performance (pixel,paint, etc), it may be worth testing adding 'will-change' as I heard some long-standing issues have been resolved.

[jim-spot]

I was able to solve this pretty well just using the Next image API to generate a small image with quality = 1. Like:

static getPlaceholderImageURL(imageURL: string): string {
        return `/_next/image?url=${encodeURIComponent(imageURL)}&q=1&w=128`
}

Then used like:

<Image src={props.featuredImageURL}
         blurDataURL={Utils.getPlaceholderImageURL(props.featuredImageURL)}
         placeholder="blur"
  />

[jim-spot]

Follow-up question— I get that static imports are great, but how do you actually get that to work with a CMS system where the images are stored on a remote CDN?

[styfle]

Caching Behavior for optimized images is described here https://nextjs.org/docs/api-reference/next/image#caching-behavior

The blur placeholder must be generated at build time because it can't be generated on-demand without affecting page load time. And even if you generated with next dev, you can't guarantee that cache is preserved and populated to every region in a CDN. So we treat the blur placeholder as a static file instead of optimized image.

[jim-spot]

Yeah I get that— It's similar to how a statically built page is always going to be faster than ISR, but Next.js does support ISR... So how is this any different than ISR, but for images instead of content?

As far as I see it:

1. Blur can be generated in a production runtime using the image API (unless you are using static export). I'm using it in prod with npm run start at the moment and it appears to work just fine.
2. Even though it may slow down a first page load, every subsequent page load after that (within the cache timeout) should load as quickly as if it were statically generated at build time.
3. The people who want remote-blur capability are most likely those who have thousands of images hosted on a CDN somewhere. And those people are already likely using ISR, so it doesn't seem like this would be a detriment to their operation because they are used to the "first-to-access = slow" tradeoff.

The one downfall I could see to this approach is that on a high-traffic site with lots of entropy in page access patterns you could potentially get into a thundering herd problem if you had to clear the entire cache— image optimization is relatively CPU intensive. But my guess is that most sites fit into the standard pattern of extremely concentrated access patterns into a relatively small set of images, so I can't imagine this being a concern for most.

[styfle]

The people who want remote-blur capability are most likely those who have thousands of images hosted on a CDN somewhere. And those people are already likely using ISR

Are you suggesting that we need ISR for images so that they can be fetched at build time? Something like getStaticPaths() but for the images you want to fetch at build time?

[jim-spot]

Are you suggesting that we need ISR for images so that they can be fetched at build time? Something like getStaticPaths() but for the images you want to fetch at build time?

TLDR;

Not asking for anything new. Next.js allows remote URLs for the Image component. Why does the placeholder="blur" attribute need to behave differently for local vs. remote images?

TL;

I'm not asking for Next.js to support anything new, just to add official support for something that already works. Throwing an error for placeholder="blur" when the URL is remote seems unnecessary. A little more detail.

If I have a site with hundreds or thousands of blog pages, my getStaticPaths most likely looks something like this:

export const getStaticPaths: GetStaticPaths = async () => {
    // Blog landing pages will be generated newly as they are accessed.
    const results: GetStaticPathsResult = {
        paths: [],
        fallback: "blocking"
    };

    return results;
};

And my getStaticProps function return looks like this:

return {
    props: {
       content: postFromCMS.content,
       featuredImageURL: postFromCMS.featuredImage.url
    },
    revalidate: REGENERATION_TIME_IN_SECS
  };

Which means that none of my blog posts are generated at build time— they are built JIT on the server.

Now if you look at the page which renders my blog, I would love to be able to do something like:

<Image src={props.featuredImageURL} placeholder="blur" layout="fill" sizes="50vw"/>

But because props.featuredImageURL is a remote URL, I will get a Next.js error which says I cannot do this— I must supply a blurDataURL.

Now here's the kicker: this is the exact output of an image in my production site with a local statically built image:

<img srcset="/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhome-hero.e35d7cd7.jpg&amp;w=640&amp;q=75 640w, /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhome-hero.e35d7cd7.jpg&amp;w=750&amp;q=75 750w, /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhome-hero.e35d7cd7.jpg&amp;w=828&amp;q=75 828w, /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhome-hero.e35d7cd7.jpg&amp;w=1080&amp;q=75 1080w, /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhome-hero.e35d7cd7.jpg&amp;w=1200&amp;q=75 1200w, /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhome-hero.e35d7cd7.jpg&amp;w=1920&amp;q=75 1920w, /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhome-hero.e35d7cd7.jpg&amp;w=2048&amp;q=75 2048w, /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhome-hero.e35d7cd7.jpg&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fhome-hero.e35d7cd7.jpg&amp;w=3840&amp;q=75" decoding="async" data-nimg="fill" style="position: absolute; inset: 0px; box-sizing: border-box; padding: 0px; border: none; margin: auto; display: block; width: 0px; height: 0px; min-width: 100%; max-width: 100%; min-height: 100%; max-height: 100%; object-fit: cover; object-position: 25% 50%;">

Notice how it still uses the image API?

And here is one which is referencing a remote image:

<img srcset="/_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fm5ehn3s5t7ec%2Fwp-image-199371%2Fb7fd11a576edc46a9ca6cfc71d84a51f%2FDog-Swimming-Guide.jpeg&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fm5ehn3s5t7ec%2Fwp-image-199371%2Fb7fd11a576edc46a9ca6cfc71d84a51f%2FDog-Swimming-Guide.jpeg&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fm5ehn3s5t7ec%2Fwp-image-199371%2Fb7fd11a576edc46a9ca6cfc71d84a51f%2FDog-Swimming-Guide.jpeg&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fm5ehn3s5t7ec%2Fwp-image-199371%2Fb7fd11a576edc46a9ca6cfc71d84a51f%2FDog-Swimming-Guide.jpeg&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fm5ehn3s5t7ec%2Fwp-image-199371%2Fb7fd11a576edc46a9ca6cfc71d84a51f%2FDog-Swimming-Guide.jpeg&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fm5ehn3s5t7ec%2Fwp-image-199371%2Fb7fd11a576edc46a9ca6cfc71d84a51f%2FDog-Swimming-Guide.jpeg&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fm5ehn3s5t7ec%2Fwp-image-199371%2Fb7fd11a576edc46a9ca6cfc71d84a51f%2FDog-Swimming-Guide.jpeg&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fm5ehn3s5t7ec%2Fwp-image-199371%2Fb7fd11a576edc46a9ca6cfc71d84a51f%2FDog-Swimming-Guide.jpeg&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fm5ehn3s5t7ec%2Fwp-image-199371%2Fb7fd11a576edc46a9ca6cfc71d84a51f%2FDog-Swimming-Guide.jpeg&amp;w=3840&amp;q=75" decoding="async" data-nimg="fill" style="position: absolute; inset: 0px; box-sizing: border-box; padding: 0px; border: none; margin: auto; display: block; width: 0px; height: 0px; min-width: 100%; max-width: 100%; min-height: 100%; max-height: 100%; object-fit: cover; object-position: center center;">

The only difference is the url parameter points to remote URL. But under the covers the image API is doing the exact same thing—

1. Is the image cached? If yes, return it.
2. If no, download the image from the url parameter.
3. Optimize it.
4. Save it to the cache.
5. Return the cached image.

The only difference with a statically built image and a remote image is this:

1. In a static local image, when a person first hits the page, the answer to number 1 is always yes.
2. In a remote-image, when a first person hiss the page, the answer to number 2 is always no.

But after a person first hits a page, a statically built image and a remote image work 100% exactly the same.

So the whole point is this: if a static local image and a remote image have nearly similar logic for the src attribute, why can't the same be said for the blur attribute? There is no real reason (I can see) that it needs to throw an error.

[iwgyyyy]

I'm using the "app folder", and I have a somewhat clumsy method that fits my use case:

'use client';

import Image from 'next/image';
import { useState } from 'react';
import classNames from 'classnames';

interface ImageWithBlurProps {
  src: string;
  className?: string;
  alt?: string;
  fill?: boolean;
}

export default function ImageWithBlur(props: ImageWithBlurProps) {
  const { src, className, alt = '', fill = false } = props;

  const [loaded, setLoaded] = useState<boolean>(false);

  return (
    <>
      <Image
        fill={fill}
        unoptimized
        className={classNames(className, { hidden: loaded, block: !loaded })}
        src={`${src}?image_process=resize,p_10`}  // You can modify this to use a remote URL as a placeholder.
        loading="eager"
        alt={alt}
      />
      <Image
        fill={fill}
        unoptimized
        className={classNames(className, { hidden: !loaded, block: loaded })}
        src={src}
        alt={alt}
        loading="eager"
        onLoadingComplete={() => setLoaded(true)}
      />
    </>
  );
}

[hatchli]

I believe this will have a sever impact on performance, per @timneutkens prior comment.

Unless I'm wrong, the only way to do this without negatively impacting performance is to have your cdn create the placeholder and store it. I was really wanting to implement thumbhash, but alas I'm using shopify's cdn and there's no dynamic image management there.

[musjj]

Are there any good solutions for blurring external images on client-side components? It seems that plaiceholder only works for server components.

[bookernath]

Previous to Next.js, in an MPA context, I used LazySizes to achieve this pattern on the Stencil framework on BigCommerce; we use a ~10px wide LQIP served straight from our CDN with negligible LCP or Web Vitals impact.

I believe it works just fine if you have a fast CDN to which the client is already connected; especially with HTTP/2 you can shovel dozens of <1kb assets into the browser in less than 30ms or so, and the experience can be quite nice.

In the case of BigCommerce, we've had this strategy live for 7+ years and it has been durable and high performance through many years of Core Web Vitals adjustments.

Demo example here:

https://v0-image-gallery-app-eight.vercel.app/

Certainly it is not as optimal as having inline base64 data, but as is clear in this thread the infrastructural needs necessary to pre-populate that data are sometimes difficult to satisfy or come with their own tradeoffs, so allowing this ability to use an external URL (even if it's not recommended) feels like a highly desirable compromise to me.