[Canary] Performance issues optimizing the images

[Nick-Mazuk]

I'm experiencing some similar performance issues as mentioned in https://github.com/cyrilwanner/next-optimized-images/issues/169 but with the most current build.

I have gotten the same error occasionally, but more often, images will just take forever to build during development. Small images are near-instant, though anything above 500x500 pixels seems to take a few minutes for each image. I even just clocked a single image taking 12 minutes to process.

Any ideas about what could be causing the slow optimization times?

Just to rule out a few possibilities:

• I am not using dynamic routes
• I'm still experiencing slow builds with one image, one size, and no webp (so 1 output image)
• I'm not using any custom configuration of the plugin
• The cache is working fine, so only the initial optimization is affected
• I'm using 3.0.0-canary.10

If the slow build times are unavoidable, here are a few suggestions to help for development:

1. Make it so optimizing images doesn't block the website render
2. While images are optimizing, display a default "image is still optimizing" image
3. When the image finishes optimizing, replace the temp image with the actual image

I literally have no idea how feasible this would be, so if it's not possible, no worries! And of course, this would only be for development.

Thanks for everything!

[nelsonreitz]

Can confirm, I'm hitting netlify timeout build time (25min) with just a few images on 3.0.0-canary.10.

[Nick-Mazuk]

For anyone reading this thread now, I ended up switching to the new next/image component in NextJS 10.0.0 https://nextjs.org/docs/api-reference/next/image

Been using it for about a week and it's working wonderfully.

[TheThirdRace]

NextJs solution is far from perfect and has plenty of troubles:

• Caching is forcing network request to check Etag, you can't override this behavior
• Optimization is done on the fly, which means it's a delay you wouldn't get at build time
• The image styling used is highly restrictive, inefficient and forces the use of !important to overwrite
• Most uses of Next/Image component results in 3 to 4 DOM nodes per image, which bloat the DOM if using multiple images
• The wrappers are divs, so if you use in a p tag, you're semantically incorrect
• You can't use a decent/secure Content-Security-Policy header

We do need an alternative because NextJs solution isn't rosy as soon as you dig a little deeper.