It's 2019! Everybody thinks they know code splitting. So - let's double check!  In short – code splitting is just about not loading a whole thing. Then you are reading this page you don't have to load a whole site. When you are selecting a single row from a database – you don't have to take all.
Obvious? Code splitting is also quite obvious, just not about your data, but your code. React.lazy? No – it only uses it. Code splitting is being done on a bundler level – webpack, parcel, or just your file system in case on "native" esm modules. Code splitting is just files, files you can load somewhere "later". So — to the questions "What is powering code splitting?" — the answer is — a "bundler". React.lazy is using. Just using code splitting of your bundler. Just calling import when got rendered. And that's all. React.lazy superseded it. And provided more features, like Suspense to control loading state. So - use React.Lazy instead.  Well. There are a few grey zones about React.lazy and code splitting I forgot to mention. It's not easy to test React.lazy due to its asynchroniosity. It would be just "empty", as long as it is not loaded yet(even if it is) – Promises and import returns, and lazy accepts, promises, which always got executed in the next tick. Proposed solution? You would not believe, but the proposed solution is to use synchronous thenables — See pull request. So — lets make our imports SYNCHRONOUS!!! (to fix lazy issue for the tests, or any other server side case) It's not hard to convert import function to a memoized synchronous thenable. React.lazy is SSR friendly. But it requires Suspense to work, and Suspense is NOT server side friendly. There are 2 solutions: This is a good option, but it would be not quite client side friendly. Why? Let's define the 2th possible solution: It's easy – not react-loadable – it's heavy unmaintained and obsolete, even if it is still mega popular. (and thank you for popularizing code splitting, yet again) Loadable-components – might be a very good choice. It is very well written, actively maintained and support everything out of the box. Support "full dynamic imports", allowing you to import files depending on the props given, but thus untypable. Supports Suspense, so could replace React.lazy. Universal-component – actually "inventors" of full dynamic imports – they implemented it in Webpack. And many other things at low level – they did it. I would say – this library is a bit hardcore, and a bit less user friendly. Loadable-components documentation is unbeatable. It's worth if not to use this library, then read documentation - there are so many details you should know… React-imported-component – is a bit odd. It's bundler independent, so it would never break (there is nothing to break), would work with Webpack 5 and 55, but that comes with a cost. While previous libraries during SSR would add all the used scripts to the page body, and you will be able to load all the scripts in a parallel – imported don't know files names, and will call the original "imports"(that's why bundle independent) to load used chunks, but able to make call only from inside the main bundle – so all additional scripts would be loaded only after the main one got downloaded and executed. Does not support full dynamic imports, like React.lazy, and, as a result – typeable. Also supports Suspense. Uses synchronous thenables on SSR. It also has an absolutely different approach for CSS, and perfect stream rendering support. There is no difference in quality or popularity between listed libraries, and we are all good friends – so pick by your heart. SSR is a good thing, but, you know, hard. Small projects might want to have a SSR – there are a lot of reasons to have it – but they might not want to setup and maintain it. So the easiest my solution for SSR, especially for simple SPA would be prerendering. Like opening your SPA in a browser and hitting "Save" button. Like: Prerendering is "SSR" without "Server". It's SSR using a Client. Magic! And working out of the box… … … but not for code spitting.
So - you just rendered your page in a browser, saved HTML, and asked to load the same stuff. But Server Side Specific Code (to collect all used chunks) was not used, cos THERE IS NO SERVER!  In the previous part, I've pointed to libraries which are bound to webpack in terms of collecting information about used chunks - they could not handle hybrid render at all. React-imported-component could handle this case, as long as it is not bound to the bundler/side, so there is no difference for SSR or Hybrid, but only for react-snap, as long as it support "state hydration", while rendertron does not. And here you have to use another solution, which is just perpendicular to all other libraries. This library was created for partial hydration, and could partially rehydrate your app, keeping the rest still de-hydrated. And it works for SSR and Hybrid renderers without any difference.
The idea is simple: There is another article about this technology, you might read. But main here — it solves "Flash Of Unloaded Content" in another, not a common for code splitting libraries way. Be open for a new solutions.  javascript, webgl, maps, react, орфография(нет)