Adds tests to the Image component to verify that the correct data is being exposed.
Based on #27899 and #28312
## Bug
- [ ] 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
This PR adds `lazyBoundary` prop on Image Component.
This feature is to load the images earlier.
I'm not good at English. So, I couldn't explain enough in the documentation what `lazyBoundary` is.
Feature request: https://github.com/vercel/next.js/discussions/24552
## Feature
- [x] 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`
- [x] Integration tests added
- [x] 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
- [x] Make sure the linting passes
fixes#19074
This change disables image lazy-loading when both of the following are true:
1) A image is being rendered following a client-side page transition
2) The image has been previously loaded during this session.
Before this change, all images with lazy-loading enabled have a visible flicker during client-side page transitions, even though they're already loaded.
With this change, there's are two performance risks:
1) There's a chance that some offscreen images will have lazy-loading disabled unnecessarily because they were previously loaded. I think the performance hit here is pretty negligible and the situation is unlikely to come up very often.
2) There's a chance a different-sized version of the image will be selected by the browser, but lazy-loading will be disabled anyway. This seems even more unlikely to me, and anyway the performance hit from a stray un-lazy-loaded image (on a client-side transition) is very minor.
In both cases, I think the performance risk is outweighed by the UX improvement of getting rid of the image flicker on page transition.
If the `Image` src url had existing query params, the imgix loader would simply append another query string with `?` causing both query strings to break.
This PR adds a way to safely merge query strings if needed using [URLSearchParams](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams).
## Bug
- [X] fixes#26288
- [X] Integration tests added
Currently if you have `sizes` set in `next/image`, the image will likely be downloaded multiple times (usually twice) on Safari (macOS and iOS): the correct size for the viewport, and the original size specified in `src`.
Also make sure you have "Ignore Resource Cache" disabled in the Safari Devtools when trying to reproduce:
The root cause is the way Safari handles `<img>`'s attribute updates. Although React updates all the attributes one by one synchronously and programmatically, Safari will still try to fetch the resource immediately and won't wait for other DOM changes to be finished.
That means if we set the following 3 attributes in this order: `src`, `srcSet`, `sizes`. Safari will fetch the image when `src` is set. And then once `srcSet` is there it will fetch the resource again based on it. And finally, when `sizes` is updated it might correct the resource URL again.
So the fix here is simple: by just reordering those to `sizes`, `srcSet`, `src`, it will only load the image with the correct size only once:
<img width="1498" alt="CleanShot 2021-03-09 at 21 05 30@2x" src="https://user-images.githubusercontent.com/3676859/110477852-a27c7700-811e-11eb-88dc-d6e7895f67bd.png">
Fixes#19478.
Fixes#18720
This removes image preloading. It doesn't work correctly on any browser other than Chrome (with Chrome's real engine). On all other browsers, it triggers 2x the bytes to be downloaded. The tradeoff isn't worth it here IMO.
Chrome itself should be smart enough to bump an `<img />` tag's priority over other preloads that are script type during the preparse phase.
We can reintroduce this when we don't hurt non-Chrome users.
This PR fixes two bugs causing HTML validators to complain.
- Error: Bad value data:image/svg+xml;charset=utf-8, for attribute src on element img: Illegal character in scheme data: < is not allowed.
- Fixed by using base64 for svg during `layout=intrinsic` to avoid angle brackets
- Error: Element img is missing required attribute src.
- Fixed by using base64 transparent gif for `loading=lazy` placeholder
Fixes#18850
This pull request fixes `<Image />` not updating when new props are passed by removing external DOM mutations and relying on React to do it instead.
As an added bonus, I've extracted the intersection observer from both the `<Image />` and `<Link />` component, as their instance can be shared!
The increase in size is minor (+3B), and actually a decrease for apps using both `<Image />` and `<Link />`.
---
Fixes#18698Fixes#18369
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
There was a bug when the user defines a width on the Image component, but a larger size image is requested.
This is because the browser uses the `srcset` to decide which image size to request and we had the srcset basically hardcoded.
This PR fixes the behavior so that the `srcset` will never be larger than the `width` defined on the component.
It also fixes a bug where the preload srcset did not match the img srcset.
- Related to #18147
- Related to #18122
This PR updates the `<Image>` component to follow the same property naming as native `<img>`.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-loading
This currently allows two values,`loading=lazy` and `loading=eager`, but there might be new values added in a future spec.
cc @atcastle
