Angular Should I use the vendorChunk in production

Question

I am using Angular6 and I was wondering if it was better to set "vendorChunk" to true or false in production. I know what it does, but I am not sure of the best value to use in production.

Viyella

Answer 1

It depends on your use case.

The advantage of not having a separate vendor chunk is that you'll be able to get a smaller bundle size. How much smaller depends on your app. I suggest trying a build with and without the flag to see if there is a significant difference.

On the other hand, the main advantage of having vendorChunk enabled is that the users will be able to only download the changed client code without the third party code(Which are less likely to be changed often).

In summary:

Set vendorChunk to true if:

• You plan on updating the client code often without changing much of the third party libraries.

Set vendorChunk to false if:

• There is a significant bundle size reduction by doing so
• OR You are unlikely to change client code frequently

Phototransistor

Quick question, why does not separating the vendor chunk make the bundle size smaller? – Brasilein

can we add: Set vendorChunk to false if: - Bundle almost only consists of own code ( small number of third party libs) ? ( not sure about the sentence structure...) – Merta

@Brasilein Separating the vendor makes the code bigger, not smaller, I believe you misread. The reason is that code can be compiled better if some libraries (in the main.js and vendor.js) are present only once in the code. – A

Answer 2

I was searching by the same question, and in Angular docs https://angular.io/cli/build, says that option should only for dev.

Insensible

Answer 3

Devs say that in production vendor.js will "often get different vendor chunk hash even when changing application code only". Thus looks like there is no much use for vendorChunk=true in production. (Can't check it though)

But I've just checked budle sizes for our production app, for vendorChunk=false
main.js (1'996'389 bytes)

For vendorChunk=true
main.js (193'223 bytes) + vendor.js (1'804'540 bytes) = 1'997'763 bytes

We win 1374 bytes, that is nothing, but could depend on app of course. As for me I think its better to stick to default behavior. (true for dev, false for prod)

Sacred

I think that you only get a different hash if you change the imported modules of the application affecting the tree shaking output which changes the vendorChunk size. – Sayette

Answer 4

In short, that depends.

If your website is visited once per person it's probably best to not have it since the benefit comes from caching the vendor chunk.

You can more or less swap the question for these

• "Are your users repeat visitors?" (yes => turn on)
• "Is the first time users also first class citizens of your app?" (yes => turn off)

Here are some examples:

1. Let's say you have a website that is visited once a week and you do weekly updates. Making the user's download all of your node_modules every time is probably an overkill, so you put it into a vendor.[hash].js with cache-control: <around a year> so if the browser can use the one it already downloaded instead.

2. If you have an app that's about converting single clicks to sales in one go. Then having them download a single main.[hash].js file is usually faster load time.

So it depends, there are benefits to both, and that's why it's an option.

Clump

Answer 5

A good edge case that I faced on my company could be using multiple Angular components in an app that makes heavy use of microfrontends with different frameworks.

For example, suppose that you need Angular components in a React App. If you use more than one Angular component in such scenario, a separate vendorChunk could be loaded only once for all the used components that depends on the same modules.

This will improve load time, since each component just need to load its mainChunk to working accordingly.

Sayette