Skip to content
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

LazyLoad all Visible Items #180

Closed
maimairel opened this issue Jul 3, 2015 · 15 comments
Closed

LazyLoad all Visible Items #180

maimairel opened this issue Jul 3, 2015 · 15 comments

Comments

@maimairel
Copy link

Currently Flickity's new lazy load feature works by specifying how many images before and after the current cell is being lazy loaded. Is it possible to load every cell that's visible instead of specifying the number of cells. Maybe lazyLoad: 'auto', or is this a feature already available right now?

Thank you !

@CaptainCodeman
Copy link

👍 I think most people's expectation of image lazy-loading is usually focused on them being in the viewpoint rather than just a count.

It would be extra cool if non-loaded images that were quickly skipped past were ignored. i.e. only attempt to load images becoming visible when the scrolling speed is below a certain threshold or they will stop in the visible area.

@nvartolomei
Copy link

Also maybe it's nice to expose visible event so we could implement lazy load ourselves. Atm lazyload is triggered by cellSelected event.

@desandro
Copy link
Member

desandro commented Jul 8, 2015

+1 this issue if you would like to see this feature added.


Thanks for this feature request. This may be a nice feature, but I'm concerned about how much complexity would be added because of it. Specifying the number of adjacent cells is straightforward both for me to handle and for users to understand.

@CaptainCodeman
Copy link

Here's why (for me) the # of adjacent cells is slightly lacking as it currently is ...

Imagine using flickity with a set of images which may be a mix of landscape and portrait orientation in a responsive layout which varies in width based on the device (I don't think that's an unusual use-case).

On a smaller device with landscape images it may only need 2 or 3 to fill the visible area but on a wider device and with more portrait oriented images it may need many more - 5? 10? 20?. Whatever fixed number it is set to will be 'wrong' in some cases and either leave a visible gap or be wasting requests showing images that may never be seen.

For me the # of adjacent images should be the number to pre-load before they come into view.

I can see it making sense as-is for more static / fixed designs though and it's still useful even if the number has to be set too high (if it saves loading another 50 images for example).

@IanLunn
Copy link

IanLunn commented Jan 13, 2016

+1 and for the exact reason @CaptainCodeman has pointed out.

I'm working on a performance sensitive project and would like to use lazy loading to prevent non-visible images from downloading until necessary. I have cells set at a fixed width. 2 - 6 images are visible depending on screen size. Due to how lazyLoad currently works, if I don't load 5 ahead for desktop devices, cells come into view that haven't been preloaded. However, loading 5 ahead means when viewed on a mobile device, 3 images are being loaded that may not be required.

Also, if using lazyLoad: 5 and wrapAround: true for example, this means loading 10 images. Only loading the visible image would make the use of these two options together more performant too.

@ThePJMP
Copy link

ThePJMP commented Jan 28, 2016

+1 It would be a very useful feature

@matyushen
Copy link

+1

1 similar comment
@a-v-l
Copy link

a-v-l commented Apr 18, 2016

+1

@desandro
Copy link
Member

desandro commented Jul 11, 2016

With Flickity v2 out, you can use groupCells to group cells together as individual slides. groupCells can group cells by how many fit within the viewport. Then use lazyLoad to load images in those cells.

I'm closing this feature request for now. Thank you for your feedback!

@CaptainCodeman
Copy link

CaptainCodeman commented Jul 11, 2016

I don't think that is right, the two options are not really related IMO.

Whether you want things to lazy load is more likely based on where they are relative to the viewport, not whether they are in some group. I don't want to advance by any group of images, I want one at a time, but I want them lazy loaded.

The percentage setting for the grouping is more along the lines of what's needed for lazy loading though.

@mhemrg
Copy link

mhemrg commented Nov 18, 2018

I agree with @CaptainCodeman.
groupCells option isn't a good solution for the issue.

@madsem
Copy link

madsem commented Jan 10, 2019

Sadly this doesn't work

var flky = new Flickity( '.main-carousel', {
        lazyLoad: true,
        groupCells: '100%',
        accessibility: true,
        prevNextButtons: true,
        pageDots: false,
        resize: true,
        draggable: '>1',
        freeScroll: true,
        contain: true
    });

The last one on the right-hand side is never loaded, even though visible and grouped as you can see in the settings above.

This makes my slider look horrible and frankly, unusable on a production site. How can I lazyload really all in the visible viewport?

The slider is full-width, from 5 cells down to 1 on smaller devices. If only one cell is displayed in viewport, it loads, but as soon as there are 2+ the right-hand one is never loaded

@madsem
Copy link

madsem commented Jan 10, 2019

Argh, well... As so often, you open an issue and then a minute later figure out a solution. This is what happened here, so for anyone who has this issue:

Set

lazyLoad: 1,

This makes the slider also lazyload the next image in line.
Found here: #670

@nghiepdev
Copy link

groupCells or lazyLoad: 1 option isn't a good solution for the issue.

@jibinycricket
Copy link

Any solution to this?

@metafizzy metafizzy locked as resolved and limited conversation to collaborators May 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests