Your best bet is to render the page formalities and structure in a second or two (ethernet time, cell-data time will vary). And then, backfill the data as the data comes up.
Imagine if you reboot the starship Enterprise. There are dozens of displays. They don't all come up at the same time, they flit on, one at a time, depending on how long they take to do their thing. We consider that normal. Also, note that the Enterprise bridge does not spasmodically get larger as workstations insert themselves Harry Potter style between other workstations as they start up. The workstations are always there, just the screens (of fixed size) start filling with data. That's the design concept to go for.
Your user may not even want that data
It's easy to suffer tunnel vision, or "get-there-itis" as the aviators call it. You're presuming everyone who lands on the homepage wants the content you've done all the work on. Good chance not.
- Some want the "About us" page or "How this business/site works" page - they're not ready to convert, and a big computational load to present your wares is wasted.
- Others want directions to your site (think music theatre, they are late to this show, and don't care about ticket availablility for other shows.)
- Others have a question and want to find a way to contact you.
- Etc. etc. Those users are not unimportant.
It's rude to make them wait. It's also suicide to delay; because if the big DB crunch never finishes, that means your site is down. Same if the big DB crunch takes 7 seconds, but they abandon in 6.
You're supposed to reserve space
This new trend they call "skeleton UIs" where you reserve space for the loading content -- it is not a new thing. It's a very old thing, and a very mandatory thing.
The web was going quite strong in 1995 when most people had 33.6kbps modems. You see the
img tag with its
width= attributes? They're not for scaling. The Internet lived or died off of those. That's what made your site usable within a sufferable amount of time. That's what put a gray box with a little "image" icon where your content goes. People were used to this, and really appreciated it. Many set their browser to "don't auto-load images" and clicked to see the ones they wanted.
This didn't render (yet)? No matter. The page could render, and it won't jump.
Mind you in 1995, it was possible to fail to specify
width= parameters, and you would indeed get the sad version of scroll jumping that was possible on a 486 (that's a CPU chip) without a VPU. This only happened on the cheesiest amateur home-cooked web sites. Anyone remember loading a friend's personal travelougue site and having to go get a coffee while his 100 images jerkily loaded?
So this concept of "Don't cause scroll jumping" is nothing new. Don't normalize failure to reserve space for loading content, it's always been a lazy and sloppy way to code.
And yes, that does present design challenges for dynamically loaded content. In fact, that's how that camel-of-indeterminate-size got its nose back in the tent. Lazy sites go "We can't know how large this tweet will be" (I'm gonna guess, less than 140 characters)... good design is working this out.
In the old days, we solved almost any problem like that with an iframe. So it's definitely possible.