0

Are there chunk size / loading time implications in choosing between:

  • Splitting a client side application into multiple bundles and serving them across different html pages (i.e. server side routing /about => about.html => about.bundle.js, etc) (this doesn't mean code splitting can't still be used on sub pages, e.g. admin/dashboard, admin/reports).

  • Serving a single client side application that uses code splitting across client-side routes.

And would the significance of chunk size / loading time most likely be eclipsed by architectural considerations such as:

  • The need/desire to share/isolate state across different routes

  • Overhead of abstracting app initialization code so that it can run in each bundle vs possibility to optimise initialization code per app bundle.

?

In general, why would you choose one approach over the other?

Note: Many resources like survivejs discuss bundle splitting and code splitting, saying that the former is a less granular version of the latter. However, it is not clear when you might need to split bundles as opposed to just using code splitting, especially when you have the possibility to split those bundles across separate html pages.

Dan
  • 2,830
  • 19
  • 37
  • Split the bundles if they are getting big enough that they are impacting page load (download and/or parse time). That has little to do with code-splitting, though code-splitting likely helps prevent the need for bundle-splitting, though certainly not all the time. – Matthew Herbst Feb 01 '19 at 23:30
  • Thanks Matthew, that's sort of what I'm trying to understand though: what is the difference between a large application that has one bundle that's code-split vs smaller applications? When would code splitting **not** prevent the need for bundle splitting? That is essentially my question. – Dan Feb 01 '19 at 23:43
  • Code-splitting is for when the app can handle the code needed for additional functionality being loaded a bit later (asynchronously). If your app needs all the code to run immediately, then you can't code split. If you can say, only load the chat code when the user goes into the chat screen, then you could code-split out the chat code. If you do enough code-splitting (if you build your app to support it), then you'll have lots of tiny bundles and you'll not need to do any additional bundle splitting. – Matthew Herbst Feb 01 '19 at 23:46
  • Awesome, you're helping fill in the picture here. So in the context of the question I've asked, where obviously the about page is not needed when loading the admin page for example, is there any difference between bundle splitting per page and code splitting per route? I.e. routing is an obvious natural boundary for code-splitting and bundle splitting, so why choose one or the other? – Dan Feb 02 '19 at 00:05
  • 1
    There could be a difference if the two pages have any shared code (ex, 3rd party libraries), in which case it might make sense to bundle split that code out depending on how much of it there is. That way that code can be easily cached by the client for future re-use. It would make say, loading the about page slightly slower since there's an additional network call (though that's becoming less true with HTTP 2.0), but would increase the future loading of the admin page since the 3rd party code would already be cached. If you need serious performance, you should probably be doing both. – Matthew Herbst Feb 02 '19 at 00:18
  • Wait, but a lazy loaded portion of the app doesn't re-import 3rd party code (e.g. React) does it? Presumably it just imports any 3rd party code specific to it. So if (code split case) about isn't using redux, and then we visit admin which is, then redux will be included with admin. But if pages mostly shared same 3rd party code, then bundle splitting doesn't help much, since it'll all be in the main initial chunk. Ok, thanks! Think I'm getting a better conceptual handle on the competing concerns here. Splitting bundles is pehaps akin to splitting hairs :D. – Dan Feb 02 '19 at 00:36
  • Right, but if you code-split and the user comes into about in one session, and admin in another session, and you don't bundle split the vendor code out, then the user will have to download the vendor code twice. With bundle splitting the vendor code would be cached after the first session, meaning it wouldn't need to be downloaded again during the second session. Trade-offs :) – Matthew Herbst Feb 02 '19 at 01:26

0 Answers0