Image loading is super slow with next/image

[Aviisek]

I am using next/image as described

<Image
                alt='alt '
                src={getImage()}
                layout='fill'
                objectFit='cover'
                objectPosition='right bottom'
            />

but its superslow while loading the page

what could be the issue or its expected behaviour because of optimisation on demand ?

[Sandstedt]

@Aviisek Sounds like a server problem. What server and version are you using? How long waiting time do you have on other images? If you look at the response header, does it has a cache policy set? Working on converting our framework to using next/image, and has been very fast this far at least.

[Sandstedt]

I know, I haven't said anything otherwise. That's why we have switched to ImgIx handling the image generation instead of the current node sollution. In the meanwhile. This obviously need to be addressed.

[ghost]

just add package yarn add sharp

For any queries
https://nextjs.org/docs/messages/sharp-missing-in-production

It works amazing

[dagda1]

i tried that but nothing happened

[Alannek1992]

I have the same problem.. the initial load of the images takes incredibly long even though I have included sharp etc. next:12.0.9. Any ideas? After the initial load the images are probably cached and the problem is gone.

[stanislavyv]

just add package yarn add sharp

For any queries https://nextjs.org/docs/messages/sharp-missing-in-production

It works amazing

Still unreasonably slow, even with sharp

[kristianstroka]

Any updates on this? ... there are more new versions, but still same issue with images ... :(

[deadcoder0904]

@kristianstroka nope, subscribe to this issue → #23637

[simplenotezy]

I believe a workaround could be if you could modify the "cache-control" header. In such case I could have my Cloudflare Worker proxy cache the image, since I don't expect them to change ever really.

[dagda1]

I have been experiencing this. I just waited 20 seconds while demoing to a client for the images to appear. I was very embarrased

[Sandstedt]

@dagda1 Been there. Feel the pain.

Just upgrade to next 11 or 12 and make sure you run npm install sharp (and make sure it's installed on the server too), and you will be all set (it's so much faster then the default arm-optimized image processing).

And set minimum cache ttl in next.config.js:

images: {
    minimumCacheTTL: 31536000,
}

[dagda1]

@Sandstedt thank you. I'm on next 11 and I have the sharp package installed in "dependencies".

How would it not be installed on the server? That sounds like something that might be happening.

I'll update my config to use the minimumCacheTTL.

[Sandstedt]

@Sandstedt thank you. I'm on next 11 and I have the sharp package installed in "dependencies".

How would it not be installed on the server? That sounds like something that might be happening.

I'll update my config to use the minimumCacheTTL.

Run npm ls sharp in the project root on the server to see if it's installed.

Else maybe monitor the CPU performance to see if it's a bottleneck there. We're usually fine with the lowest tier on Digital Oceans dedicated servers.

Also make sure that the images gets a long cache time in the http headers. A year is probably good at least. Else the generated images won't be saved.

You can also make sure you don't delete the .next/images folder (maybe it's .next/cache/images or something) while ex rsync'ing up files to the server. Else you will delete all previous generated files on the server when deploying a new version.

[dagda1]

@Sandstedt I tried the above suggestions but they did not improve anything that much.

I just removed all next/image from my repo and moved all static content delivery to cloudfront and here are the results:

next/image was a horrendous experience, I wasted a lot of time trying to make this work and for no reason. I find a lot of vercel opaque and the advice was to use the sharp package but I have no idea whether it was working or not and I definitely used it but there was no feedback to say whether it worked or not.

I love how easy vercel is to deploy via git push. I love the temporary preview URLs although I do find this unreliable but for images and static asset serving, I found it pretty awful and no real way to make things better outside of next.config.

[Sandstedt]

Oh, I have not idea if my suggestion works in Vercel. I was talking about e regular deployment to our own servers. (We're using Digital Ocean and Ubuntu servers). But yeah, there is zero feedback on what image engine is in use, more than without Sharp it's super slow on Linux servers.

But great you solved it in another way.

[dagda1]

the sharp thing is totally opaque. It appears to work for some but not others. There are no logs or way of knowing what is happening.

I ended up putting my images in AWS cloudfront

[BelalKhalifaKP]

@dagda1 How do you load you images from the CDN, I got the same problem, but with remote images. They seem to load twice idk what's wrong and the sharp thing is not really working. The CDN itself is extremely fast, but then the image loads for a second time for seconds.

[tooshikii]

I experience the same issue on my app deployed on AWS, amplify although I'm setting up sharp as an image loader with environmental variables set up as cited in the issue here.
#23637

Has anyone encounterd the same issue and found a sloution ?

[MonkeyHenry]

@tooshikii Did you solve your problem? I'm also using AWS Amplify and tried a bunch of different things suggested in this thread to no avail.

[Alireza17224]

Same problem

[Tosinkoa]

Pls is there any solution yet? am also facing this problem

[Alireza17224]

To fix this problem, first put the most important images to
priority={true}

this prop will delete the lazy load from your image and it will be much faster!

Also installing sharp can improve this action

yarn add sharp

npm install sharp

[atomoc]

genius

[MONTYYYYY]

same. here next js version: 12.3.1

[M1ck0]

I am facing this issue since next 10 I think, no one seemed to care then, and no one seems to care now. Sad

[lazyflog]

next image -> img is working to me!

[techinp]

I have stopped to use next/image change to use <img/> instead while waiting for fix this problem!

[dagda1]

Do you know vercel actually charge for image optimization. I hope it is not based on this solution because it does not work for a lot of people and the whole process is totally opaque

[dagda1]

I think vercel are in denial on thus one. I've had sharp installed forever but I get the same lazy answer that it works on my machine. The whole thing is opaque with no feedback if I'm getting oprimization or not apart from how God damn slow the images are to load. To charge for this is a joke and I'm going to move to remix and be done with next which is very slow on lots of counts

[M1ck0]

Loading the initial image is much faster now.

This code sample that you sent is not from the new next/image. This is next/legacy/image as half of these params are not available anymore, or have been renamed.

Also, don't use loading prop as it can degrade performance. You should use priority

https://nextjs.org/docs/api-reference/next/image#loading

[Charlio99]

Loading of the initial image is much faster now.

This code sample that you sent is not from the new next/image. This is next/legacy/image as half of these params are not available anymore, or have been renamed.

Is there anything to do besides upgrading to next13? I updated from next12 to next13 last week just bumping the next version in the package.json (and the requirements)

[M1ck0]

<Image
  src="SOMELOCALPATH.WEBP"
  fill
  priority
  alt=""
  className="absolute inset-0"
  draggable="false"
/>

objectFit and objectPosition are deprecated now. You should set them through css. Try this and tell me if it works any better.

Read more here

[Charlio99]

<Image
  src="SOMELOCALPATH.WEBP"
  fill
  priority
  alt=""
  className="absolute inset-0"
  draggable="false"
/>

objectFit and objectPosition are deprecated now. You should set them through css. Try this and tell me if it works any better.

Read more here

Still slow. When the web loaded faster what I did is to rollback to next12

[sedouard]

Still slow. When the web loaded faster what I did is to rollback to next12

Same here. I've upgraded to Next 13 and ensured sharp is installed and available. I even set NEXT_SHARP_PATH to the absolute path of the sharp NPM directory.

[winchell]

There are almost certainly multiple causes in this thread but this bug disappeared when I stopped creating my own server.js that included custom launch code like new NextServer({. When I let the build create the server.js (as designed -- this should be the norm), the Image component works as expected.

[jsandovalg]

[M1ck0]

Putting unoptimized={true} is the same as if you are default HTML <img/> tag

When true, the source image will be served as-is instead of changing quality, size, or format. Defaults to false.

[consal]

I use the recent nextjs 13, deploy on Vercel. My images are around 200kb, I have Embla carousel with the images. Sometimes the images take a couple of seconds to load... Does anyone have a working solution? I installed sharp, it didn't change anything.

[xie392]

Me too, have you solved this problem now?

[jserrao]

Hacky, but you could pretty easily build your own image component and then try to load all of your images via something like S3. You can basically just go around the whole optimization if you want.

[quoctruongdev]

I am also facing the same problem in next js 13.4.12.

[damirdjukanovic]

Facing the same issue, I've removed the avif from formats in next.config.js and it does load faster, but still a bit slow.

images: { formats: ['image/webp'] }

[stanislavyv]

They do mention that avif takes 20% more time to generate, but still...

[bluengreen]

I've done numerous a/b comparisons and still not understanding where vercel gets this notion that next/image makes images load "faster". Thats just not true. I suppose if I uploaded a photo directly from my camera, full size, it might be faster as it scales and optimizes that image. I've found just doing some pre-processing and/or using a CDN, (cloudfront, cloudflare, etc) is soooooooo much faster its not even remotely close. I'm using Bunny CDN and optimizing by passing a query string to set the size, crop etc, but any of these inline CDN processors will work. It's obscene the difference in speed.

Another thing to consider is next/image requires a serverless function to run. Even if you create a separate loader. I found this out when they sent me a message saying that images will no longer load cause I blew past the 1000 invocation limit in the free vercel hosting. I re-wrote my loader into my own wrapper function and voila - no more limits.

Also, you want to be mindful on where you use next/image. Because of these constraints like the function invocation, and requiring window before rendering the image, your design layout will shift as the images become available to load. So for something critical like your logo in the upper left corner you will want to just use the plain old img tag with an optimized image. The browser will handle it so much faster.

[McJezuss]

Please remember to check Cloudflare DNS settings!

I use Cloudflare as my DNS manager but never disabled the proxy on the DNS records for Vercel. For some reason, this caused images to load insanely slow (I'm talking upwards of 10s on some images that were already pre-optimized with quality set to 60%).

However, when the proxy is disabled on the DNS records for Vercel, the images load nearly instantly, even after a full reload and on new devices.

I hope this helps someone out there.

[Prakash-Growmax]

where should i disable in the vercel

[stanislavyv]

Still very slow in 14.2.3. I tried both Image and getImageProps. App in ECS with sharp installed. I'm using priority for LCPs and also sizes where appropriate. quality on most images is set to 75 (default). width and height I get from the image metadata. Once loaded it works well, but after a fresh deployment some images take up to 20+ seconds to load.

[ramyNiranjan]

Hi
I have the same setup as you. Did you find an answer to it, or how is your image loading time now?

[ariunaamy]

Were you able to figure this out?

[duylddev]

same issue when images are store in AWS S3 (same region with backend),
image is 75kb but take 3seconds to "wait for backend response"
any solution?

[bluengreen]

If you are using the next/image component its calling a serverless function on every request. Skip the image component and just use a html img tag, and a cloudfront distribution. Try that.

[duylddev]

I'm using aws ec2, not vercel hosting
want to use image component for auto resize feature
but if next/image is not ready for production, I'll go back to the old way

[bluengreen]

I wouldn't say its not ready for production but its for optimization. Your image most likely doesn't need the optimization cause its so small. The extra server hit is unnecessary.

[duylddev]

oh, I got your point
my bad when using next/image, look likes it will make s3 cloudfront become useless (cause now it always hit our server, not cdn)
thanks a lot :D

[bluengreen]

Yeah thats the idea. However, next/image doesn't actually cache. I find s3 > cloudfront is faster. I also spun up imgproxy on aws lambda using this template. Gonna check that out so it will sit inbetween s3 > imgproxy > cloudfront.

https://imgproxy.net/blog/almost-free-image-processing-with-imgproxy-and-aws-lambda/

[BelalKhalifaKP]

Absolutely! The magic is in the aspect ratio of the Image. When you have an Image with a size of 200x300 and you don't set the aspect ratio to 2-3 in className or set width and height to 200 and 300 it will be slow. Really just resizing Images changes everything. If you wanna display the image in the size 150x250 and set the width and height to 150 and 250 but the image itself has another aspect ratio, you will have problems. Just resize the image to a ratio that fits 150-250. Let me know if this changed your life. Am Mi., 13. Nov. 2024 um 13:36 Uhr schrieb Ariunaa Myagmar < ***@***.***>:

…

Were you able to figure this out? — Reply to this email directly, view it on GitHub <#21294 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BC7XITKSZWIYREYSEJHC7TD2AMMSXAVCNFSM4WHTLOHKU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMJSGM3TONJR> . You are receiving this because you commented.Message ID: <vercel/next. ***@***.***>

[ariunaamy]

Hey, thanks! Adding the exact sizing to the class name helped a
bit, but the issue is is that the images in the database are managed by
someone else, and they upload various images with different ratios. We
currently have around 2,000 images in the database, so I’m considering
running a script in the background to resize them to a uniform aspect ratio.
And then I am sure it will get better. Or if you have better idea lmk

[BelalKhalifaKP]

Azure CDN was also a gamechanger for me. Can you check the image loading time. It’s important to know how long it gets requested from the db and how long it takes to be rendered afterwards. On Thu 14. Nov 2024 at 09:10, Ariunaa Myagmar ***@***.***> wrote:

…

Hey, thanks! Adding the exact sizing to the class name definitely helped a bit. I understand what you mean about using the actual aspect ratio of images. My challenge is that the images in the database are managed by someone else, and they upload various images with different ratios. We currently have around 2,000 images in the database, so I’m considering running a script in the background to resize them to a uniform aspect ratio. Let me know if you have other ideas. [image: Screenshot 2024-11-14 at 1.57.54 PM.png] On Wed, Nov 13, 2024 at 7:37 PM BelalKhalifaKP ***@***.***> wrote: > Absolutely! The magic is in the aspect ratio of the Image. When you have > an > Image with a size of 200x300 and you don't set the aspect ratio to 2-3 in > className or set width and height to 200 and 300 it will be slow. Really > just resizing Images changes everything. If you wanna display the image in > the size 150x250 and set the width and height to 150 and 250 but the image > itself has another aspect ratio, you will have problems. Just resize the > image to a ratio that fits 150-250. > > Let me know if this changed your life. > > Am Mi., 13. Nov. 2024 um 13:36 Uhr schrieb Ariunaa Myagmar < > ***@***.***>: > > > Were you able to figure this out? > > > > — > > Reply to this email directly, view it on GitHub > > < > #21294 (reply in thread)>, > > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/BC7XITKSZWIYREYSEJHC7TD2AMMSXAVCNFSM4WHTLOHKU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMJSGM3TONJR> > > > . > > You are receiving this because you commented.Message ID: <vercel/next. > > ***@***.***> > > > > — > Reply to this email directly, view it on GitHub > < #21294 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/A3OKHR73Y5OPEEGC7CXDR7L2AMTVDAVCNFSM4WHTLOHKU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMJSGM4DIMZV> > . > You are receiving this because you commented.Message ID: <vercel/next. > ***@***.***> > — Reply to this email directly, view it on GitHub <#21294 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BC7XITNB6MKU53Q6GVSYQB32AQWDNAVCNFSM4WHTLOHKU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMJSGQ4TINZR> . You are receiving this because you commented.Message ID: <vercel/next. ***@***.***>

[zr00da]

import MyImage from '@/public/images/image.webp'

<Image
  src={MyImage}
  width={1280}
/>

Imagine the surprise when I found out the above makes my static site always download a 1.5MB avif at 2x the source resolution marked as a slow request (runs a serverless function?) instead of the 200kb static webp I provided, with max-age=0 caching as a bonus...

I don't understand the defaults here - why is a srcset generated at all when I didn't provide it? Why does the component think I want a resample that's bigger than the source (that it knows the size of) which only magnifies the asset size without any improvement in quality since it's not an AI upscale? Why aren't these assets generated statically during SSG build? What's up with the magic behavior changes around the fill property that really just sets some CSS around object-fit? And the cache headers - is it not reasonable to trigger cache invalidation with a url param if a new build sees the asset actually change instead?

I can see the more useful usecases in the docs, but when the barebones functionality can set you up for a serious performance hit in what I'd call an elementary usecase then isn't it reasonable to say the component might be defaulting to too many magic assumptions about the platform and srcset generation specifically?

[dmythro]

This is so odd. Is it still reproducing?

[BitBeaver-182]

Not sure if everyone keep having this issue, but I had it and struggle a while with it.
I'm currently running in a standalone output on an EC2 instance (just to test things out).
My issues where that even when I had sharp installed it prompted me the message: Sharp Missing In Production even when I had it installed. and when running it images would load painfully slow. I did the following:
Run in your projects directory:

export NEXT_SHARP_PATH=$(pwd)/node_modules/sharp

Run a build

npm run build

copy the assets as recommended in the docs.

run your server.js

node .next/standalone/server.js

1st checkoint:
this should already not give you any errors in your console:

moving on..

moving files to the server.

here, whatever you're using it's okey. rsync is my prefer choice for this quick tests.

move the output folder into your server. this can be the command you run if you choose rsync:

rsync -avz --delete ./.next/standalone/   user@host:/path/to/your/folder

Once in the server you can either run it as is with the comand above or I prefer to use systemctl

[Unit]
Description=Your awesome project
After=network.target

[Service]
User=your-user
WorkingDirectory=/path/to/your/folder
# Ensure that the production environment is set and NEXT_SHARP_PATH is defined.
Environment="NODE_ENV=production"
Environment="NEXT_SHARP_PATH=/path/to/your/folder/node_modules/sharp"
# If you use nvm, load it (or set the PATH so node can be found)
# just type which node and it should give you the path to put bellow
ExecStart=/path/to/node server.js.  
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

save it as whatever server name you want .service inside the /etc/systemd/system path.
the run

sudo systemctl daemon-reload
sudo systemctl restart your-service-name.service
sudo systemctl status your-service-name.service

I hope this helps at least 1 person.

[mkanavakatini]

Just putting this here for visibility, I'm using pnpm and had to add this in my package.json

  "pnpm": {
    "onlyBuiltDependencies": [
      "sharp"
    ]
  }

[den-ii]

It's not about the server, it's as if nextjs Image renders late. I have found something that works for me though. I got a real low quality of my image, compressed it and converted it to base64 string, then I was able to use it like this:
It works great for me.

 <Image
            src={"/signup.png"}
            alt="creator"
            layout="fill"
            objectFit="cover"
            loading="eager"
            priority
            className="rounded-bl-2xl rounded-tl-2xl"
            blurDataURL={signupImgBlur}
            placeholder="blur"
          />

If you're rendering something like an icon it's best you use @svgr/webpack package for svg's