spfx web parts not rendered on page load until scrolled to

%3CLINGO-SUB%20id%3D%22lingo-sub-1513663%22%20slang%3D%22en-US%22%3Espfx%20web%20parts%20not%20rendered%20on%20page%20load%20until%20scrolled%20to%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1513663%22%20slang%3D%22en-US%22%3E%3CP%3EI%20have%20custom%20spfx%20web%20parts%20located%20at%20various%20locations%20in%20a%20long%20site%20page.%20I%20notice%20that%20these%20web%20parts%20are%20rendered%20only%20when%20user%20scrolls%20down%20the%20page%20and%20upon%20nearly%20reaching%20the%20viewport%20does%20the%20web%20part%20code%20fires.%20Is%20this%20some%20sort%20of%20page%20optimization%2C%20so%20that%20wayward%20web%20parts%20do%20not%20cause%20any%20page%20to%20load%20slowly%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20custom%20dynamic%20web%20parts%20for%20page%20navigation%20that%20depends%20on%20all%20the%20web%20parts%20being%20loaded%20upon%20page%20load.%20The%20web%20part%20at%20the%20top%20of%20the%20page%20needs%20the%20anchor%20links%20of%20web%20parts%20at%20the%20bottom%20of%20the%20page%20to%20be%20displayed%2C%20so%20this%20issue%20is%20causing%20the%20custom%20navigation%20bar%20to%20not%20display%20all%20the%20anchor%20links.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20used%20to%20work%20some%20months%20ago%2C%20but%20now%20it%20doesn't.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1514612%22%20slang%3D%22en-US%22%3ERe%3A%20spfx%20web%20parts%20not%20rendered%20on%20page%20load%20until%20scrolled%20to%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1514612%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F705329%22%20target%3D%22_blank%22%3E%40stchiew%3C%2FA%3E%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EYou're%20right.%20This%20is%20default%20behavior%20for%20modern%20pages%20in%20SharePoint.%20Maybe%20it%20was%20working%20before%20because%20your%20page%20was%20not%20long%20enough%20to%20not%20load%20some%20webparts%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can%20see%20how%20that%20would%20be%20a%20problem%20for%20you%2C%20though.%20What%20you%20could%20do%20is%20group%20your%20webparts%20together%20inside%20a%20big%20webpart.%20I've%20done%20that%20for%20other%20reasons%20but%20surely%20it%20would%20to%20solve%20your%20problem%2C%20too.%20Or%20you%20could%20change%20the%20logic%20of%20your%20custom%20nav.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ELet%20me%20know%20if%20you%20need%20any%20help.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1517815%22%20slang%3D%22en-US%22%3ERe%3A%20spfx%20web%20parts%20not%20rendered%20on%20page%20load%20until%20scrolled%20to%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1517815%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F365643%22%20target%3D%22_blank%22%3E%40Carlos_Marins%3C%2FA%3E%26nbsp%3Bthanks%20for%20your%20reply!%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI'm%20pretty%20sure%20it%20worked%20earlier%20this%20year%20with%20some%20very%20long%20pages.%20Actually%20this%20is%20the%20web%20part%20solution%20I%20am%20trying%20to%20implement%20from%20the%20spfx%20PnP%20Sample%20repos%26nbsp%3B%3CA%20title%3D%22react-page-sections-navigation%22%20href%3D%22https%3A%2F%2Fgithub.com%2Fpnp%2Fsp-dev-fx-webparts%2Ftree%2Fmaster%2Fsamples%2Freact-page-sections-navigation%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ereact-page-sections-navigation%3C%2FA%3E%26nbsp%3B%2C%20so%20it%20really%20depends%20on%20all%20subsequent%20web%20parts%20to%20be%20loaded%20and%20registered%20as%20a%20data%20source%20before%20the%20top%20navigation%20displays%20all%20links.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20did%20some%20more%20testing%2C%20with%20the%20standard%20Hello%20World%20web%20part%20at%20the%20bottom%20of%20a%20simple%20modern%20page%20with%20many%20OOTB%20webparts%2C%20both%20in%20a%20Targeted%20Release%20tenant%20and%20a%20Standard%20Release%20tenant%20and%20got%20different%20results!%20Seems%20in%20targeted%20release%20the%20web%20part%20is%20loaded%20in%20full%20on%20page%20load%2C%20while%20in%20the%20latter%20release%20it%20doesn't.%20So%20my%20web%20part%20works%20in%20target%20but%20not%20in%20standard.%20Below%20are%20snapshots%20from%20browser%20dev%20tools%2C%20upon%20page%20load%20without%20scrolling.%20(Hoping%20these%20changes%20will%20be%20rolled%20out%20to%20standard%20release%20tenants%20soon)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EStandard%20Release%20-%20there's%20a%20div%20data-viewport-id%2C%20but%20the%20rest%20of%20the%20webpart%20is%20not%20rendered.%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22StandardRelease_Helloworld.JPG%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F204956iB1389E8CB089E157%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22StandardRelease_Helloworld.JPG%22%20alt%3D%22StandardRelease_Helloworld.JPG%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ETarget%20release%20tenant%20-%20the%20WP%20is%20rendered%20without%20scrolling%2C%20without%20the%20div%20data-viewport-id%20tag%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22TargetedRelease_Helloworld.JPG%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F204957i7B244BCBB55F9534%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22TargetedRelease_Helloworld.JPG%22%20alt%3D%22TargetedRelease_Helloworld.JPG%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1585446%22%20slang%3D%22en-US%22%3ERe%3A%20spfx%20web%20parts%20not%20rendered%20on%20page%20load%20until%20scrolled%20to%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1585446%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F705329%22%20target%3D%22_blank%22%3E%40stchiew%3C%2FA%3E%26nbsp%3B-%20I%20do%20have%20the%20same%20issue.%20Few%20of%20the%20custom%20components%20which%20replied%20on%20webpart%20on%20the%20page%20doesnt%20work%20anymore%20until%20I%20scroll%20the%20page%20to%20bottom.%26nbsp%3B%3C%2FP%3E%3CP%3E%3Ca%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F41501%22%3E%40microsoft%3C%2Fa%3E%20-%20Is%20this%20a%20bug%20or%20a%20page%20behavior%20change%3F%20Can%20we%20override%20this%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Occasional Contributor

I have custom spfx web parts located at various locations in a long site page. I notice that these web parts are rendered only when user scrolls down the page and upon nearly reaching the viewport does the web part code fires. Is this some sort of page optimization, so that wayward web parts do not cause any page to load slowly?

 

I have custom dynamic web parts for page navigation that depends on all the web parts being loaded upon page load. The web part at the top of the page needs the anchor links of web parts at the bottom of the page to be displayed, so this issue is causing the custom navigation bar to not display all the anchor links.

 

This used to work some months ago, but now it doesn't.

3 Replies
Highlighted

Hi @stchiew,

 

You're right. This is default behavior for modern pages in SharePoint. Maybe it was working before because your page was not long enough to not load some webparts?

 

I can see how that would be a problem for you, though. What you could do is group your webparts together inside a big webpart. I've done that for other reasons but surely it would to solve your problem, too. Or you could change the logic of your custom nav.

 

Let me know if you need any help.

Highlighted

@Carlos_Marins thanks for your reply!

 

I'm pretty sure it worked earlier this year with some very long pages. Actually this is the web part solution I am trying to implement from the spfx PnP Sample repos react-page-sections-navigation , so it really depends on all subsequent web parts to be loaded and registered as a data source before the top navigation displays all links.

 

I did some more testing, with the standard Hello World web part at the bottom of a simple modern page with many OOTB webparts, both in a Targeted Release tenant and a Standard Release tenant and got different results! Seems in targeted release the web part is loaded in full on page load, while in the latter release it doesn't. So my web part works in target but not in standard. Below are snapshots from browser dev tools, upon page load without scrolling. (Hoping these changes will be rolled out to standard release tenants soon)

 

Standard Release - there's a div data-viewport-id, but the rest of the webpart is not rendered.

StandardRelease_Helloworld.JPG

 

Target release tenant - the WP is rendered without scrolling, without the div data-viewport-id tag

TargetedRelease_Helloworld.JPG

Highlighted

@stchiew - I do have the same issue. Few of the custom components which replied on webpart on the page doesnt work anymore until I scroll the page to bottom. 

@microsoft - Is this a bug or a page behavior change? Can we override this?