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

Docs: Indicate High memory usage if not installing sharp for image optimization #41417

Closed
gaplo917 opened this issue Oct 14, 2022 · 5 comments · Fixed by #61696 or #63321
Closed

Docs: Indicate High memory usage if not installing sharp for image optimization #41417

gaplo917 opened this issue Oct 14, 2022 · 5 comments · Fixed by #61696 or #63321
Labels
Documentation Related to Next.js' official documentation. locked

Comments

@gaplo917
Copy link

gaplo917 commented Oct 14, 2022

What is the improvement or update you wish to see?

Introduction

Remote image sizes are difficult to guarantee when some users uploaded very large images on the CMS. The very large images will be retrieved by nextjs and served to the frontend.

The default library squoosh will cause the nextjs process a very high memory usage during image optimizations and might crash the whole nextjs container in a limited resource environment.

Thus, the high memory behaviour should be docuementated to increase the necessarity of installing sharp.

Note: Some of our team members can't see observable differences after installing sharp and then remove it immediately.

Suggestion

Indicate high memory usage of squoosh compared with sharp. For example, a single 5000 x 5000 images would consume ~600MB memory while sharp use less than few MB memory only.

Is there any context that might help us understand?

Demo Recording

Without installing Sharp

Three 5000x5000 images will cause 1.8GB memory usage, and the memory jump is linear.
next-high-mem

Installed Sharp

The memory usage remains stable.
next-sharp-installed-no-high-mem

Does the docs page already exist? Please link to it.

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

@gaplo917 gaplo917 added the Documentation Related to Next.js' official documentation. label Oct 14, 2022
gaplo917 added a commit to gaplo917/nextjs-lottie-webworker-sample that referenced this issue Oct 14, 2022
@karlhorky
Copy link
Contributor

Wonder if this issue can be replaced by a PR to switch back to sharp, now that @squoosh/cli and @squoosh/lib are unmaintained:

Project no longer maintained

Unfortunately, due to a few people leaving the team, and staffing issues resulting from the current economic climate (ugh), this package is no longer actively maintained. I know that sucks, but there simply isn't the time & people to work on this. If anyone from the community wants to fork it, you have my blessing. The squoosh.app will continue to be supported and improved.

Screenshot 2023-03-31 at 14 42 39

@karlhorky
Copy link
Contributor

karlhorky commented Mar 31, 2023

@styfle is there already an issue / PR about switching from squoosh back to sharp somewhere?

Eg. A) reverting @Timer's PR below and B) reverting all followup PRs adding back optional sharp support and C) making sharp again a required dependency of Next.js:

M1 support (the original reason for switching to squoosh) has been in sharp for a long time now, and there is an initiative to also get WebAssembly support:

@styfle
Copy link
Member

styfle commented Apr 11, 2023

There's no issue tracking it in Next.js because lovell/sharp#3522 hasn't landed yet.

Once it lands then we can look into removing squoosh as the wasm implementation in favor of sharp.

For now, the linked docs in the original post explain the current status.

@karlhorky
Copy link
Contributor

Looks like [email protected] now includes (experimental) WebAssembly support 🙌

styfle added a commit that referenced this issue Feb 6, 2024
…ep (#61696)

## History

Previously, we added support for `squoosh` because it was a wasm
implementation that "just worked" on all platforms when running `next
dev` for the first time. However, it was slow so we always recommended
manually installing `sharp` for production use cases running `next
build` and `next start`.

Now that [`sharp` supports
webassembly](https://sharp.pixelplumbing.com/install#webassembly), we no
longer need to maintain `squoosh`, so it can be removed. We also don't
need to make the user install sharp manually because it can be installed
under `optionalDependencies`. I left it optional in case there was some
platform that still needed to manually install the wasm variant with
`npm install --cpu=wasm32 sharp` such as codesandbox/stackblitz (I don't
believe sharp has any fallback built in yet).

Since we can guarantee `sharp`, we can also remove `get-orientation` dep
and upgrade `image-size` dep.

I also moved an [existing `sharp`
test](#56674) into its own fixture
since it was unrelated to image optimization.

## Related Issues
- Fixes #41417
- Closes #54670
- Related #54708
- Related #44804
- Related #48820
Copy link
Contributor

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 21, 2024
styfle added a commit that referenced this issue Apr 25, 2024
…ependency (#63321)

## History

Previously, we added support for `squoosh` because it was a wasm
implementation that "just worked" on all platforms when running `next
dev` for the first time. However, it was slow so we always recommended
manually installing `sharp` for production use cases running `next
build` and `next start`.

Now that [`sharp` supports
webassembly](https://sharp.pixelplumbing.com/install#webassembly), we no
longer need to maintain `squoosh`, so it can be removed. We also don't
need to make the user install sharp manually because it can be installed
under `optionalDependencies`. I left it optional in case there was some
platform that still needed to manually install the wasm variant with
`npm install --cpu=wasm32 sharp` such as codesandbox/stackblitz (I don't
believe sharp has any fallback built in yet).

Since we can guarantee `sharp`, we can also remove `get-orientation` dep
and upgrade `image-size` dep.

I also moved an [existing `sharp`
test](#56674) into its own fixture
since it was unrelated to image optimization.

## Related Issues
- Fixes #41417
- Related #54670
- Related #54708
- Related #44804
- Related #48820
- Related #61810
- Related #61696
- Related #44685
- Closes #64362

## Breaking Change

This is a breaking change because newer versions of `sharp` no longer
support `yarn@1`.

- lovell/sharp#3750

The workaround is to install with `yarn --ignore-engines` flag.

Also note that Vercel no longer defaults to yarn when no lockfile is
found

- vercel/vercel#11131
- vercel/vercel#11242

Closes NEXT-2823
ForsakenHarmony pushed a commit that referenced this issue Aug 16, 2024
…ependency (#63321)

## History

Previously, we added support for `squoosh` because it was a wasm
implementation that "just worked" on all platforms when running `next
dev` for the first time. However, it was slow so we always recommended
manually installing `sharp` for production use cases running `next
build` and `next start`.

Now that [`sharp` supports
webassembly](https://sharp.pixelplumbing.com/install#webassembly), we no
longer need to maintain `squoosh`, so it can be removed. We also don't
need to make the user install sharp manually because it can be installed
under `optionalDependencies`. I left it optional in case there was some
platform that still needed to manually install the wasm variant with
`npm install --cpu=wasm32 sharp` such as codesandbox/stackblitz (I don't
believe sharp has any fallback built in yet).

Since we can guarantee `sharp`, we can also remove `get-orientation` dep
and upgrade `image-size` dep.

I also moved an [existing `sharp`
test](#56674) into its own fixture
since it was unrelated to image optimization.

## Related Issues
- Fixes #41417
- Related #54670
- Related #54708
- Related #44804
- Related #48820
- Related #61810
- Related #61696
- Related #44685
- Closes #64362

## Breaking Change

This is a breaking change because newer versions of `sharp` no longer
support `yarn@1`.

- lovell/sharp#3750

The workaround is to install with `yarn --ignore-engines` flag.

Also note that Vercel no longer defaults to yarn when no lockfile is
found

- vercel/vercel#11131
- vercel/vercel#11242

Closes NEXT-2823
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation Related to Next.js' official documentation. locked
Projects
None yet
3 participants