[Fizz] Preload "suspensey" images#27191
Merged
gnoff merged 1 commit intofacebook:mainfrom Aug 10, 2023
Merged
Conversation
86aff4c to
f166788
Compare
1 task
f166788 to
ed57e93
Compare
f9c316a to
3b44caf
Compare
…ng SSR. We now track whether a rendered img is "suspensey" and emit a corresponding preload behind fonts in priority.
3b44caf to
26bf677
Compare
sebmarkbage
reviewed
Aug 10, 2023
| const key = getImagePreloadKey(src, imageSrcSet, imageSizes); | ||
| let resource = resources.preloadsMap.get(key); | ||
| if (!resource) { | ||
| resource = { |
Contributor
There was a problem hiding this comment.
Let's extract this stuff too like getPreloadResource(...).
Collaborator
Author
There was a problem hiding this comment.
I'd like to but I think it needs to go in another PR. there are challenges with this b/c the current implementation is highly optimized to avoid creating props object unless absolutely required and so this can't be tidily implemented in a single function. Also I should do the same thing for stylesheet and other resource types
sebmarkbage
approved these changes
Aug 10, 2023
github-actions bot
pushed a commit
that referenced
this pull request
Aug 10, 2023
Eventually we will treat images without `loading="lazy"` as suspensey meaning we will coordinate the reveal of boundaries when these images have loaded and ideally decoded. As a step in that direction this change prioritizes these images for preloading to ensure the highest chance that they are loaded before boundaries reveal (or initial paint). every img rendered that is non lazy loading will emit a preload just behind fonts. This change implements a new resource queue for high priority image preloads There are a number of scenarios where we end up putting a preload in this queue 1. If you render a non-lazy image and there are fewer than 10 high priority image preloads 2. if you render a non-lazy image with fetchPriority "high" 3. if you preload as "image" with fetchPriority "high" This means that by default we won't overrsaturate this queue with every img rendered on the page but the earlier encountered ones will go first. Essentially this is React's own implementation of fetchPriority="auto". If however you specify that the fetchPriority is higher then in theory an unlimited number of images can preload in this queue. This gives users some control over queuing while still providing a good default that does not require any opting into Additionally we use fetchPriority "low" as a signal that an image does not require preloading. This may end up being pointless if not using lazy (which also opts out of preloading) because it might delay initial paint but we'll start with this hueristic and consider changes in the future when we have more information DiffTrain build for [f359f9b](f359f9b)
This was referenced Aug 10, 2023
gnoff
added a commit
that referenced
this pull request
Aug 10, 2023
`pushImg` should have been gated by enableFloat Added in #27191
kodiakhq bot
pushed a commit
to vercel/next.js
that referenced
this pull request
Aug 12, 2023
Updated React from cb3404a0c to f359f9b41. ### React upstream changes - facebook/react#27191 - facebook/react#27209 - facebook/react#27199 - facebook/react#27218 - facebook/react#27217 - facebook/react#27212
|
Hi seems like the preload only happens for the src/srcset inside an img. If you have a separately defined source tag then the images are not preloaded ? eg in the example below image1.jpg will be preloaded, but image1.webp will not. |
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
Eventually we will treat images without `loading="lazy"` as suspensey meaning we will coordinate the reveal of boundaries when these images have loaded and ideally decoded. As a step in that direction this change prioritizes these images for preloading to ensure the highest chance that they are loaded before boundaries reveal (or initial paint). every img rendered that is non lazy loading will emit a preload just behind fonts. This change implements a new resource queue for high priority image preloads There are a number of scenarios where we end up putting a preload in this queue 1. If you render a non-lazy image and there are fewer than 10 high priority image preloads 2. if you render a non-lazy image with fetchPriority "high" 3. if you preload as "image" with fetchPriority "high" This means that by default we won't overrsaturate this queue with every img rendered on the page but the earlier encountered ones will go first. Essentially this is React's own implementation of fetchPriority="auto". If however you specify that the fetchPriority is higher then in theory an unlimited number of images can preload in this queue. This gives users some control over queuing while still providing a good default that does not require any opting into Additionally we use fetchPriority "low" as a signal that an image does not require preloading. This may end up being pointless if not using lazy (which also opts out of preloading) because it might delay initial paint but we'll start with this hueristic and consider changes in the future when we have more information
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
`pushImg` should have been gated by enableFloat Added in facebook#27191
bigfootjon
pushed a commit
that referenced
this pull request
Apr 18, 2024
Eventually we will treat images without `loading="lazy"` as suspensey meaning we will coordinate the reveal of boundaries when these images have loaded and ideally decoded. As a step in that direction this change prioritizes these images for preloading to ensure the highest chance that they are loaded before boundaries reveal (or initial paint). every img rendered that is non lazy loading will emit a preload just behind fonts. This change implements a new resource queue for high priority image preloads There are a number of scenarios where we end up putting a preload in this queue 1. If you render a non-lazy image and there are fewer than 10 high priority image preloads 2. if you render a non-lazy image with fetchPriority "high" 3. if you preload as "image" with fetchPriority "high" This means that by default we won't overrsaturate this queue with every img rendered on the page but the earlier encountered ones will go first. Essentially this is React's own implementation of fetchPriority="auto". If however you specify that the fetchPriority is higher then in theory an unlimited number of images can preload in this queue. This gives users some control over queuing while still providing a good default that does not require any opting into Additionally we use fetchPriority "low" as a signal that an image does not require preloading. This may end up being pointless if not using lazy (which also opts out of preloading) because it might delay initial paint but we'll start with this hueristic and consider changes in the future when we have more information DiffTrain build for commit f359f9b.
bigfootjon
pushed a commit
that referenced
this pull request
Apr 18, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Eventually we will treat images without
loading="lazy"as suspensey meaning we will coordinate the reveal of boundaries when these images have loaded and ideally decoded. As a step in that direction this change prioritizes these images for preloading to ensure the highest chance that they are loaded before boundaries reveal (or initial paint). every img rendered that is non lazy loading will emit a preload just behind fonts.This change implements a new resource queue for high priority image preloads
There are a number of scenarios where we end up putting a preload in this queue
This means that by default we won't overrsaturate this queue with every img rendered on the page but the earlier encountered ones will go first. Essentially this is React's own implementation of fetchPriority="auto".
If however you specify that the fetchPriority is higher then in theory an unlimited number of images can preload in this queue. This gives users some control over queuing while still providing a good default that does not require any opting into
Additionally we use fetchPriority "low" as a signal that an image does not require preloading. This may end up being pointless if not using lazy (which also opts out of preloading) because it might delay initial paint but we'll start with this hueristic and consider changes in the future when we have more information