Sp-dev-docs: SPFX Web parts not loading on load

[sidjustsid]

We have observed that SPFX web parts functionality got changed in previous two days .
Previously web parts used to load on the first load.
Now the web parts are loading one after the other in the scroll.
Can some one suggest here , is something which has changed in the previous one week?

Any suggestions or answers would be highly appreciated.
Many Thanks

@VesaJuvonen @waldekmastykarz @mcmynn83

[Jordy84]

Same here, some web parts are only available after scrolling down the page. 1px down seems to be enough: document.querySelector('#s4-workspace').scrollTop += 1

Displaying modern web parts on classic site btw

[patmill]

Sorry for the delay - we have been working on optimizations to not fire the load event on webparts that are outside of the viewport in order to speed up page perf. Are you seeing errors when the webpart renders (or that the webpart doesn't render), or just that your onload isn't getting fired until you scroll into view?

[sidjustsid]

@patmill
No there are no errors once the web part is loaded . The issue is the second layer of the page has few web parts. In that scenario until the view port of the web parts which are there in the second layer are loading the web parts are seen blank, this makes the user experience bad. The user will think that there is no data in that particular area. This is happening in few devices only .This wont be an issue with the large screens.

[NickSevens]

@patmill is this something we can override? We have a particular scenario where content is dynamically shown/hidden, causing the web parts to load only after scrolling.
It would be nice if this loading behavior can be changed in some way?

[NickSevens]

Checking if there's some new info? :)

[kmartindale]

any updates with this item? we're also experiencing some user experience confusion.

[Tran-Kien]

I would also like an update on this issue. Is there a way to override it and fire all the load events? Page performance is not as concerning for us at this point. Having half of the page being blank is much more of a concern.

Thanks

[kmartindale]

@UMAknow-Kien we had to write a script that basically jiggles the page up and down a pixel on load. less than ideal at this point but seems to be working for us until we hear word.

[NickSevens]

@UMAknow-Kien @kmartindale same here... added a script to move s4-workspace up and down.

[umaknow-francis]

Hi, this is a real issue for us. On modern pages, we observed these two problems:

• We have several full-width web parts on top of a modern page. They therefore each have there own section (limitation to only a single web part in full-width section apparently). The sections seem to have a long height by themselves on load even if they collapse around the actual rendering of the containing web parts afterward. The effect is that only the first couple of web parts get rendered then collapsed and most the of page appear blank to the end user until they scroll. There is no easy way to add that kind of automatic scroll script in modern pages.

• The other situation is that we have a very long FAQ web part that spans over several pages. A search bar automatically filters it. It seems that the web part gets rendered only after a certain proportion is visible, say 20%, which looks fine for the average web part. But for such a long web part, nothing gets displayed until a good deal of scrolling over a blank page! This completely breaks the user experience.

Is there any way to have more control over this behavior?
@VesaJuvonen @waldekmastykarz @mcmynn83 @patmill

[umaknow-francis]

I managed to inject some script in the modern page, changing the scroll position successfully. However, the effect is simply to load the web parts within the specific viewport that I end in. I tried to scroll at the bottom and back up, but the render seems to happen after that, so it does not change anything. I also tried to scroll at the bottom, wait 5 seconds and go up, but then only what was in the viewport at rendering time has rendered and I ended back to a blank section that did not re-render. Argh!!!

Sample script used:

var canvas = document.getElementById('spPageCanvasContent');
var scrollRegion = canvas.parentElement.parentElement;
//scrollRegion.scrollTop +=300;
//scrollRegion.scrollTop =0;
var millisecondsToWait = 5000;
scrollRegion.scrollTop = canvas.scrollHeight;
setTimeout(function() {    
    scrollRegion.scrollTop = 200;
}, millisecondsToWait);

[dgaeta]

@sidjustsid @umaknow-francis @NickSevens @UMAknow-Kien @Jordy84 are you still experiencing this issue?

[umaknow-francis]

Yes, I did a quick check, but it seems different: the web part are now in a "loading" state, but never loads until I scroll down.

[dgaeta]

@umaknow-francis does it still not load after 30-60 seconds without scroll? (if so, do you see any errors in the console?)

You can send a copy of the logs by pressing Ctrl and F12 and on the "Trace" tab click "Export CSV".

[sidjustsid]

I think the issue is not existing now. MS has just checked this as a test and reverted back.
@patmill Could you please update on this?

[umaknow-francis]

Well, I checked again and definitely see the issue still. Before, it was just blank, but now we see the web part loading forever, yes more than 60 seconds, until I scroll down. See for yourself in this screenshot.

[dgaeta]

@umaknow-francis can you provide the trace logs for that page? (Ctrl and F12, then click on the "Trace" tab, then click "Export CSV")
Also do you see any errors from the browser console?

Just to confirm, you're observing the webpart does not load until you scroll down?

[dgaeta]

@umaknow-francis To add, this perf optimization was turned off (loading only after 20% of webpart is in viewport)

[dgaeta]

Closing as this optimization was removed.

[umaknow-francis]

I confirm that the issue is gone with the "optimization" now removed. Very happy that it works well again!

[robpearmain]

@umaknow-francis how di you remove the optimization as I am experiencing an issue where a webpart is not in the dom until you scroll it in to view

[umaknow-francis]

I did not: Microsoft did it as announced by @dgaeta .
So, as far as I see, either the fix was not deployed to your tenant or you experience a different issue...

[lammy82]

I'm still struggling with this 'optimization' in my tenancy. I have some web parts which are hidden by default and really need them to load so they are available when the user toggles them into view, instead of showing the spinner, which then doesn't disappear until the user additionally scrolls the page.

Has anyone found a reliable way of overriding this functionality? Or do I just need to be patient and wait for the removal of the optimisation to reach my tenancy?

[robpearmain]

Hi @lammy82 . My Tenancy still has this. Although a web part constructs before it is shown, I moved all my initialisation code in to the ComponentDidMount (React) as this fires once it comes in to view if that helps

[kcasamento]

Still experiencing this behavior. Is fix still being rolled out to tenants? Do I need to update the spfx package version to something specific?

[Soumyawrk]

Hello everyone, still facing this issue. On load the below widgets are not getting loaded but just scrolling a bit not even more required really just a small bit loads. Please help how can we overcome this..

[PeteDurst]

Unfortunately we have the same problem.
Please reopen this issue.
What other solutions are there, apart from scrolling?

[HollywoodHiskey]

Still hoping for a fix as well! This issue has a significant impact on user experience and we haven't been able to find a good workaround.

[patmill]

Just to confirm things. Is the problem that webparts don't load, or that they don't load until a small portion (maybe 1 pixel) is in the viewport, or you need a bunch of visibility in the viewport before they load?

Is the desire that the webparts load despite their not being in the viewport as well?

Is there any difference between 1st party and 3rd party webparts? ie, does this happen when you add a random webpart - say a doc viewer?

Thanks.

[PeteDurst]

It is absolutely important for us that the webparts are loaded, even if they are not in viewport and we urgently need a solution or a workaround.

I will check tomorrow how much of a webpart must be visible.

Currently we have this problem with the webparts developed by us.

[patmill]

So, in chatting with some people that own the pages app (the modern page that hosts the webparts), what _should_ be happening is that the webparts in the viewport load first. Once they have finished rendering, we'll start loading webparts outside the viewport - but only after the ones in the viewport have loaded.

I'm going to write a test page and see what those timings look like.

[kcasamento]

We are using jquery tabs on a classic page and can confirm that any tab with an spfx web part exhibits the behavior described above. The web part will stay in a "loading" state until either the screen is resized or if you scroll. I've put debugging code in our onInit method and none of our code even runs until that scroll/resize happens.

[hunterpankey]

I'm seeing this issue, too. Using a publishing site, my web part that gets positioned about 60% on screen and 40% below the fold doesn't render until the user either scrolls the web part entirely into the viewport, or resizes the browser window. I really need a resolution to this before I can go live with this project. It won't do to have big open rectangles on half of my screen when the page loads.

[javed74]

I am facing same issue as well. I am using bootstrap Tab interface (all CSS) where each tab content is Webpart Zone with SPFX component. On page load the visible Tab component loads fine but when I navigate to another tab, component shows "Loading ....." message until manually resize browser window. Is there any other solution, instead of resizing window?

[TietjeDK]

We experience a similar issue when user enters the page where webpart is located via a link in an email. It seems like the webpart isn't fully loading every time, which impacts the user experience in a bad way, and is nightmare to debug. Please advice.

[n00el]

It's brilliant how they burying they head in the sand ... SPFX 2019, the problem is still there in 2020, the issue is closed. It's a nightmare, thanks sharepoint team.

[VesaJuvonen]

@n00el - as this issue is closed, it's not unfortunately visible in any internal systems, which makes us really hard to help you. If this is still an issue for you, can you please open up a new issue, so that we can help you to resolve this. Thanks for the details advance.

Happy to not to bury anything on the sand, but we need to be aware of the issues, so that we can help, so looking forward on the new issue from you. Thanks.