aFarkas
commented
8 years ago I also thought about that and I also saw the polyfill already. My plan was to at least play with the API to have some know how and maybe give some input in the design process of this young API. But I have currently plenty of work and it seems that this won't change until end of August.
In general, I'm an extreme fan of new web platform features as also of performance features, but I have a simple rule: I only add a feature and relay on polyfills as soon as two different browser engines are supporting them. (It doesn't have to be a stable browser version though). (And yes: There are more, but also vague rules).
This is why I'm now preparing the switch over to requestIdleCallback. Which is already supported in Chromium and soon will be supported by Firefox. My tests are very promising although I hoped rIC would give me not only an idle time, but also a time, where the layout is guaranteed to not be dirty.
With other yes, but not now ;-).
Big question here: Is any other browser interested to implement this API soon?
But let's talk about the thing here:
I must say, that I have nearly no knowledge about the full capabilities of IntersectionObserver, but I noticed some parts.
Here are some parts about the polyfill:
- scroll/resize and mutationobserver The polyfill is only using the events above. And for scroll (a non bubbling event), it is using event propagation instead of event capturing. The later would also fire if a scrollable child in the container is scrolled, which can bring an element also into viewport. Is this how IntersectionObserver should work? I thought any change, that might bring an element into view should be used. If this is so, you can find a full list of events in lazysizes.
- throttle function
This might be a very subjective view, but it helped me a lot.
getBoundingClientRectcan be an extreme fast method that can be called on hundreds of elements (if you have more you might want to use efficient script yielding) on a high frequency without causing jank. On the other hand it can be very slow and causes jank if it is called even only on one element, if you call it at the wrong time.
After I refactored my throttle method to: Do a normal throttle using setTimeout, then do a rAF and then call a timeout with 0. I had dramatic performance improvements.
A cleaned up version could look like this:
var throttle = function(fn){
var running;
var lastTime = 0;
var run = function(){
running = false;
lastTime = Date.now();
fn();
};
var afterRAF = function(){
setTimeout(run);
};
var getRAF = function(){
rAF(afterRAF);
};
return function(){
if(running){
return;
}
var delay = 125 - (Date.now() - lastTime);
running = true;
if(delay < 9){
delay = 9;
}
setTimeout(getRAF, delay);
};
};This has two interesting effects by scheduling 3 jobs instead of just one, the job takes longer if the browser is currently busy (mostly only in the loading phase), which results in slower frequency. The second thing, that seems to heavily improve things is the fact that I often get a position in the frame life cycle right after frame commit (i.e.: rAF + timeout of 0. Basically this is also the position, where rIC is scheduling tasks.) (The chance, that layout is dirty is much lower.)
If you are interested the upcoming throttle function can be seen here.
- Memory leaking observed elements I don't know how the native IntersectionObserver works, but I hope there is only a weak reference to the observed elements. However the polyfill holds a strong reference, which means if the element is removed from the document and the page author has no reference to it, the polyfill will still have one. This is a common problem of lazyloaders. For me this is currently the number one point why I can't use the current state of the polyfill.
About the IntersectionObserver spec and its use case:
lazysizes is different in the way, that I don't use one static expand (margin). It uses a dynamic one. If there are currently images in view loaded only other images in view are loaded. Images that are near the view are not downloaded. If network is idling the view is expanded to preload images, that are not in view.
This way you get two important things:
- images that are not in view are not in "competition" with in view images. They don't consume bandwidth and slow down in view image loading.
- On the other hand you can (And I think a good developer should) heavily preload not in view images, so that the user doesn't need to wait for images to load as soon as he scrolls through the page.
I have difficulties to think how I can implement this model with IntersectionObserver because of two things.
- It is not possible to change options on the fly.
- Assuming I would use two observers: It is not possible to pause and resume an observer.
The only thing I can think of, is to use one observer with the large expand option and than if the callback is called to sort these records for in view and near view images and then decide how to do things.
Use case: I don't doubt, that this API improves developer convenience, battery lifetime and also performance for developers, which don't use the right tools to implement in view detection. (No or non efficient throttled event handlers for example.)
But I really doubt, that it would noticeable improve jank with good current implementations. Especially, I don't think, that it would dramatically improve performance compared to the upcoming version of lazysizes.
The way how scroll events do work now has dramatically changed in the last years. FF is just making the switch and now all browser have async scroll events. The actual visual scroll is now always decoupled from the scroll event itself.
This doesn't mean, that it is bad (I think it can be very good for battery lifetime), but I don't think it will produce wonders.
triblondon
yoavweiss
ojanvafai
abarre
scott-thrillist
thasmo
t-kelly
caillou
willstocks
serulux
This is a fantastic tool and really positive for the performance of the web. I'd love to see this using IntersectionObserver to compute the intersection of the viewport and the lazyload elements, which will avoid the need to use a scroll handler in browsers that offer support for IntersectionObserver.
I'm currently working on adding an IntersectionObserver polyfill to the polyfill service, which will provide IO support on all the browsers you support for lazySizes, so a nice-to-have would be a version of lazysizes that relies on IO with no onscroll fallback, on the basis that it can be polyfilled where needed.