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 fixes a few things related to optional catch-all routes and i18n. The first thing is it ensures the correct data route is generated on the client so that the locale isn't duplicated for an optional catch-all route, the next is it ensures the browser history is updated correctly when only a locale change is occurring, and then it also ensures we handle the locales and normalizing for fallback optional catch-all pages correctly.
Tests have been added to ensure these cases are covered properly and we don't regress on them, these changes were also tested on Vercel [here](https://next-js-bug-i18n-root-params-nybg44l0b.vercel.app/)
Fixes: https://github.com/vercel/next.js/issues/18633
Fixes: https://github.com/vercel/next.js/issues/19059
This pull request completely replaces our old page loader with a brand new route loader.
Our existing comprehensive test suite means I did not need to add a bunch of tests. I did add them where behavior was added or fixed.
Summary of the changes:
- Eagerly evaluates prefetched pages in browser idle time (speeds up transitions)
- Router is **no longer frozen** indefinitely if the Build Manifest never arrives
- Router is **no longer frozen** indefinitely if a page fails to bootstrap
- New `withFuture` utility instead of ad-hoc deduping per resource
- Prefetching is now delayed until browser idle time to not impact TTI
- Browsers without `prefetch` now fall back to eager evaluation instead of using `preload`
- We're now ready to serve non-static assets **with `no-store` without breaking prefetching**
- **Application can now hydrate without fetching CSS assets—this is a huge performance win that was previously blocking hydration**
---
The minor size increase here is unfortunate, but we have to incur it for correctness.
---
Fixes#18389Fixes#18642
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
While we were fixing how Next.js handled CSS, we added a complex prefetch, preload, fetch sequence to acquire the CSS asset.
This unnecessarily overcomplicated what could've been only a `fetch()` from the very start!
---
Fixes#16932
This pull request speeds up Next.js' rendering pipeline by fetching data, parsing it, and loading it into memory instead of only doing the network request.
This will mainly result in improved Firefox/Safari performance since they handled prefetch incorrectly—only Chrome did it right. This also gets us closer to being able to use `no-store` in our caching headers!
---
Fixes#18639
x-ref #18802
This adds ncc inlining optimizations for the following dependencies:
* cacache
* schema-utils
* find-cache-dir
* mkdirp
* neo-async
* web-vitals
The slight increase in output in the reports here is due to the variation of the bundled version of web-vitals.
In addition, this moves ast-types to be a devDependencies entry instead of in dependencies as it was before https://github.com/vercel/next.js/pull/14746 as I could not see any production usage (ping @prateekbh). Happy to separate that out into a separate PR if preferred too.
This PR prints a pretty error when the Image `src` property is a [protocol-relative URL](https://www.paulirish.com/2010/the-protocol-relative-url/).
> Update 2014.12.17:
> Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.
Fixes#18536
Next.js would try to "recover" if its CSS assets went missing (i.e. a deployment occured) **while the page was initially loading**.
This handled a rare case where we'd try to let the Next.js complete hydrating even though a deployment occured.
However, in practice, this never worked: if the `fetch()` failed, that means the original assets never downloaded themselves (because the `fetch()` should be coming from disk cache).
Instead of letting Next.js get itself into a weird state, let's just stop hydration so that the page doesn't accidentally delete its styles.
The handle-no-styles behavior is already tested in `test/integration/css/test/index.test.js`. There was never a branch for it using its cached styles, so nothing else needs updated.
---
Fixes#17930
When visiting a non-locale prefixed path (`/hello` instead of `/fr/hello`) we don't trigger locale redirects currently so if another locale is matched we need to ensure this is reset to the `defaultLocale` for rendering to prevent a mis-match on the client and the server.
This also fixes hydration errors from occurring with `asPath` for `getServerSideProps` pages due to `normalizeLocalePath` expecting only a pathname and `asPath` containing `hash` and `query values also.
Fixes: https://github.com/vercel/next.js/issues/18337
Fixes: https://github.com/vercel/next.js/issues/18510
This PR deprecates the `unsized` property from NextImage because the property did not accomplish the desired effect.
Users should rely on one of the new layouts instead:
- `<Image layout="fixed" />`
- `<Image layout="intrinsic" />`
- `<Image layout="responsive" />`
- `<Image layout="fill" />`
The `unsized` property will continue to work as-is in production but is deprecated and will throw in dev.
---
### TODO:
- [x] test `layout=fill` in typescript types
- [x] test `layout=fill` render behavior
- [x] test that `unsized` switches to `layout=fill`
- [x] test `next dev` erroring on `unsized`
- [ ] layout docs (tracked in issue #18554)
- [ ] both `layout=fill` and `layout=responsive` use all deviceWidths in the srcset
---
Fixes#18541
Co-authored-by: Steven <steven@ceriously.com>
This PR introduces a new `layout` property.
This allows 3 possible values (`fixed`, `intrinsic`, or `responsive`) which solve many use cases we have seen since 10.0.0 and will hopefully avoid usage of `unsized`.
Fixes#18351
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Add err.sh for missing images domain
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
* Update test
Co-authored-by: Steven <steven@ceriously.com>
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
For many users refactoring from `<img>` to `<Image>`, we can often support their properties as-is.
The exception was width/height.
This PR allows the `<Image>` component to accept strings for `width` and `height` just like `<img>`.
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
