Finally 🚀.

Can’t wait to get that 100 lighthouse performance scores once again 😋

yay

Wow, this is fantastic!!!

Would it also allow overriding the image format with a query parameter? There will be scenarios where I’d want to explicitly specify a format — for example, using PNGs when the image has more lines and using JPGs when the image is more photo-realistic. Of course AVIF does both of these kinds really well, but while we wait for more widespread browser support, the ability to specify the image format would be nice.

Provide every possible transformation — The goal of this RFC is to provide the minimal transformations needed

I assume ^this non-goal also covers generating image placeholders? (blurred images, used colours, etc.)

#16832 also doesn't include the use of placeholders so it looks like it isn't a goal for either RFC, but they are one of the best features of next-optimized-images and gastby-image from a UX perspective (I did see the comment about perf issues in #16832, but haven't seen any benchmarks and would like to understand that point more)

Is there any consideration for signing image URLs like Thumbor to prevent URL tampering? Even though you can configure the allowed image domains, this proposal would leave the image endpoint open to denial of service attacks.

From the Thumbor documentation:

Now let’s say that some malicious user wants to overload your service. [They] can easily ask for other sizes in loops or worse, like:

http://some.server.com/unsafe/300x301/smart/path/to/image.jpg
http://some.server.com/unsafe/300x302/smart/path/to/image.jpg
http://some.server.com/unsafe/300x303/smart/path/to/image.jpg

Other than that, the user can ask for images that do not exist, thus forcing us to perform useless http GET operations or filesystem operations.

Does this mean that for the first time a request is made an image is generated, and then every subsequent requests will serve the created image? Is it basically a smart image cdn? I guess it will be cleaned between builds though?

I'd like to propose a few things to consider adding into this RFC which would be very useful.

• Option to use signed urls for external images instead of white list domains. It would also protect the arguments for hijacking the sizes, quality and so on.
• Possibility to select crop method and positioning (center, top, left, right, bottom, etc)

We wrote a similar solution using vips/sharp (not maintained at the moment) to be able to replace our SaaS for image optimization and manipulation, it explains a bit more what I ment by signed urls and more params to control the image - in case that would be helpful :-)

https://github.com/barnebys/bimp

How would this work for generated static sites?

Non-Goals

• ...
• Support for next export — The goals of the RFC and it's particular characteristics of on-demand optimizing over optimizing at build time which causes build time slowdowns

I think optimizing at build time its valid in a lot of use cases and it does not require to have serverless support to handle the requests, I do agree that it should have some sort way to only transform images once and skip for subsequent builds.

Maybe add a new RFC for this? It is one of the most used features in some frameworks.

This is a great RFC, I am doing so already with Sharp, Vercel and NextJS. It works well, and Vercel gives good Cache Control.

1. Are there any considerations for the user controlling the http cache headers for the images returned by _next/image?

Some truly unique remote URLs will probably not change and can be cached after they are resized. Others like /_next/image/?logo.webp may need to be expired.

Deploys cannot be relied upon to clear the cache either as this is online image processing.

2. Some S3 best practices are no public access by default and for CORS policies for websites fetching assets from S3 or through Cloudfront CDN.

Since this is server side fetching credentials would be required for the server to access non public assets. This prevents DDoS and therefore requires no next support for masked URLs.

This may mean a user must supply a function that can fetch the image, it is not available over HTTP, or is only available securely over HTTP with environment variables. Would this be supported?

Thanks 👍

What would be the HTML output of such component and how would responsive imagery be achieved? Sometimes you want to serve images of with 500 width on medium screens, but only 300 on larger screens because of tiling or something. This is of course achieved through the sizes attribute on the img tag. I very much like the idea of query parameters. You can add a sizes s query that adds media queries.

What about DDOS? For example somebody makes thousands request with random query on _next/image?url=/logo.png&w=100&h=100&q=70

I wonder if image optimization is going to support rewrites? This could be helpful for adaptation and incrementally adopting Next.js.

The dream come true in v10.
I just came here to say thank you for being the best react framework ever ❤️

Would love to see alternative storage options. Right now I'm assuming images get stored on disk, but with a large enough quantity of images we might eat up all the available storage on whatever server we are using. It also means we will be discarding these image caches if using Blue/Green deployments.

If we could select an S3 bucket, for example, to store images we could mitigate this storage problem

Is Fallback optimize image to original format available at the moment?