-
-
Notifications
You must be signed in to change notification settings - Fork 676
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
loads element without any scroll. ignores threshold #591
Comments
I'm also facing this issue. |
Well... it seems that the problem was |
Thanks, @MtDalPizzol Yes it you set The solution you found sounds very smart. Can I ask you to try using JS (not native) lazy loading also on the images and see if your Largest Contentful Paint further improves? I guess it will. |
@verlok I could try that. But to be honest, I don't see how it would make LCP better. I feel like anything that needs "foreign" JS code will always perform worse than native browser functionality. Is there something I'm not aware of here? Also, in the Core Web Vitals docs, they repeatedly state that you should run as little JS as possible AND use native when available. On top of that, my largest element on page load is not lazily loaded. So, at least in my case, it doesn't seem necessary to do that. |
By the way, to be clear: I'm using the library for both (images, and iframes), just with different configs: import LazyLoad from 'vanilla-lazyload'
export default function initLazyLoad () {
const lazyImages = new LazyLoad({
elements_selector: 'img.lazy',
use_native: true
});
const lazyIframes = new LazyLoad({
elements_selector: 'iframe.lazy',
threshold: 600
});
} |
I will explain in a second..
Correct.
Awesome. This is indeed a best practice. If you take all of the a above, you may agree with me that a) the image causing your LCP won't be delayed if you load every other image else using JS, but b) if you use native lazy loading, images that are just below the fold are loaded as soon as the page loads, meaning while the LCP image is loading, meaning slowing its loading down. This would be visible especially on slower connection. You don't have trust me, just try it and test it using webpagetest.org, on both fast and slow connections. |
This makes A LOT of sense. I'll surely give this a try. Thank you so much for the tip. My only concern with this, is that Core Web Vitals are a tricky beast to handle. We're working hard, trying to get ready for the new INP metric that comes into play in march 2024, and since TBT can affect INP, I'm a little worried that leaving image handling to JS might affect INP due to potentially triggering long tasks during the page lifecycle. |
Thanks for sharing, @MtDalPizzol I cN tell you that my lazy load script doesn't run any long task, it just watches the elements using the IntersectionObserver API and when it's time, it copies one attribute on another. |
Sure! In fact, that was the reason I switched from I'll go ahead and implement your suggestions! Thanks a lot, again! PS: already following on X and reading the articles on the site. |
Hi,
Please see the issue shown on video here:
https://www.loom.com/share/d172a32f5f6a447a99ecd2942a9daeb9
My init is:
ll = new LazyLoad({ // Assign the callbacks defined above callback_enter: callback_enter, callback_exit: callback_exit, callback_cancel: callback_cancel, callback_loading: callback_loading, callback_loaded: callback_loaded, callback_error: callback_error, callback_finish: callback_finish, elements_selector: "iframe", threshold: 300, });
I also have the callbacks from your demos set up, so I can see that it's loading without me scrolling at all.
It seems to do it twice somehow. I don't know what to think except that something on my page may be tricking the Intersection Observer somehow.
The text was updated successfully, but these errors were encountered: