Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creates unnecessary duplicate images #962

Open
zatakiya opened this issue Jul 17, 2024 · 4 comments
Open

Creates unnecessary duplicate images #962

zatakiya opened this issue Jul 17, 2024 · 4 comments

Comments

@zatakiya
Copy link

Package creates images in all sizes, even though input(original) image is of smaller size.

For example, consider an image of 800px width. Ideally, the package should ignore creating of larger size images than this but it generates images for all sizes defined in next.config.js

This behavior creates images that are identical with different names.

@dc7290
Copy link
Owner

dc7290 commented Jul 17, 2024

This is a specification.

Next.js build → Due to the image optimization process and proceed, I don't know how many pixels the image is.

Therefore, I try to generate an image according to the next.config setting so that there is no problem with any image requested.

What image size is requested can be controlled by the sizes and width properties of next/image, so there is virtually no problem.

@zackBRAVE
Copy link

This is a specification.

Next.js build → Due to the image optimization process and proceed, I don't know how many pixels the image is.

Therefore, I try to generate an image according to the next.config setting so that there is no problem with any image requested.

What image size is requested can be controlled by the sizes and width properties of next/image, so there is virtually no problem.

You are right, with sizes and width properties, it won't be a problem when customer visit the site.
However in our use case there are many photos, and we upload them to CDN, which can take up some space and extend the uploading time.

I used next-image-export-optimizer before, it has a logic as below:
// only use the width if it is smaller or equal to the next size in the allSizes array
https://github.com/Niels-IO/next-image-export-optimizer/blob/e8efeb45b873908a1393722e7042a0622e4a5f74/example/src/ExportedImage.tsx#L175

As you mentioned you don't know how many pixels the image is, I think this might help?
const originalImageWidth = (isStaticImage && src.width) || undefined;

Thx, best regards, an amazing library.

@Javierieh
Copy link

Thanks for developing this plugin is really useful!

I was thinking maybe we could add a step prior to processing each image where we read the exif metadata and see the image dimensions. This shouldn't delay the process too much, in fact it could increase the overall speed by not having to process uncessary copies.

If you're taking pull requests I can take a look into this. I've used https://www.npmjs.com/package/exifreader in the past and its fast.

@Javierieh
Copy link

Actually, we should also take into consideration the sizes prop on the images because depending on its usage there are sizes that will never be needed.

https://nextjs.org/docs/app/api-reference/components/image#sizes

"Second, the sizes property changes the behavior of the automatically generated srcset value. If no sizes value is present, a small srcset is generated, suitable for a fixed-size image (1x/2x/etc). If sizes is defined, a large srcset is generated, suitable for a responsive image (640w/750w/etc). If the sizes property includes sizes such as 50vw, which represent a percentage of the viewport width, then the srcset is trimmed to not include any values which are too small to ever be necessary."

So having by image width, combined with the sizes property (and the sizes defined in https://nextjs.org/docs/app/api-reference/components/image#devicesizes), we can trim the srcset to only include the images needed.

I believe this is how nuxt.js does it by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants