Fix INP with Webpack: Reduce Long Tasks via Better Bundling

Step 1: Profile with webpack-bundle-analyzer

No bundling optimization should begin without a visualization of the current state. webpack-bundle-analyzer generates an interactive treemap showing the parsed size of every module in every chunk. Install it, run a production build, and open the report before changing any configuration.

npm install --save-dev webpack-bundle-analyzer

const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');

module.exports = {
  mode: 'production',
  plugins: [
    // Only run during analysis, not in standard CI builds
    process.env.ANALYZE === 'true' && new BundleAnalyzerPlugin({
      analyzerMode: 'static',
      reportFilename: 'bundle-report.html',
      openAnalyzer: false,
    }),
  ].filter(Boolean),
};

ANALYZE=true npx webpack --config webpack.config.js
open bundle-report.html

In the treemap, look for three patterns: a single enormous vendors rectangle, duplicate module names appearing in multiple chunks, and large libraries whose functionality you are only using partially (Lodash, Moment.js, date-fns/esm). These are your targets for the steps that follow.

For deeper profiling, pair the bundle analyzer with the JavaScript performance guide to correlate bundle weight with specific long tasks in the Chrome DevTools Performance panel.

Step 2: Tune SplitChunksPlugin for granular splitting

Webpack's default SplitChunksPlugin configuration produces a single vendors chunk containing all node_modules code. For INP, the goal is to split that chunk into smaller, more focused pieces: one chunk for the framework runtime (React + ReactDOM, ~130KB), one for UI components (MUI, Radix, etc.), one for data utilities, and one per major third-party library. Smaller chunks parse faster individually and can be loaded on demand.

module.exports = {
  mode: 'production',
  optimization: {
    splitChunks: {
      chunks: 'all',         // Split async AND sync chunks
      minSize: 20000,        // 20KB minimum chunk size
      maxSize: 244000,       // 244KB maximum -- split larger chunks
      minChunks: 1,
      cacheGroups: {
        // React core -- highly stable, cache forever
        reactCore: {
          test: /[\\/]node_modules[\\/](react|react-dom|scheduler)[\\/]/,
          name: 'vendor-react',
          chunks: 'all',
          priority: 40,
          enforce: true,
        },
        // UI component library -- changes less often than app code
        uiLibrary: {
          test: /[\\/]node_modules[\\/](@mui|@radix-ui|framer-motion)[\\/]/,
          name: 'vendor-ui',
          chunks: 'all',
          priority: 30,
        },
        // Data / utility libraries
        utils: {
          test: /[\\/]node_modules[\\/](lodash-es|date-fns|immer|zustand)[\\/]/,
          name: 'vendor-utils',
          chunks: 'all',
          priority: 20,
        },
        // All remaining node_modules
        defaultVendors: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendor-misc',
          chunks: 'all',
          priority: 10,
        },
      },
    },
  },
};

After this change, a build that previously emitted one vendors.js at 1.1MB will instead emit four chunks averaging 150-250KB each. The vendor-react chunk is essentially permanent -- it changes only when you upgrade React -- so it receives a long-lived cache header and is never re-downloaded by returning visitors.

Step 3: Extract the runtime chunk

The Webpack runtime is a small JavaScript manifest (~3KB) that maps module IDs to chunk filenames. By default it is embedded in the entry chunk, meaning that any change to any module anywhere in the application changes the entry chunk hash. Extracting it into a standalone file is a one-line configuration change with zero downsides.

module.exports = {
  mode: 'production',
  optimization: {
    // Isolate the runtime manifest into its own tiny chunk
    runtimeChunk: 'single',
    // Use content-based hashes for stable long-term caching
    moduleIds: 'deterministic',
    chunkIds: 'deterministic',
  },
};

With runtimeChunk: 'single', a typical deploy now invalidates the cache for only two files: the runtime manifest and the application chunk that actually changed. The vendor-react chunk, unchanged for months, stays in the CDN cache. This directly reduces the amount of JavaScript a returning user must download and re-parse on deployment day, which is often when INP regressions spike in field data.

Use moduleIds: 'deterministic' alongside runtime extraction. Without it, Webpack assigns sequential integer IDs to modules; adding a new dependency anywhere in the tree shifts all IDs, causing all chunk hashes to change and negating the caching benefit.

Step 4: Code-split routes with dynamic import()

Every statically imported route component is included in the initial bundle, parsed before any interaction occurs. Replacing static imports with dynamic import() tells Webpack to emit a separate async chunk per route. The browser fetches and parses each route chunk only when the user navigates to that route, eliminating the parse cost for all other routes on page load.

// All route components parsed upfront, even for unvisited routes
import HomePage from './pages/HomePage';
import DashboardPage from './pages/DashboardPage';
import SettingsPage from './pages/SettingsPage';
import CheckoutPage from './pages/CheckoutPage';
import AdminPage from './pages/AdminPage';

const routes = [
  { path: '/', component: HomePage },
  { path: '/dashboard', component: DashboardPage },
  { path: '/settings', component: SettingsPage },
  { path: '/checkout', component: CheckoutPage },
  { path: '/admin', component: AdminPage },
];

import { lazy, Suspense } from 'react';

// Each route becomes a separate async chunk
// webpackChunkName controls the output filename
const HomePage = lazy(
  () => import(/* webpackChunkName: "page-home" */ './pages/HomePage')
);
const DashboardPage = lazy(
  () => import(/* webpackChunkName: "page-dashboard" */ './pages/DashboardPage')
);
const SettingsPage = lazy(
  () => import(/* webpackChunkName: "page-settings" */ './pages/SettingsPage')
);
const CheckoutPage = lazy(
  () => import(/* webpackChunkName: "page-checkout" */ './pages/CheckoutPage')
);
const AdminPage = lazy(
  () => import(/* webpackChunkName: "page-admin" */ './pages/AdminPage')
);

// Wrap the router outlet in Suspense
function AppRouter() {
  return (
    <Suspense fallback={<PageSkeleton />}>
      <Routes>
        <Route path="/" element={<HomePage />} />
        <Route path="/dashboard" element={<DashboardPage />} />
        <Route path="/settings" element={<SettingsPage />} />
        <Route path="/checkout" element={<CheckoutPage />} />
        <Route path="/admin" element={<AdminPage />} />
      </Routes>
    </Suspense>
  );
}

For heavy components within a page (rich text editors, data grids, PDF viewers), apply the same pattern at the component level. A tiptap rich text editor with its extensions can weigh 180KB -- loading it only when the user activates an edit form eliminates a 60ms parse task from every page load.

You can also add prefetch hints so the browser loads the next likely route chunk during idle time:

// webpackPrefetch injects a <link rel="prefetch"> tag automatically
// The chunk downloads at idle priority after the current route finishes
const CheckoutPage = lazy(
  () => import(
    /* webpackChunkName: "page-checkout" */
    /* webpackPrefetch: true */
    './pages/CheckoutPage'
  )
);

This approach is compatible with frameworks that build on Webpack. If your project uses Create React App, Vite, or another bundler, consult Fix INP in React for framework-specific guidance, and Fix INP in Next.js for Next.js-specific dynamic import patterns.

Step 5: Tree shaking with the sideEffects field

Tree shaking removes exports that are never imported anywhere in the dependency graph. Webpack 5 enables this automatically in production mode, but it cannot safely tree-shake a module unless it knows the module has no side effects (global mutations, CSS injections, polyfills). The sideEffects field in package.json provides this guarantee.

{
  "name": "my-app",
  "sideEffects": [
    "*.css",
    "*.scss",
    "./src/polyfills.js",
    "./src/global-styles.js"
  ]
}

Setting "sideEffects": false tells Webpack every module is pure. The more targeted array form above is safer -- it marks only CSS and known side-effectful files as exceptions, while allowing all application JavaScript to be tree-shaken. This is especially impactful for libraries like Lodash when imported via lodash-es (the ESM edition), which exposes hundreds of named exports. An import like import { debounce } from 'lodash-es' will include only the debounce module rather than the full 71KB library.

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  mode: 'production',
  optimization: {
    usedExports: true,      // Mark unused exports in module scope
    sideEffects: true,      // Read sideEffects from package.json
    minimize: true,
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          compress: {
            passes: 2,      // Two compression passes for better DCE
            drop_console: true,
          },
        },
      }),
    ],
  },
};

After enabling sideEffects and switching from lodash to lodash-es, a representative application saw its utility chunk shrink from 94KB to 11KB. That 83KB reduction translates directly to a shorter parse task and a measurable INP improvement. See the JavaScript performance guide for more on identifying oversized dependencies.

Step 6: Persistent filesystem caching and Module Federation cost

Webpack 5's persistent cache stores the compiled module graph to disk between builds. This has two performance implications: it keeps CI build times fast as your chunk count grows, and it ensures that performance-critical configurations (like the SplitChunks settings above) do not get accidentally disabled to speed up slow local builds.

module.exports = {
  mode: 'production',
  cache: {
    type: 'filesystem',
    buildDependencies: {
      // Invalidate cache when config files change
      config: [__filename],
    },
    // Version the cache by Node.js version and environment
    version: `${process.env.NODE_ENV}-${process.versions.node}`,
  },
};

If your project uses Webpack 5 Module Federation to share code between micro-frontends, be aware of its INP cost. Each remote container is a separately deployed Webpack build. When a host application needs a component from a remote, it issues a network request to fetch the remote's manifest and then the component chunk. If this happens inside an event handler -- for example, when the user clicks a button that renders a component from a remote -- the interaction is blocked by the full network round-trip.

The fix is to prefetch remote containers eagerly, outside of any interaction path:

// In the host application's bootstrap.js (not index.js)
// Prefetch remote manifests during idle time
if ('requestIdleCallback' in window) {
  requestIdleCallback(() => {
    // Kick off the remote fetch before any user interaction
    import('checkout/CartWidget').catch(() => {
      // Silently ignore prefetch failures
    });
  });
}

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        checkout: 'checkout@https://checkout.example.com/remoteEntry.js',
      },
      shared: {
        // Mark shared modules as singleton to prevent duplicate parsing
        react: { singleton: true, requiredVersion: '^18.0.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
      },
    }),
  ],
};

The singleton: true flag is critical. Without it, Module Federation may load two copies of React -- one from the host and one from the remote -- doubling the parse cost and potentially causing hook errors at runtime. A full INP guide covers the broader interaction model that explains why each additional parse millisecond translates directly to INP regression.

Step 7: Deduplicate dependencies and defer third-party scripts

Duplicate packages and eagerly executed third-party scripts are two separate problems that both inflate main thread work. Resolve.alias handles duplicates; a combination of deferred script loading and event-driven initialization handles third-party scripts.

To find duplicates, run the following before touching any configuration:

# npm
npm ls react 2>/dev/null | grep react

# Deduplicate npm lockfile
npm dedupe

# yarn
yarn dedupe --check

If npm ls shows React listed at two different versions, force resolution to a single copy with Webpack's resolve.alias:

const path = require('path');

module.exports = {
  resolve: {
    alias: {
      // Force all imports of react to resolve to the root installation
      react: path.resolve('./node_modules/react'),
      'react-dom': path.resolve('./node_modules/react-dom'),
    },
  },
};

For third-party analytics, chat, and A/B testing scripts, move them out of the Webpack bundle entirely and load them asynchronously via the HTML template, firing only after the page is interactive. Using html-webpack-plugin:

<!-- Load analytics only after the browser is idle -->
<script>
  window.addEventListener('load', function () {
    if ('requestIdleCallback' in window) {
      requestIdleCallback(loadAnalytics, { timeout: 4000 });
    } else {
      setTimeout(loadAnalytics, 2000);
    }

    function loadAnalytics() {
      var script = document.createElement('script');
      script.src = 'https://cdn.example-analytics.com/analytics.min.js';
      script.async = true;
      script.defer = true;
      document.head.appendChild(script);
    }
  });
</script>

Do not bundle analytics scripts into your Webpack output. Beyond the INP cost, it prevents updating the script without a full redeploy and forces all users to re-download a chunk whenever the analytics vendor pushes an update to their SDK. For further detail on third-party script management, see the JavaScript performance guide. To measure whether your changes have moved the needle, use the performance budget tool to set an INP threshold and receive alerts when a new deploy crosses it.