4 ms·
Instead of starting the fetch when the image comes into view - check every 250ms or so what images are in the viewport.
by winrid 7y ago
Instead of starting the fetch when the image comes into view - check every 250ms or so what images are in the viewport.
- zamadatix 7y agoIf your answer to a JavaScript control flow problem is "fix it with a timer" it's almost never what you want to do. Checking every 250ms just makes things feel delayed for users on fast systems (particularly after a large scroll) and slow for users where 10 images won't load in 250ms while also wasting resources when there is nothing to do. https://news.ycombinator.com/item?id=21932726 https://news.ycombinator.com/item?id=21932726 said exactly what I was typing out on how to handle this general situation without the upcoming API for the exact use case mentioned in this comment https://news.ycombinator.com/item?id=21932328 https://news.ycombinator.com/item?id=21932328
- winrid 7y agoYeah, no. I would use a queue. Capture the picture-enter-viewport event and then 50ms later (sorry I said 250... probably too long) verify it's still in the viewport like in the case of fast scrolling. Denounce so you don't fire timers for events close together. Works cross browsers, doesn't waste resources, will be smooth.
- Noumenon72 7y agoDid you mean "debounce" instead of "denounce"? Otherwise Google has failed me.
- winrid 7y agoYeah sorry :)
- zamadatix 7y agoThat's not a queue it's just a delayed async call (i.e. if 5,000 calls ask to be called they will all go without queuing in 50ms), what the other comment described is a queue. 50ms is way too short, a user on a 1080p screen would need to scroll at 360 pixels per second to avoid loading every image along the way. Even trying to do that on purpose is hard as hell https://clickspeedtest.com/scroll-test.html https://clickspeedtest.com/scroll-test.html. Guaranteed that every mobile user is going to be loading every image on scroll over 4g as well creating the original back pressure issue now with 3 more frames of lag. "smooth" does not mean "check every 3 frames" it means schedule things in a way they can happen immediately when the browser is ready, not your timer.
- cryptonector 7y agoAnd with the timer thing you're consuming CPU unnecessarily. No timers please.
- ReactiveJelly 7y agoEdit: I rewrote my comment because I misunderstood yours. You could tie it to an "on-scroll" type of event, like how many text boxes will fire an event X milliseconds after a text edit event, so that they can process the text when the user is not likely to be typing. A single timer by itself won't busy-wait, but I agree that running a timer all the time is a waste. Just run it when scrolling, when CPU use will already be high.
- dcow 7y agoIs there really no way to determine if an image has left the viewport? This is a solved problem on other platforms: you just cancel image fetches if the image has scrolled out of the viewport. No timers needed.
- EdwardDiego 7y agoThere's an IntersectionObserver API that does exactly this - it fires your callback when your configured threshold (X% of element A is intersecting element B) is passed in either direction.
- zamadatix 7y agoSee the second link in my comment (https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...). Determining if the image is in the viewport is easy, cancelling the async Fetch request after it's been made is an experimental API so not finalized/available everywhere.