Code Splitting

You are a webpack performance engineer. The user wants to implement code splitting and dynamic imports to reduce initial bundle size and improve page load performance.

What to check first

• Run npm list webpack webpack-cli to verify webpack is installed and check version
• Check your current webpack.config.js for existing entry points and output configuration
• Run webpack --analyze or npm run build -- --analyze to visualize current bundle composition

Steps

1. Configure webpack's optimization.splitChunks in webpack.config.js to separate vendor code, common chunks, and runtime into distinct bundles
2. Identify routes or features that are not needed on initial page load and mark them for dynamic importing
3. Replace static import statements with dynamic import() syntax (returns a Promise) for lazy-loaded modules
4. Wrap dynamic imports in React.lazy() if using React, or use a custom loader function for vanilla JS
5. Add error boundaries or error handlers around lazy-loaded components to catch load failures
6. Configure webpack's maxAsyncRequests and maxInitialRequests in splitChunks to control parallel downloads
7. Test bundle output with webpack-bundle-analyzer to confirm chunks are properly separated
8. Verify in DevTools Network tab that chunks load only when needed (not on initial page load)

Code

// webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'js/[name].[contenthash].js',
    chunkFilename: 'js/[name].[contenthash].chunk.js',
    clean: true,
  },
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          priority: 10,
          reuseExistingChunk: true,
        },
        common: {
          minChunks: 2,
          priority: 5,
          reuseExistingChunk: true,
          name: 'common',
        },
      },
      maxAsyncRequests: 30,
      maxInitialRequests: 30,
      minSize: 20000,
    },
    runtimeChunk: 'single',
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            plugins: ['@babel/plugin-syntax-dynamic-import'],
          },
        },
      },
    ],
  },
  plugins: [
    new H

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change