Contact emails
scli...@chromium.org, rajen...@chromium.org, be...@chromium.org
Design doc/Spec
Design doc: https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit
Spec: TBD
Summary
Defer loading certain below the fold third-party iframes and below-the-fold images on the page until the user scrolls near them. For frames, third-party iframes that are meant to be shown to the user are deferred, leaving alone frames that are used for analytics or communication according to heuristics. For images, insert placeholders with appropriate dimensions, which it gets by issuing a range request for the first few bytes of the image. When the user scrolls, deferred frames and images that will be visible soon start loading.
Motivation
Reduce data usage, speed up page loads, and reduce memory usage.
From UMA histograms (Navigation.DeferredDocumentLoading.StatesV4) for Android, out of all cross-origin iframes loaded on pages, over 20% were both (a) likely intended to be shown to the user according to heuristics that attempt to filter out analytics/communication iframes (e.g. filter out 0x0, above or left of the screen, etc.) and (b) were never actually visible to the user, i.e. the user never scrolled all the way down to the iframe.
Preliminary benchmarks with basic prototypes of LazyLoad have shown 18% improvement to Speed Index on typical pages on a simulated 3G network. Other benchmarks have shown up to 35% reduction in typical page size with LazyLoad, see analysis.
Risks
Interoperability and Compatibility
Edge: No signals
Firefox: No signals
Safari: No signals
Web developers:
Multiple JavaScript libraries attempt to use JavaScript to lazy load images, e.g. link
A thread on WICG about lazy loading images
Lazy loading is conceptually very similar to the common infinite scroll design
There are some web compatibility risks with LazyLoad, e.g. the document's "load" event could happen before deferred elements are loaded in, so sites that relied on the old ordering might not work correctly unless they disable LazyLoad. Other compatibility risks can be found listed in the design docs, here and here.
Ergonomics
Deferring images will make use of the image replacement feature in Blink.
Some browser features (e.g. Print, Save Page As) that expect all resources to be fully loaded will need to be updated to force any remaining deferred resources to be loaded in before resolving, more details here.
Activation
The current idea is that, once launched, the feature would be enabled by default, with a way to opt-out, although the exact design here is still TBD.
Debuggability
Deferred iframes and images will be marked as such when looking at the "Elements" view in DevTools, so that web developers can differentiate between a slow-loading resource and an element that was specifically deferred by LazyLoad. Exact UI and plumbing TBD.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Android only, at least initially.
LazyLoad as a feature doesn't need to be Android specific, but the plan is to start with Android since the benefits of LazyLoad will likely have the most impact on Android, and this will also help minimize any negative impact to user experience. If LazyLoad is successful on Android, then desktop platforms will be considered as well.
Link to entry on the feature dashboard
ChromeStatus link: TBD
Requesting approval to ship?
No.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d84cdb3a-5114-498b-876c-54cc0b810ef5%40chromium.org.
Defer loading certain below the fold third-party iframes and below-the-fold images on the page until the user scrolls near them or until all content above the fold has finished loading.
That'd solve the problem for opening an article and reading it while offline, and it would also improve the experience for fast scrolling people.
Is the plan to enable this for all users or just when data savings is enabled? I'd be supportive of doing it in data saver mode but have some pretty big concerns about doing it across the board.
Fetching the images after the network has gone idle can have a lot of latency, particularly if the cell connection needs to ramp back up (not to mention using a lot of power going between states). There's a pretty high likelihood that users will be scrolling to blank content that needs to fill in and it's one of the bigger problems with js-based lazy-loaders (my preference when working with them is to delay the images until after the main content loads but to still load all of the images and not wait for user interaction).
It looks like the range-request mechanism is only used for cases where dimensions aren't known. Any idea what the risk is of breaking tracking and retargeting pixels?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4c151882-0a67-4bc0-9306-14db69f3a364%40chromium.org.
>Defer loading certain below the fold third-party iframes and below-the-fold images on the page until the user scrolls near them.
Could we change this to:Defer loading certain below the fold third-party iframes and below-the-fold images on the page until the user scrolls near them or until all content above the fold has finished loading.
That'd solve the problem for opening an article and reading it while offline, and it would also improve the experience for fast scrolling people.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a57a2a40-fa36-469a-9cd1-a3e200c5c4e9%40chromium.org.
What exactly defines "near them"?If the data connection is slow and the user is only two flings/scrolls away from the image, I'd be annoyed: "Why hasn't it loaded already?" - in that case, lazy loading makes reading an article "lazy waiting" (Medium on desktop has this annoyance too).In general, I think this is a good idea, but there are implications that need to be thought of.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e6f12bd8-ce8b-4932-bdd4-9707d24febd7%40chromium.org.
>Defer loading certain below the fold third-party iframes and below-the-fold images on the page until the user scrolls near them.
Could we change this to:Defer loading certain below the fold third-party iframes and below-the-fold images on the page until the user scrolls near them or until all content above the fold has finished loading.
Unfortunately, that would mean the user loses out on data savings and memory usage savings if they never end up scrolling to the content.
I'm concerned about how this will affect users with intermittent connectivity. What if you open an article when you have connectivity, but try to read it when you don't (for instance, while in transit)? Currently, everything will be cached for your offline perusal, unless the publisher uses lazy load (e.g. Medium). With this change, large blocks of content below the fold would be missing when offline.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d84cdb3a-5114-498b-876c-54cc0b810ef5%40chromium.org.
Overall, this is something I heard people want for a long while, so thanks for working on this!With that said, I have some concerns about the approach.Are there plans to change the spec in order to match that behavior?* The HTML spec required that images delay the load event of the document they were fetched in. Will that change?
* The image element's load event fires only after its entire data was fetched? Will that change?
* Same questions for iframes.
If the answer to the above is true, are those changes web compatible? Is the plan to experiment with those changes to see their impact in the wild? If so, how are we planning to measure breakage?
Otherwise, the design document mentions fetching using range requests the first 2K of the image in order to get its dimensions, saying it is "highly likely to contain the image dimensions for larger images, according to UMA data (Blink.DecodedImage.EffectiveDimensionsLocation.* histograms)."Is it possible to share that data publicly? Would be very interesting to know what "highly likely" means.
Also, what is the plan for images that don't exhibit this property?And for progressive images (read: JPEGs) that fit their initial scan in that range - will that be displayed as a placeholder?
The design document also mentions a dependency on the Data Reduction Proxy - can you elaborate what that dependency is?
For images that are lazy loaded as they are outside of the initial viewport, would it be possible to include the layout based client hints? (as their display dimensions are known at the time their fetch starts)
Will users have a way to opt-out of that behavior, to address Brenton's concerns? Is there an alternative (heuristic) approach that will address them?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d84cdb3a-5114-498b-876c-54cc0b810ef5%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhjDPLKSLMpjKk0duP3Gea7S3cm3xosdAVGiBC_DH-i2Q%40mail.gmail.com.
>Defer loading certain below the fold third-party iframes and below-the-fold images on the page until the user scrolls near them.
Could we change this to:Defer loading certain below the fold third-party iframes and below-the-fold images on the page until the user scrolls near them or until all content above the fold has finished loading.
Unfortunately, that would mean the user loses out on data savings and memory usage savings if they never end up scrolling to the content.
While that's absolutely true, it would still be an improvement over the current behaviour and perhaps with powersaving mode (or simply a setting) it could be made more passive.
I just fear this feature will be useful for the majority of people, while being quite a nuisance for power users like myself.Scrolling on a macbook's touchpad is incredibly fast and using the scrollbar is instantaneous.
If I open a website, read the content above the fold and start scrolling after one minute, I would expect the entire website to be fully loaded but with this feature implemented as its currently planned, it would still need to load more content even after a minute.
Now that's visually annoying, but if the page starts jumping around because of images filling in the gaps... ouch.
Perhaps it would be more prudent to implement this feature and have it disabled by default for a while, allowing developers to select one out of several modes and try them out to see what it would do for their own experience, and for the experience of their customers. After feedback has been collected, a new default value could be chosen and developers will have already had some time to adjust their websites to make optimal usage for this feature.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f7162c9d-1fe2-4293-8b73-f8f8806e9bfd%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBp5rXUQ-CtqTTNpYFMMNWiiTKRMHSWEtdCL%3D8Pv5QGPuvgTg%40mail.gmail.com.
Range requests are a source of security issues since they're pretty undefined. I'm working to fix this for media elements, and the spec for lazy loading should do the same. I'll try to abstract as many of the algorithms as possible.Here are the attacks we should avoid https://github.com/whatwg/fetch/issues/144#issuecomment-368040980.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.