Tabs: Lazyload

[summercms]

Something we have done in our cms, was adding lazyloading to tabs, which increased performance for all themes and plugins.

It would be kind of nice if that was rolled out to tabs in a web standardized form.

[mrmckeb]

Thanks for sharing, @ayumi-cloud.

I can see lazy-loading being applied to the contents of many components - perhaps there should be a lazy-loading component itself, which could be the child of tabs (and other elements)?

Can you explain more how you would expect this to work? How would a developer make use of this feature?

[summercms]

Can you explain more how you would expect this to work? How would a developer make use of this feature?

Sure, I was hoping that developers could have Native lazyloading for tabs and use the same methods that Addy Osmani from Google used to natively lazy load images in browsers, see here: https://addyosmani.com/blog/lazy-loading/

To lazy load tabs, developers could just add an attribute to the tabs, see lazyloading attributes

The original Lazyloading explainer can be found here: https://github.com/scott-little/lazyload

Also when a user opens say tab 2 using a hashed uri (to directly open it). The contents of tab one should not display before tab 2 loads in the browser giving a FOIT (Flash of Invisible Text) issue.

Hope that helps.

p.s. Would be interested to know what other components you are thinking to lazyload.

---

An example from our cms:

Let's say a user is on a using a 2G/GPRS network connection and the data is coming very slowly to their device:

• First - The tab list loads

• Second - You see a blue loading spinner for the tab content

• Third - The tab content gets loaded.

Please note, when a user is using a fast internet connection all these sequences would take milliseconds.

[Malvoz]

@ayumi-cloud where does the content in the tabs come from? During the finalization of the loading attribute for img someone asked about potentially enabling lazy-loading for custom components, see discussion from whatwg/html#3752 (comment) (you'll probably have to hit the "Load more..." button to see the related comments).

So presumably the HTML spec is the right venue to raise this in, instead.

Other related concepts to improve performance by deferring rendering of content may include the (albeit discontinued) <virtual-scroller>, and CSS content-visibility (more info https://web.dev/content-visibility/).

[summercms]

So presumably the HTML spec is the right venue to raise this in, instead.

I wasn't sure whether to open this here or in whatwg that's why I opened and closed this issue at the beginning - will open it over there.

[gregwhitworth]

@ayumi-cloud one thing that you can utilize Open UI for is possibly to get feedback from folks on how often libraries lazy load content within components and what type of components they do this on. This will also help bolster the usecases but yes ultimately the work for spec text belongs in WHATWG. Closing this issue out but please re-open it if something changes.