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

Tabs: Lazyload #238

Closed
summercms opened this issue Dec 8, 2020 · 5 comments
Closed

Tabs: Lazyload #238

summercms opened this issue Dec 8, 2020 · 5 comments

Comments

@summercms
Copy link

summercms commented Dec 8, 2020

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.

@summercms summercms changed the title Lazyload Tabs Tabs: Lazyload Dec 9, 2020
@summercms summercms reopened this Dec 9, 2020
@summercms summercms mentioned this issue Dec 9, 2020
@mrmckeb
Copy link
Collaborator

mrmckeb commented Dec 9, 2020

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
Copy link
Author

summercms commented Dec 9, 2020

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

image

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

image

  • Third - The tab content gets loaded.

image

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

@Malvoz
Copy link
Contributor

Malvoz commented Dec 10, 2020

@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
Copy link
Author

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
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants