Hey there! I’ve run into this exact issue before—Docker’s default file system handling can really bog down webpack’s dev server, especially on Mac/Windows. Let’s break down why this happens and how to speed things up:

Is this a Docker or webpack problem? #

Mostly it’s a Docker file system performance issue, not webpack itself. When you mount your local code into a Docker container, the cross-system file sync (between your host OS and the Linux container) is way slower than native file access. Webpack’s dev server relies heavily on fast file reads/watches, so this bottleneck hits hard. That said, we can tweak both Docker and webpack settings to fix it.

Top Fixes to Speed Up Builds #

1. Optimize File Mounts (Biggest Win!) #

• Use the right Docker Desktop backend:
  • On Windows, switch to the WSL 2 backend (Settings > Resources > WSL Integration)—it’s way faster than the legacy Hyper-V backend for file sharing.
  • On Mac, enable VirtioFS (Settings > Features in Development > Enable VirtioFS) if you’re on a recent Docker Desktop version. It’s a game-changer for file sync speeds.
• Add cache/delegated flags to your mounts:
  When using docker-compose or bind mounts, add the cached (host-first caching) or delegated (container-first caching) flag to reduce sync overhead. For example:

  # docker-compose.yml
  services:
    your-app:
      volumes:
        - ./src:/app/src:cached  # Prioritize host's cache for faster reads
        - ./public:/app/public:cached
        # DO NOT mount node_modules! Keep it inside the container
  

  Never mount your host’s node_modules into the container—binary dependencies (like native modules) are OS-specific, so they’ll be slower and might even break. Install them directly in the container via your Dockerfile:

  COPY package*.json ./
  RUN npm install  # Installs into container's node_modules, which stays fast
  COPY . .
  

2. Tune Webpack’s Watch Settings #

Docker’s file system doesn’t always play nice with webpack’s default inotify-based file watching. Adjust these options to make it faster and more reliable:

// webpack.config.js
module.exports = {
  // ...
  watchOptions: {
    poll: true,  // Fallback to polling (works better in Docker than inotify)
    ignored: /node_modules/,  // Skip watching node_modules to reduce overhead
    aggregateTimeout: 300,  // Wait 300ms after changes to trigger a build (avoids frequent rebuilds)
  }
};

3. Enable Webpack Caching #

Let webpack reuse previous build artifacts instead of starting from scratch every time:

// webpack.config.js
const path = require('path');

module.exports = {
  // ...
  cache: {
    type: 'filesystem',  // Store cache in files instead of memory (persists across container restarts)
    cacheDirectory: path.resolve(__dirname, '.webpack-cache'),
  }
};

You can optionally mount .webpack-cache to your host if you want to retain cache across container rebuilds, but even keeping it inside the container will speed up consecutive builds.

4. Give Docker Enough Resources #

Webpack builds are CPU and memory-heavy. Head to Docker Desktop Settings > Resources and allocate at least:

• 4 CPU cores
• 8 GB of memory
• 2 GB of swap space
  If you’re on Linux, ensure you’re using the overlay2 storage driver (run docker info | grep Storage Driver to check)—it’s the fastest default option for Docker.

5. Optimize Loader/Plugin Caching #

Don’t forget to enable caching for your loaders too:

• For Babel, add "cacheDirectory": true to your babel.config.json
• For other loaders like css-loader, check their docs for cache options

Final Notes #

After implementing these tweaks, you should see build times drop to something much closer to your local setup—often within 1-2 minutes, and maybe even faster with VirtioFS/WSL 2. The key is reducing the file sync overhead between host and container, and letting webpack reuse as much cached work as possible.

内容的提问来源于stack exchange，提问作者Griffin Meyer