@角/料桶进口成本

Question

Using the latest Angular & CLI versions (~6.1.6), and the latest @angular/material library (~6.4.7), I'm finding a pretty significant performance penalty when using an import from @angular/material's primary entry point ( public_api.ts ):

import { MatButtonModule }  from '@angular/material';

If I update the import statement to use the secondary endpoint:

import { MatButtonModule }  from '@angular/material/button';

My vendor bundle is reduced by ~2.6MB, and page render speed decreases by ~200ms.

With @angular/cli 's tree shaking abilities, the ultimate production build size is equivalent with either import statement. As a result, I feel people often favor the development semantics of the terser import statement, not realizing/understanding the dev-time performance penalty.

Why isn't the performance penalty of 3rd party "barrel importing" discussed more? I've had a really hard time finding any documentation on the decision making process and/or performance implications of these choices.

Answer 1

So when you import barrel, webpack will add all exports from the barrel to your bundle.js. When you import a specific file like below

import { MatButtonModule }  from '@angular/material/button';

Will be imported only button file.

But the webpack 2 release came with built-in support for ES2015 modules (alias harmony modules) as well as unused module export detection. The new webpack 4 release expands on this capability with a way to provide hints to the compiler via the "sideEffects" package.json property to denote which files in your project are "pure" and therefore safe to prune if unused.

There are several tips to get rid of "dead code"( imports which included in your bundle but not used)

• Use ES2015 module syntax (ie import and export).
• Add a "sideEffects" property to your project's package.json file.
• Use production mode configuration option to enable various optimizations including minification and tree shaking .