Blazy 3.x Roadmap

We should update this later when I have time to get back to it.

In short, it will be about few things like dropping deprecated stuffs such as VEF, D8, and PHP7, solidification, codebase, functionality, minimal upgrade issues. And probably new features.

Feel free to share your thoughts.

Thank you.

My ultimate goal is to have a robust and easy to use system for building sliders and other components that need to load media in a performant way.

3.x seems like an opportunity to review how it works now and make some changes to streamline future use.

Can you please share some insight on the current status of the Blazy library, and whether browser's native support for lazy loading can replace it?

From the project page description, it sounds like 90% of the benefits are natively supported. Does it make sense to narrow the focus of this module to support only the parts that are still problematic?

Since 2.6, Blazy is 100% native, and had been with native since its early incubation in 2019 before Firefox and core had it.

Old blazy library was made a fallback for old browsers instead. You can even remove old library via Blazy UI if targetting modern browsers.

Check out relevant issues for details.

Above all, Blazy also offers few important enhancements to native to account for LCP via Slider and co. option under Loading priority aside from Preload option, hard-coded 8000px threshold fixes with native IO and RO, CLS via Aspect ratio, etc.

More improvements are always open as I know browsers' APIs are evolving into awesomeness like many languages.

Let me know what you think?

Using the library as a fallback makes sense, although I suspect the number of users on unsupported browsers is rapidly decreasing these days. Hopefully one day it will not be a concern at all.

I read up a bit more on how native lazy loading works with that 8000px threshold. It seems like it only helps when you are scrolling vertically, where it will load images further down the page as needed.

But it sounds like it won't help for sliders. If slide images are set to lazy load, I suspect they would begin loading when visible (too late).

So additional preloading options are still needed. There are currently 6 choices, and it takes some time to understand the differences and pick the right one. I think the notes could be improved to help people choose.

I'll take a stab at my interpretation for when to use them.

Lazy - Use this when the whole slider is below the fold, all images are lazy loaded. But this does not help preload images in a slider.

Auto - Automatically determine which to use. Sounds like it's useful when the slider may or may not be above the fold. So not for hero sliders. What does this do for preloading the next slides? How does this one work, and when else should it be avoided?

Eager - Good for above the fold only. Are all images in the slider loaded this way?

Defer - "Trigger native lazy after the first row is loaded". Does this mean that the first is eagerly loaded and the next are loaded after the transition? The linked issue doesn't really explain it, I am more confused after reading it.

Unlazy - Does this eagerly load all the images? What's the difference vs eager?

Slider - Good for single images sliders, but not carousels. How is this different than Defer?

I think in most cases what we want is a way to load the first image, then load the rest of the page, then start preloading images in the slider so they're ready when used. I can think of a few different scenarios that might take a different algorithm to optimize, like load them all if there's only a few, or preload a set number ahead of time if there are a lot.

> ... only helps when you are scrolling vertically...
Blazy takes advantage of native IO along and to overcome some issues/ limitations with native lazyload. Understanding this should reduce some confusion. Noted roughly in project home.

IO works in all/ regardless directions. More about object visibility within the viewport -- left, right, top, bottom -- vertical or horizontal scrolls.

Blazy takes good advantages of IO to have some screnarios: defer 8000px threshold; eager/ immediate; unlazy to totally disable lazy routines; slider to load one visible and delay the rest, etc.

Placing media below an 8000px wall of texts, in the middle, or right above the LCP fold while watching the Networks tab, would help you understand the differences.

Understanding web vitals will help the provided Blazy options make sense: https://web.dev/articles/vitals.

> ...it won't help for sliders. If slide images are set to lazy load, I suspect they would begin loading when visible (too late).
Yes and No. Understanding how sliders work would point you to that Yes and No, assumed large ones:

1. Slider/ slideshow: one visible slide at a time, the rest are out of viewport. Both Slick with float, and Splide with Flexbox will push the rest out of viewport, except the one visible. Those invisible won't be read by IO, the trigger of Blazy native lazyload.
2. Carousel: multiple visible slides within a viewport and beyond.
3. Fader, transitioned or animated: multiple visible slides within a viewport, normally absolutely positioned at Slick and most commercial sliders I know of, but not at Splide, hardly beyond the viewport, unless you modified it.

> defer vs slider ... loading priority.

1. Defer will not load anything, even below 8000px threshold, until one (row) is visible, the trigger. Nothing loaded because the browsers don't understand that Defer value. Once one is visible, then the rest are delegated back to browsers after that trigger by giving them values they understand.
2. Slider will only load the first visible, below or above, no problems. To solve LCP issue without sacrificing perfomance for jumbrotrons aka hero images.

Both are invalid values for a very short life, but with dynamic JS will make them valid. Some validators had learned about dynamic contents, some were outdated. Do not use oudated ones to validate dynamic contents, they just need an update.

> Unlazy vs eager

1. Unlazy removes native lazyload signatures/ routines/ mechanisms/ overheads. You don't want to lazy load small logos, or thumbnails, nor LCP area. That would make Lighthouse complain.
2. Eager still has native signatures.

> Lazy - Use this when the whole slider is below the fold, all images are lazy
loaded. But this does not help preload images in a slider.
Blazy has two preloads: native browsers' via Preload option, and dynamic/ JS preload (ahead) as a combo of sliders before or after change/ move events with Blazy. Both help relevant to different scenarios.

> most cases what we want is a way to load the first image, then load the rest of the page...
See web vitals above. The Loading priority + Preload options should give you exactly what you want, and beyond. Shortly, scenarios, placements of media within the viewport, will affect your decisions. And Blazy is providing you options to accomplish them while considering different scenarios. Lighthouse will yell at you if you use lazy load on the LCP area, even if you think lazyload is good. However Slider Loading priority should make it fairly happy while keeping the rest of hidden/ out-of-viewport slides not immediately loaded. If confused, see above about native IO. Understanding that Blazy makes use of IO along with native lazy load will reduce some confusion.

> notes could be improved to help people choose.
Definitely. Improvements are always valuable and welcome :)

3.x is out.

The roadmap was pretty straight forward and enough as said in #2 and project home.

Thank you.

Automatically closed - issue fixed for 2 weeks with no activity.