Is it expected that `mozjpeg: true` uses significantly more cpu?
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 32.7k
- Forks
- 1.4k
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 5
Description
Question about an existing feature
Is it expected that setting mozjpeg: true and processing jpeg as both input and output uses significantly more cpu than the default?
What are you trying to achieve?
Trying to find a good default for Next.js users. I noticed really high CPU for JPEG input and output.
In a previous PR, @lovell set mozjpeg to always be true here:
When you searched for similar issues, what did you find that might be related?
https://github.com/lovell/sharp/issues?q=is%3Aissue%20state%3Aclosed%20mozjpeg
Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this question
TODO
Please provide sample image(s) that help explain this question
2,149 JPEGs tested with MozJPEG on and off at quality 75 with concurrency of 8 on MacBook M3 Pro.
CPU averages use each image’s median of three runs on an M3 Pro, including decode/rotate/resize/encode. Ratios average each image’s input KB ÷ output KB; higher means greater size reduction. Smaller images weren’t enlarged.
| Requested width | Average CPU (ms) | CPU saved | Average output KB | Average input/output ratio |
|---|---|---|---|---|
| 3840 | 31.67 → 8.80 | 72.2% | 39.57 → 51.81 | 4.13 → 3.81 |
| 1920 | 20.96 → 7.72 | 63.2% | 25.90 → 33.52 | 4.51 → 4.09 |
| 1080 | 14.48 → 5.76 | 60.2% | 17.71 → 22.71 | 5.62 → 4.93 |
| 640 | 11.01 → 5.02 | 54.4% | 12.76 → 16.31 | 8.31 → 7.09 |
Disabling MozJPEG saved 54–72% CPU, with average outputs 28–31% larger.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue does not name a source file, test, or entry point, and the standalone reproduction is still TODO. Start by reproducing the reported JPEG benchmark with mozjpeg enabled and disabled, then identify where sharp delegates JPEG encoding. Done would require a maintainer-confirmed explanation of the CPU/size tradeoff or a clearly scoped change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100