Generally, AVIF quality can be lower compared to WebP so we can adjust this for the user so that it looks roughly the same depending on if the browser supports AVIF or WebP.
- Fixes#31254
- Related to https://github.com/lovell/sharp/issues/2850
This will ensure an image hashed consistently regardless of how its imported:
- `import file from "./file.png"` -> /_next/static/media/file.12345678.png
- `url(./file.png)` -> /_next/static/media/file.12345678.png
- `new URL("./file.png", import.meta.url)` -> /_next/static/media/file.12345678.png
* Move unit tests to one folder
* Migrate unit tests to TypeScript
* add test types to lint
* Ensure ts(x) tests are run with util
* Add tsx extension to jest config
* bump
fixes#27210
maybe related: #19668
currently, the image optimizer returns 400 when an image url contains non-ascii characters. this pr uri-encodes the `url` query parameter to fix it. also see https://github.com/vercel/next.js/issues/27210#issuecomment-890305204
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
In this PR I've added the `Content-Disposition` header to the response of the image `/_next/image` route. That header is used by the browser when showing the dialog for the `Save image as...` action.
There are some differences between the browsers, ex:
When requesting the image `test.jpg`, the response header `Content-Type: image/webp` - in FF the filename from the `Save image as...` dialog would be `test.webp` but in Chrome `test.jpg` even if the `Content-Disposition: inline; filename="test.webp"` is present in the headers. The same about png images, the rest types are fine. It looks like FF is checking the `Content-Type` for the extension but the Chrome does not and is doing another type of check.
Fixes#26737
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes
* Use sharp for image transformations when available
* Refactor resizeImage and add sharp warning
* only show sharp warning once per instance
* Modify sharp error message
* Add documentation for optional sharp dependency
* Update docs/basic-features/image-optimization.md
Co-authored-by: Steven <steven@ceriously.com>
* Import types for sharp
* Update lockfile
* Add testing against sharp
* use fs-extra for node 12
* Rename test sharp path variable
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
* update squoosh specific test
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
* update tests
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
In a previous PR (#27200), we added `minimumCacheTTL` to configure the time-to-live for the cached image. However, this was setting the `max-age` header.
This PR ensures that `minimumCacheTTL` doesn't affect browser caching, only the upstream header can affect browser caching.
This is a bit safer in case the developer accidentally caches something that shouldn't be and the cache needs to be invalidated. Simply delete the `.next/cache/images` directory.
- Related to #19914
- Related to #22319
- Closes#23328
- Related to #19914
- Related to #22319
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`
This PR changes the implementation of `placeholder=blur` when using `next dev` so that it lazy loads on-demand.
This will improve the developer experience for web apps with many blurred images.
Since we are no longer accepting new built-in loaders, users may wish to use a different cloud provider.
So this PR renames `dangerously-unoptimized` to `custom` to handle this case as well as the intention of `next export`.
If the user doesn't add a `loader` prop, we throw an error.
If the user adds a `loader` prop but it doesn't return the width, we print a warning.
- Follow up to #26847
- Fixes#21079
- Fixes#19612
- Related to #26850
This pull request adds "Vary: Accept" header to responses from the image optimizer (i.e. the /_next/image endpoint).
The image optimizer prefers re-encoding JPG files to WebP, but some browsers (such as Safari 14 on Catalina) do not yet support WebP. In such cases the optimizer uses the Accept header sent by the browser to send out a JPG response. Thus the optimizer's response may depend on the Accept header.
Potential caching proxies can be informed of this fact by adding "Vary: Accept" to the response headers. Otherwise WebP data may be served to browsers that do not support it, for example in the following scenario:
* A browser that supports WebP requests the JPG. The optimizer re-encodes it to WebP. The proxy caches the WebP data.
* After this another browser that doesn't support WebP requests the JPG. The proxy sends the WebP data to the browser.
- [x] Integration tests added
- [x] Make sure the linting passes
This solves the main use case from Issue #19914.
Previously, we would set the `Cache-Control` header to a constant and rely on the server cache. This would mean the browser would always request the image and the server could response with 304 Not Modified to omit the response body.
This PR changes the behavior such that the `max-age` will propagate from the upstream server to the Next.js Image Optimization Server and allow browser caching. ("upstream" meaning external server or just an internal route to an image)
This PR does not change the `max-age` for static imports which will remain `public, max-age=315360000, immutable`.
#### Pros:
- Fewer HTTP requests after initial browser visit
- User configurable `max-age` via the upstream image `Cache-Control` header
#### Cons:
- ~~Might be annoying for `next dev` when modifying a source image~~ (solved: use `max-age=0` for dev)
- Might cause browser to cache longer than expected (up to 2x longer than the server cache if requested in the last second before expiration)
## Bug
- [x] Related issues linked using `fixes #number`
Previously we were accepting a `s=1` query string parameter for static imports, but this is not necessary.
Instead, this PR looks at the file path to determine if the header should be `immutable`.
The nice thing here is we don't need to worry about someone trying `s=1` with an external image or 3rd party loader. In that case, we use the upstream `Cache-Control` header as usual.
This change also ensures we don't add the `immutable` header for `next dev`.
Related to PR #24993
This PR adds the deduplication logic to image optimizer so the cache will be reused as much as possible if there're multiple concurrent requests.
Fixes#23436.
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
This PR updates the Squoosh PNG decoder, which fixes#22929 in GoogleChromeLabs/squoosh#971.
## Bug
- [x] Fixes#22929
- [x] Integration tests added
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
If the upstream MIME type isn't prefixed with `image/`, the endpoint should directly response with a 400 error.
## Bug
- [x] Fixes#23312
- [x] Integration tests added
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
This pull request removes the native `sharp` dependency (which doesn't work on some Linux variants, nor **M1 Mac**) and replaces it with a wasm equivalent.
It also reduces Next.js' installed size by 27.3 MB.
The code is adapted from the [Squoosh CLI](https://github.com/GoogleChromeLabs/squoosh).
This PR still supports:
- Rotation normalization
- Resizing
- PNG
- JPEG
- Webp
However, it (temporarily) removes support for:
- Resizing Gifs
- Resizing Tiff
(these formats still get served and rendered correctly by the image component)
---
Fixes#20456Closes#20738Closes#21762
Fixes: https://github.com/vercel/next.js/issues/19100
> According to https://nextjs.org/docs/basic-features/image-optimization#caching Next.js populates a cache dir when using the new <Image /> component. This is not the case when using SVG files. This results in a performance penalty.
I created a function for writing images to cache directory (`wrirteToCacheDir`) and it is called for all images.
However, vector and animated images are not optimized before writing them to cache dir
Related to #18179
We fixed this in a previous PR but there were no tests for `.ico` so this PR adds a test for it to ensure we don't regress.
Similar to SVG, we bypass ICO because it typically contains multiple sizes in a single file.
Closes#18600
Fixes#18563 by adding the etag header to the optimized image response.
This does _not_ change the expireAt (TTL) for cached files on the server, which still uses the max-age of the upstream response.
The new file format on disk for cached image files is the following:
```
.next/cache/images/<HASHED_QUERYSTRING>/<EXPIREAT>.<ETAG>.<EXT>
```
Older versions of Safari (and other browsers) do not support webp format so we were incorrectly falling back to png.
This PR fixes#18509 so that we fallback to the original image format if a modern format like webp was not explicitly provided in the Accept header.
Tests were added to ensure that the Accept header for Safari, Firefox, and Chrome work properly.
This does two things:
- Rename `iconSizes` to `imageSizes`.
- Give priority to `imageSizes` regardless of `deviceSizes` as a means to opt-out of the srcset behavior.
This separates the `next.config.js` property `images.sizes` into to properties: `images.deviceSizes` and `images.iconSizes`.
The purpose is for images that are not intended to take up the majority of the viewport.
Related to #18122
This adds checks to ensure that less than 50 domain and size items are configured and no sizes are less than 0 or greater than 10,000
x-ref: https://github.com/vercel/next.js/issues/18122
Co-authored-by: Steven <steven@ceriously.com>
We currently always accept requests to the new `/_next/image` endpoint, even when it should not be used.
Instead, we should check to see if the default loader is used as a signal to enable this API.
Other loaders (such as cloudinary) will not go through the Next.js API so there is no need to expose this, instead we 404.
- Analogous to https://github.com/vercel/vercel/pull/5321
- Related to #18122
Previously, vector images like svg were being converted to webp and resized.
However, vector images already handle any size so we can bypass the same we do for animated images.
Related to #18122
The `w` parameter in the Image Optimization API is the requested size of the image and should only be resized if the source image is larger than the requested size. This PR fixes the behavior to prevent accidental upscaling, for example icon images.
This updates the new image optimizer endpoint to instead of relying on the `host` and `proto` headers for relative files to use the internal route handling in `next-server` to load files from the public directory. The existing tests for relative files with the endpoint should cover these changes
This makes sure the image optimizer doesn't de-animate images by transforming them with sharp since sharp doesn't currently handle outputting animated images
x-ref: https://github.com/vercel/next.js/pull/17749
