Bundle size analysis in Angular - Step-by-Step Execution

Concept Flow - Bundle size analysis

Start Angular Build

↓

Build Produces Bundle Files

↓

Run Bundle Analyzer Tool

↓

Analyze Bundle Contents

↓

Identify Large Modules

↓

Optimize Code (Lazy Loading, Tree Shaking)

↓

Rebuild and Re-Analyze

↓

Repeat Until Bundle Size Acceptable

This flow shows how Angular builds bundles, analyzes their size, identifies large parts, optimizes, and repeats to reduce bundle size.

Execution Sample

Angular

ng build --prod --stats-json
npx source-map-explorer dist/main.js
// Analyze output and optimize

Build Angular app with stats, then use source-map-explorer to see bundle size details.

Execution Table

Step	Action	Input/Tool	Output/Result
1	Run Angular production build	ng build --prod --stats-json	Generates dist folder with bundles and stats.json
2	Run bundle analyzer	npx source-map-explorer dist/main.js	Visual report showing sizes of modules in main.js
3	Review report	Report with module sizes	Identify large modules like Angular core, third-party libs
4	Apply optimizations	Lazy loading, tree shaking, code splitting	Smaller bundle size after rebuild
5	Rebuild app	ng build --prod --stats-json	New bundles with reduced size
6	Re-run analyzer	npx source-map-explorer dist/main.js	Updated report showing size improvements
7	Repeat if needed	Analyze and optimize	Bundle size meets performance goals

💡 Stop when bundle size is optimized and meets performance targets

Variable Tracker

Variable	Start	After Step 4	After Step 5	Final
Bundle Size (MB)	10.5	7.2	6.8	6.8
Large Modules Count	5	3	3	3
Lazy Loaded Modules	0	2	2	2

Key Moments - 3 Insights

Why does the bundle size not reduce immediately after the first build?

The first build creates the bundles and stats.json but no optimizations are applied yet. See execution_table step 1 and 2 where analysis happens after build.

How does lazy loading affect the bundle size?

Lazy loading splits code into separate bundles loaded on demand, reducing initial bundle size. This is shown in variable_tracker where Lazy Loaded Modules increase after step 4.

Why run the analyzer multiple times?

Each time you optimize and rebuild, you run the analyzer again to verify improvements. This loop is shown in execution_table steps 6 and 7.

Visual Quiz - 3 Questions

Look at the execution_table, what tool is used to analyze the bundle size?

A webpack-dev-server

B ng serve

C source-map-explorer

D npm install

💡 Hint

Check execution_table step 2 for the tool used to analyze bundles.

According to variable_tracker, what happens to the bundle size after applying optimizations?

A It increases

B It decreases

C It stays the same

D It becomes zero

💡 Hint

Look at Bundle Size (MB) values from Start to After Step 5 in variable_tracker.

At which step in execution_table do you identify large modules?

A Step 3

B Step 1

C Step 5

D Step 7

💡 Hint

Step 3 in execution_table shows reviewing the report to identify large modules.

Concept Snapshot

Angular Bundle Size Analysis:
- Build with 'ng build --prod --stats-json' to get bundles and stats
- Use 'source-map-explorer' to visualize bundle contents
- Identify large modules and optimize with lazy loading and tree shaking
- Rebuild and re-analyze until bundle size is acceptable
- Repeat to keep app fast and small

Full Transcript

Bundle size analysis in Angular starts by building the app with production settings and generating a stats file. Then, a tool like source-map-explorer is run to visualize the sizes of different modules inside the bundle. This helps identify which parts of the code or libraries are large. Developers then apply optimizations such as lazy loading modules and tree shaking unused code. After rebuilding, the analysis is repeated to check if the bundle size has decreased. This process repeats until the bundle size is optimized for better app performance.

Practice

1. What is the main purpose of bundle size analysis in Angular applications?

easy

A. To change the app's color scheme

B. To add more features to the Angular app

C. To find which parts of the app make the bundle large

D. To increase the app's loading time

Solution

1. Step 1: Understand bundle size analysis goal

   Bundle size analysis helps identify what parts of the app increase the size of the final build.

2. Step 2: Match purpose with options

   Only To find which parts of the app make the bundle large correctly states the purpose as finding large parts in the bundle.

3. Final Answer:

   To find which parts of the app make the bundle large -> Option C

4. Quick Check:

   Bundle size analysis = find large parts [OK]

Hint: Think: Why check bundle size? To find big parts [OK]

Common Mistakes:

• Confusing bundle size analysis with adding features
• Thinking it changes app appearance
• Assuming it slows down the app

2. Which Angular CLI command generates a JSON file useful for bundle size analysis?

easy

A. ng build --stats-json

B. ng serve --stats-json

C. ng test --stats-json

D. ng lint --stats-json

Solution

1. Step 1: Recall Angular CLI commands for building

   The command to build the app and generate stats is ng build --stats-json.

2. Step 2: Identify correct option

   ng build --stats-json matches the correct command to create the JSON file for bundle analysis.

3. Final Answer:

   ng build --stats-json -> Option A

4. Quick Check:

   Build with stats JSON = ng build --stats-json [OK]

Hint: Build command with --stats-json creates analysis file [OK]

Common Mistakes:

• Using ng serve instead of ng build
• Confusing test or lint commands with build
• Forgetting to add --stats-json flag

3. After running ng build --stats-json, you use source-map-explorer on the generated JSON. What will you see?

medium

A. A list of unused CSS styles

B. A list of errors in your Angular code

C. A report of unit test results

D. A visual map showing which files contribute most to bundle size

Solution

1. Step 1: Understand what source-map-explorer does

   This tool shows a visual breakdown of the bundle, highlighting file sizes.

2. Step 2: Match output with options

   A visual map showing which files contribute most to bundle size correctly describes the visual map of file size contributions.

3. Final Answer:

   A visual map showing which files contribute most to bundle size -> Option D

4. Quick Check:

   source-map-explorer output = visual size map [OK]

Hint: source-map-explorer shows visual file size map [OK]

Common Mistakes:

• Thinking it shows code errors
• Confusing with test reports
• Expecting CSS style reports

4. You ran ng build --stats-json but source-map-explorer shows no data. What is the likely cause?

medium

A. You did not generate the stats JSON file during build

B. You forgot to install source-map-explorer globally

C. You ran ng serve instead of ng build

D. Your Angular app has no components

Solution

1. Step 1: Check if stats JSON file was created

   source-map-explorer needs the stats JSON file generated by ng build --stats-json.

2. Step 2: Identify missing stats JSON as cause

   If the file is missing, source-map-explorer shows no data. This matches You did not generate the stats JSON file during build.

3. Final Answer:

   You did not generate the stats JSON file during build -> Option A

4. Quick Check:

   No stats JSON = no data in explorer [OK]

Hint: Check if stats JSON file exists before using explorer [OK]

Common Mistakes:

• Assuming source-map-explorer must be global
• Confusing ng serve with ng build
• Thinking app components affect stats generation

5. You notice your Angular bundle is very large. Which combination of actions will best reduce the bundle size?

hard

A. Disable Ahead-of-Time compilation and enable source maps

B. Use lazy loading for modules and remove unused imports

C. Add more third-party libraries and increase polyfills

D. Increase the number of components and services

Solution

1. Step 1: Identify techniques to reduce bundle size

   Lazy loading loads modules only when needed, and removing unused imports cuts unnecessary code.

2. Step 2: Evaluate options for reducing size

   Use lazy loading for modules and remove unused imports correctly combines these effective methods. Other options add size or disable optimizations.

3. Final Answer:

   Use lazy loading for modules and remove unused imports -> Option B

4. Quick Check:

   Lazy loading + clean imports = smaller bundle [OK]

Hint: Lazy load and clean imports to shrink bundle [OK]

Common Mistakes:

• Adding more libraries increases size
• Disabling AOT slows app and increases size
• Adding components without optimization