-
Notifications
You must be signed in to change notification settings - Fork 27k
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
Don't lazy-load already-loaded image in client-side transition #26968
Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Will this also fix #20178? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Failing test suitesCommit: eb681c5 test/integration/image-component/basic/test/index.test.js
Expand output● Image Component Tests › SSR Lazy Loading Tests › should have loaded the first image immediately
● Image Component Tests › SSR Lazy Loading Tests › should load the second image after scrolling down
● Image Component Tests › SSR Lazy Loading Tests › should load the third image, which is unoptimized, after scrolling further down
● Image Component Tests › SSR Lazy Loading Tests › should load the fourth image lazily after scrolling down
● Image Component Tests › SSR Lazy Loading Tests › should load the fifth image eagerly, without scrolling
● Image Component Tests › Client-side Lazy Loading Tests › should have loaded the first image immediately
● Image Component Tests › Client-side Lazy Loading Tests › should not have loaded the second image immediately
● Image Component Tests › Client-side Lazy Loading Tests › should load the second image after scrolling down
● Image Component Tests › Client-side Lazy Loading Tests › should load the third image, which is unoptimized, after scrolling further down
● Image Component Tests › Client-side Lazy Loading Tests › should load the fourth image lazily after scrolling down
● Image Component Tests › Client-side Lazy Loading Tests › should load the fifth image eagerly, without scrolling
|
This comment has been minimized.
This comment has been minimized.
Stats from current PRDefault Build (Increase detected
|
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
buildDuration | 12.3s | 12.4s | |
buildDurationCached | 3s | 2.9s | -96ms |
nodeModulesSize | 49.3 MB | 49.3 MB |
Page Load Tests Overall increase ✓
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
/ failed reqs | 0 | 0 | ✓ |
/ total time (seconds) | 2.041 | 2.043 | 0 |
/ avg req/sec | 1224.95 | 1223.56 | |
/error-in-render failed reqs | 0 | 0 | ✓ |
/error-in-render total time (seconds) | 1.134 | 1.1 | -0.03 |
/error-in-render avg req/sec | 2203.64 | 2272.84 | +69.2 |
Client Bundles (main, webpack, commons)
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
359.HASH.js gzip | 3.09 kB | 3.09 kB | ✓ |
framework-HASH.js gzip | 42 kB | 42 kB | ✓ |
main-HASH.js gzip | 20.6 kB | 20.6 kB | ✓ |
webpack-HASH.js gzip | 1.49 kB | 1.49 kB | ✓ |
Overall change | 67.2 kB | 67.2 kB | ✓ |
Legacy Client Bundles (polyfills)
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
polyfills-HASH.js gzip | 31.1 kB | 31.1 kB | ✓ |
Overall change | 31.1 kB | 31.1 kB | ✓ |
Client Pages Overall increase ⚠️
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
_app-HASH.js gzip | 803 B | 803 B | ✓ |
_error-HASH.js gzip | 3.18 kB | 3.18 kB | ✓ |
amp-HASH.js gzip | 526 B | 526 B | ✓ |
css-HASH.js gzip | 329 B | 329 B | ✓ |
hooks-HASH.js gzip | 903 B | 903 B | ✓ |
image-HASH.js gzip | 5.58 kB | 5.61 kB | |
index-HASH.js gzip | 261 B | 261 B | ✓ |
link-HASH.js gzip | 1.66 kB | 1.66 kB | ✓ |
routerDirect..HASH.js gzip | 319 B | 319 B | ✓ |
withRouter-HASH.js gzip | 320 B | 320 B | ✓ |
bb14e60e810b..30f.css gzip | 125 B | 125 B | ✓ |
Overall change | 14 kB | 14 kB |
Client Build Manifests Overall increase ⚠️
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
_buildManifest.js gzip | 418 B | 419 B | |
Overall change | 418 B | 419 B |
Rendered Page Sizes
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
index.html gzip | 531 B | 531 B | ✓ |
link.html gzip | 544 B | 544 B | ✓ |
withRouter.html gzip | 524 B | 524 B | ✓ |
Overall change | 1.6 kB | 1.6 kB | ✓ |
Diffs
Diff for _buildManifest.js
@@ -13,7 +13,7 @@ self.__BUILD_MANIFEST = {
"static\u002Fchunks\u002Fpages\u002Fhooks-4e38b05900fed34fcf34.js"
],
"/image": [
- "static\u002Fchunks\u002Fpages\u002Fimage-5cc691491b3c13e4a3e9.js"
+ "static\u002Fchunks\u002Fpages\u002Fimage-5fb28be4f48700653962.js"
],
"/link": ["static\u002Fchunks\u002Fpages\u002Flink-461e3656f357dad048d3.js"],
"/routerDirect": [
Diff for image-HASH.js
@@ -121,6 +121,8 @@
var _useIntersection = __webpack_require__(7426);
+ var loadedImageURLs = new Set();
+
if (false) {
}
@@ -331,7 +333,7 @@
} // See https://stackoverflow.com/q/39777833/266535 for why we use this ref
// handler instead of the img's onLoad attribute.
- function handleLoading(img, placeholder, onLoadingComplete) {
+ function handleLoading(img, src, placeholder, onLoadingComplete) {
if (!img) {
return;
}
@@ -346,6 +348,8 @@
img.style.backgroundImage = "none";
}
+ loadedImageURLs.add(src);
+
if (onLoadingComplete) {
onLoadingComplete();
}
@@ -459,6 +463,10 @@
isLazy = false;
}
+ if (src && true && loadedImageURLs.has(src)) {
+ isLazy = false;
+ }
+
var _ref4 = (0, _useIntersection.useIntersection)({
rootMargin: "200px",
disabled: !isLazy
@@ -601,6 +609,7 @@
});
}
+ var srcString = src;
return /*#__PURE__*/ _react["default"].createElement(
"div",
{
@@ -664,7 +673,7 @@
className: className,
ref: function ref(img) {
setRef(img);
- handleLoading(img, placeholder, onLoadingComplete);
+ handleLoading(img, srcString, placeholder, onLoadingComplete);
},
style: imgStyle
})
Webpack 4 Mode (Decrease detected ✓)
General Overall increase ⚠️
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
buildDuration | 9.9s | 9.8s | -92ms |
buildDurationCached | 3.8s | 3.9s | |
nodeModulesSize | 49.3 MB | 49.3 MB |
Page Load Tests Overall decrease ⚠️
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
/ failed reqs | 0 | 0 | ✓ |
/ total time (seconds) | 2 | 2.064 | |
/ avg req/sec | 1250.24 | 1210.96 | |
/error-in-render failed reqs | 0 | 0 | ✓ |
/error-in-render total time (seconds) | 1.138 | 1.133 | 0 |
/error-in-render avg req/sec | 2196.62 | 2206.25 | +9.63 |
Client Bundles (main, webpack, commons)
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
14.HASH.js gzip | 3.11 kB | 3.11 kB | ✓ |
677f882d2ed8..HASH.js gzip | 13.9 kB | 13.9 kB | ✓ |
framework.HASH.js gzip | 41.8 kB | 41.8 kB | ✓ |
main-HASH.js gzip | 7.81 kB | 7.81 kB | ✓ |
webpack-HASH.js gzip | 1.19 kB | 1.19 kB | ✓ |
Overall change | 67.8 kB | 67.8 kB | ✓ |
Legacy Client Bundles (polyfills)
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
polyfills-HASH.js gzip | 31.3 kB | 31.3 kB | ✓ |
Overall change | 31.3 kB | 31.3 kB | ✓ |
Client Pages
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
_app-HASH.js gzip | 791 B | 791 B | ✓ |
_error-HASH.js gzip | 3.83 kB | 3.83 kB | ✓ |
amp-HASH.js gzip | 531 B | 531 B | ✓ |
css-HASH.js gzip | 333 B | 333 B | ✓ |
hooks-HASH.js gzip | 910 B | 910 B | ✓ |
index-HASH.js gzip | 230 B | 230 B | ✓ |
link-HASH.js gzip | 1.64 kB | 1.64 kB | ✓ |
routerDirect..HASH.js gzip | 297 B | 297 B | ✓ |
withRouter-HASH.js gzip | 293 B | 293 B | ✓ |
e025d2764813..52f.css gzip | 125 B | 125 B | ✓ |
Overall change | 8.98 kB | 8.98 kB | ✓ |
Client Build Manifests
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
_buildManifest.js gzip | 418 B | 418 B | ✓ |
Overall change | 418 B | 418 B | ✓ |
Rendered Page Sizes
vercel/next.js canary | atcastle/next.js fix-19074 | Change | |
---|---|---|---|
index.html gzip | 575 B | 575 B | ✓ |
link.html gzip | 586 B | 586 B | ✓ |
withRouter.html gzip | 568 B | 568 B | ✓ |
Overall change | 1.73 kB | 1.73 kB | ✓ |
…l#26968) fixes vercel#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.
fixes #19074
This change disables image lazy-loading when both of the following are true:
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:
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.
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.