Performance in Component Libraries Quiz: Tree-Shaking and Code Splitting Quiz

This quiz explores essential techniques for optimizing component libraries using tree-shaking and code splitting. Assess your understanding of strategies to reduce bundle sizes, enhance modularity, and improve load performance in modern web applications.

1. Identifying Tree-Shakable Code

   Which practice best ensures that unused components are removed during tree-shaking in a component library?

   1. Export each component individually using named exports
   2. Combine all exports into a single default export
   3. Place all components in one large file without exports
   4. Add all components to a global namespace

   Explanation: Exporting each component individually with named exports allows tree-shaking tools to accurately detect and remove unused code, effectively reducing bundle size. Combining all exports into a single default export prevents tree-shaking from identifying unused components because the entire object may be imported. Placing everything in a single file without exports or adding components to a global namespace does not support modularity or enable tree-shaking. Only individual named exports optimize for unused code elimination.

2. Dynamic Imports and Code Splitting

   When a routing system uses dynamic imports to load feature modules only when accessed, which performance technique is being applied?

   1. Dead code elimination
   2. Minification
   3. Inlining
   4. Code splitting

   Explanation: Code splitting breaks application code into smaller chunks that are loaded on demand, improving initial load performance by only fetching what's needed. Dead code elimination, also known as tree-shaking, removes unused code but does not delay loading. Inlining embeds resources directly in code, which can increase bundle size. Minification reduces file size but does not affect the structure of code loading. Only code splitting matches dynamic loading based on user interaction.

3. Limitations of Tree-Shaking

   Why might tree-shaking fail to remove certain unused functions from a library that uses side effects during initialization?

   1. All unused code is always removed regardless of side effects
   2. Tree-shaking ignores side-effect-free code
   3. Functions with comments cannot be eliminated
   4. Side effects at the top level prevent safe removal

   Explanation: Tree-shaking cannot safely remove code with top-level side effects because those effects must be preserved for correct application behavior. It is incorrect to say that all unused code is always removed, as this ignores the issue of side effects. Comments within functions do not affect tree-shaking. The claim that tree-shaking ignores side-effect-free code is inaccurate; it primarily targets such code for elimination.

4. Granularity in Code Splitting

   If a component library splits its code based on feature groups, loading only relevant files as features are accessed, what is the primary benefit of this approach?

   1. Higher memory consumption at startup
   2. Reduced initial load time for users
   3. Longer total application build time
   4. Increased global variable usage

   Explanation: Splitting code by feature groups allows the application to load only necessary files initially, which significantly decreases the first load time and improves user experience. Increased global variable usage is unrelated to this technique. Higher memory consumption at startup does not occur; rather, memory usage can decrease. Longer build times can sometimes happen with code splitting, but this is not the main benefit.

5. False Positives in Tree-Shaking

   A developer imports an entire utility module but uses only one function. Without tree-shaking, what is the likely result?

   1. Only the used function will be present in the final bundle
   2. All code from the utility module is bundled
   3. Side effects are ignored during bundling
   4. The utility module fails to load

   Explanation: If tree-shaking is not applied, importing the entire module means all its code is included in the bundle, whether used or not. Only with tree-shaking can the unused code be removed, so the claim that only the used function is present is false. The module will successfully load; it does not fail. Side effects are not ignored during bundling without tree-shaking—these are still processed normally.