Lazy Loading of the Web Parts

[AJIXuMuK]

The discussion is based on the issue #6091.
Currently we're thinking on adding a new property to the web part's manifest called disableDeferLoading (subject to change).
Developers can set this property to true to inform the page engine to load the web part even if it's outside the viewport.

It should unblock the scenarios discussed in the issue: TOC, dynamic page section navigation, sharing the link (the latter should work now with no changes btw).

For the Page Sections navigation scenario: developers can set "disableDeferLoading": true for "anchor" web part.
In that case all instances of this web part will be loaded on the page.
No other changes should be needed.

Mentioning here all participants from the issue mentioned above.
@stchiew @tgorgdotcom @netti01 @pratk30 @AdenKenny @kmarwen @TitanRobot @Ludwixix @shaipetel @salascz @SPDEVGUY @patrickblanc @patmill

[SPDEVGUY]

I think having an option at the web or site level to disable this functionality would be preferred. Only having it as an option on a web part doesnt fix the problem of a scroll bar popping into existence only after everything was loaded, especially when that scroll bar is needed so you can scroll down to get it to actually load in the web parts.

The issue was actually caused by the content editor web parts (out of the box).

Our client has now opted to not use the modern view experience because of how difficult branding it was.

I'll repeat again, the preferred way to fix this would be an option to disable this functionality at the site level so that if it interferes with branding it can be fully disabled.

[AJIXuMuK]

@SPDEVGUY thanks!
Could you explain what you mean under out of the box content editor web part? There is no OOB content editor for modern SharePoint, community one only.

Only having it as an option on a web part doesnt fix the problem of a scroll bar popping into existence only after everything was loaded, especially when that scroll bar is needed so you can scroll down to get it to actually load in the web parts.

If we have this option, web part will be loaded even if it's far away in the bottom. And will lead to correct page scroll behavior too.

[SPDEVGUY]

The regular text / html entry one. Whatever they've called it in modern these days, it allows you to put in content. I think there was also a picture viewer one as well which was the issue because the image would load in only after it scrolled. Kevin Cole | SharePoint MCM 780.271.2171

…

________________________________ From: Alex Terentiev ***@***.***> Sent: Tuesday, April 26, 2022 8:55:08 AM To: SharePoint/sp-dev-docs ***@***.***> Cc: Kevin Cole ***@***.***>; Mention ***@***.***> Subject: Re: [SharePoint/sp-dev-docs] Lazy Loading of the Web Parts (Discussion #7918) @SPDEVGUY<https://github.com/SPDEVGUY> thanks! Could you explain what you mean under out of the box content editor web part? There is no OOB content editor for modern SharePoint, community one only. Only having it as an option on a web part doesnt fix the problem of a scroll bar popping into existence only after everything was loaded, especially when that scroll bar is needed so you can scroll down to get it to actually load in the web parts. If we have this option, web part will be loaded even if it's far away in the bottom. And will lead to correct page scroll behavior too. — Reply to this email directly, view it on GitHub<#7918 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYPH7FSMVU33XDYS6JEHBDVG77UZANCNFSM5UJ4R7WQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[StfBauer]

If you refer to loading="lazy" - This only works for the following two tags:

• img
• iframe

[AJIXuMuK]

@SPDEVGUY - what if this option is available not only in a manifest, but in property pane as well, and for 1p web parts?
You can still specify default behavior in the manifest, but the it can be overridden for the specific page if needed.

[salascz]

@AJIXuMuK: from my point of view, it would be great if the configuration might be overridden from property pane..

One example: Our company use "PnP Modern Script Editor" WebPart (https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples/react-script-editor). It is used heavily by our users. => It might be useful to disable laze load for some cases, but it seem to be unnecessary to force this behaviour generally...

[SPDEVGUY]

I wish I could show you an example, but this was months ago now. I need an option to turn this whole functionality off, for all content. In some instances it is not helpful, and having it only on all the time with no ability to disable it globally is a problem. Kevin Cole | SharePoint MCM 780.271.2171

…

________________________________ From: Stefan Bauer ***@***.***> Sent: Tuesday, April 26, 2022 9:44:33 AM To: SharePoint/sp-dev-docs ***@***.***> Cc: Kevin Cole ***@***.***>; Mention ***@***.***> Subject: Re: [SharePoint/sp-dev-docs] Lazy Loading of the Web Parts (Discussion #7918) If you refer to loading="lazy" - This only works for the following two tags: * img * iframe — Reply to this email directly, view it on GitHub<#7918 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYPH7AAP5BXSCSDATJCXK3VHAFODANCNFSM5UJ4R7WQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[edarroudi]

I think having a property on the property pane would be awesome. For control measures we could probably use PowerShell Scripts to update all Webparts to enable/disable the setting on the page.
Best solution would be to have it at page level, but property pane setting will override the behaviour. This will make it easier to maintain the sites but still give everyone some options to optimize performance.

It would probably be better (but more complex) to not use a boolean but an enum like :
DisableLazy | DisableLazyRender | EnableLazy
DisableLazy : webpart will be initialized and rendered
DisableLazyRender: webpart will be initialized (is available with manifest/property data for other connected webparts) but won't run the render sequence
EnableLazy: normal lazy loading currently implemented

[AJIXuMuK]

Thank you for the feedback @edarroudi

[ryanexner]

Just another thought, can this be handled via a URL parameter? It would be helpful to maintain lazy loading when we don't need to scroll to page. As mentioned in the previously, anchor parameters (#) do not work when you have to do a redirect for authentication or other reasons.

[addmitt]

disableDeferLoading would be fine for me, I just want the darn Page Sections Navigation web part to work >_<

[heinrich-ulbricht]

A thought about who will be able to configure and see/modify those lazy loading settings: Technical users (PowerShell, which permission required?)? All users (Browser UI)? Making this setting partially available to only one of those groups might be confusing.

But however the solution will look: when analyzing (poor) page performance everybody should be able to easily check the settings, however they were set. Thinking about the Page Diagnostics extension here: https://chrome.google.com/webstore/detail/page-diagnostics-for-shar/inahogkhlkbkjkkaleonemeijihmfagi?hl=en - it could/should show what's configured.

Goal: if an end user complains about poor performance one should be able to easily diagnose if disabled lazy loading is the cause. (Already hearing the phone ring...)

[SPDEVGUY]

Ideally it would be something that can be influenced by powershell script (spweb property). Also, keep in mind this is an on-prem sp modern need as well. In our specific scenario we needed a way to disable the functionality for all pages as part of the branding strategy as it could occur on any page within the site after the user had populated a page with content. Kevin Cole | SharePoint MCM 780.271.2171

…

________________________________ From: Alex Terentiev ***@***.***> Sent: Wednesday, April 27, 2022 7:37:28 AM To: SharePoint/sp-dev-docs ***@***.***> Cc: Kevin Cole ***@***.***>; Mention ***@***.***> Subject: Re: [SharePoint/sp-dev-docs] Lazy Loading of the Web Parts (Discussion #7918) @SPDEVGUY<https://github.com/SPDEVGUY> - what if this option is available not only in a manifest, but in property pane as well, and for 1p web parts? You can still specify default behavior in the manifest, but the it can be overridden for the specific page if needed. — Reply to this email directly, view it on GitHub<#7918 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYPH7FU2CE6DQOZZHAIKLTVHE7JRANCNFSM5UJ4R7WQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[AJIXuMuK]

Updating the thread:
The changes were implemented and will be rolled out in the next couple of weeks.

At the end we were able to just "make it work".
If a component (read - web part, or any part of it) is registered as a data source, it will be excluded from the lazy loading logic.

[vishalshitole]

@AJIXuMuK What happened to implementation of disableDeferLoading property? Has it been canceled or in progress?

Is registering web part as dynamic data source the only way to disable lazy loading?

My custom web part is a simple Accordion web part which does not need to be a dynamic data source with overheads implementing IDynamicDataCallables and its methods. I want my web part users to copy an anchor link for a particular accordion item and use that link as a reference, so that when other users navigates to that link they should be taken/scrolled directly to the appropriate accordion item irrespective of the position of Accordion web part on a page.

I came across using # workaround in the page url to force load all web parts on the page as mentioned by some in this thread #6091, but it has some limitations as well.

Please suggest. Thanks in advance!

[AJIXuMuK]

@vishalshitole - unfortunately, we will not implement disableDeferLoading as a separate property. Our initial aim was to allow dynamic data web parts to behave correctly with lazy loading.

[vishalshitole]

@AJIXuMuK So what do you suggest me for the scenario I have mentioned above? Is it # workaround which I need to implement ultimately?

[AJIXuMuK]

@vishalshitole - as your scenario is a plain "anchor" scenario - yeah, # in the query string is what you need.

[corriespondent]

@AJIXuMuK I'm in the unfortunate scenario where we are using SPFx web parts in SP server 2019, so the lazy loading happens but there is no way in SPFx v1.4 to disable it or set up dynamic data web parts. Any suggestions for how we can resolve this? We have a web part that acts as jump navigation to anchors within custom web parts further down on the page; it's no longer working because of lazy loading.

[wobba]

@AJIXuMuK how are you checking if a web part registers as a source? Scanning the code? I'm trying to add an option to allow or disallow dynamic data, using if statements to invoke the registration code - but this seems not to work.

Is what I'm trying to solve possible? For cases where the PnP Modern Search web part is used as roll-up, not having any data connections, then allowing it to be lazy loaded would be beneficial.

[AJIXuMuK]

@wobba - when a web part registers as a source, we place in in the sources map that contains all the sources on the page.
However, for the "in viewport" scenario - the web part should register itself as a source during the edit session. in that case it should be loaded on the page, no matter if it is in a viewport or no.

[wobba]

Thank you @AJIXuMuK. I worked around it by having two preconfigured entries of the web part. One where dynamic data is allowed, and one where it is not - then checking on that property in the code.

[Aymkdn]

@AJIXuMuK I'm trying to define my webpart as a data source. I'm using this.context.dynamicDataSourceManager.initializeSource(this) in onInit(), and also implementing the different related methods, but my web part is not loaded until I scroll to it (lazy loading). How do you check if a web part is a data source? How can I verify if my web part will be seen as a data source?

Before you said:

the web part should register itself as a source during the edit session

Can you explain this part?

[Aymkdn]

Ah, I think I understand. We need to edit the page, there the initializeSource is called, then republish, and this time the web part will be loaded!