Code-splitting (lazy loading) or server rendering?

Question

React

Why such a radical choice? Here . Quote:

We've tried and failed a couple of times
...
We determined that google was indexing our sites well enough for our needs without server rendering, so we dropped it in favor of code-splitting + service worker caching.

Free translation:

We tried to make friends between server-rendering and lazy-loading, and nothing came of it ....
We spit on it because Google indexes our sites normally even without server-rendering. And from these two things that are difficult to get along with each other, they chose code separation with caching.

Features of Russian realities - most of the traffic from Yandex - and some other considerations do not allow me to abandon server rendering. But I can refuse the universality of the code, while even retaining most of the common React templates for the server and the front.
But I can't decide which is the greater evil:
1) Use "isomorphism" and force the user to download a huge JS bundle with the entire application once:
+ The bundle will be cached and in the future it will either not be loaded at all, or it will be loaded from the browser cache
+ "Isomorphic" the code will not render the entire UI on initialization, but will just link the virtual DOM and the real
one - The user will have to load a VERY large bundle with modules, which they probably won't need at all
2) Abandon "isomorphism", just render the code on the server, and then replace it on the front with the application code:
+ You can split the bundle into many small modules and load only those that the user needs at the moment
- The markup rendered on the server will be replaced by React on the front after loading, however, once, then it connects its routing and works without the participation of the server
. In both cases, thanks to server rendering, the user will see the interface during loading and even be able to interact with it in no-javascript mode.
I would like to hear opinions and arguments, perhaps alternative solutions.

Answer 1

Why is it an either/or question? I get along quite well with dynamic imports ( import(moduleName) ) - this is the basis for code-splitting. It turns out very well: the server returns HTML (you can even push the styles necessary for the requested page separately into the head), which is immediately rendered by the browser, at the same time the main module (application core) is asynchronously loaded and chunks (modules) are preloaded. Comes out fast and great.