この記事の目的

Dockerは便利ですが
Windows環境で

npm installが遅い
ホットリロードが遅い
ビルドが異常に遅い

のような開発体験の劣化が起きがちです。

本記事は
遅い理由を説明しつつ
原因別に対策をチェックリスト化したものです。

先に結論まず疑う順

bind mountのI Oが遅い
ファイル監視が過剰でCPUが燃える
ボリュームと依存関係の置き場所が悪い
ビルドキャッシュが効いていない
そもそもWSL2の設定が弱い

この順で潰すと効率が良いです

よくある症状と原因

bind mountがボトルネック

症状

node_modulesを含む状態でホストをマウントしている
触ってないのにCPUが上がる

なぜ起きる

大量の小さなファイルアクセスが
ホストとコンテナ間で頻発し
I Oが支配的になります。

対策

node_modulesはコンテナ側に置く
ソースだけをマウントし依存はvolumeに逃がす

例の考え方

./src はマウント
/app/node_modules はnamed volume

監視方式が合っていない

症状

Vite Next.js Webpackでホットリロードが遅い
監視が落ちる

なぜ起きる

ファイルイベントが拾えない環境では
ポーリングにフォールバックし
CPUとI Oを使い切ります。

対策

watch設定でポーリング間隔を調整
監視対象を絞る
生成物 .next dist を監視対象から除外

Dockerfileのレイヤーが悪い

症状

変更のたびに npm install が走る

なぜ起きる

package.jsonが頻繁に変わるレイヤーと
アプリコードのレイヤーが混ざると
キャッシュが毎回破棄されます。

対策

依存インストールは package.json と lock を先にCOPY
その後にソースをCOPY

開発用と本番用が混ざっている

症状

開発でも本番buildを毎回している

対策

dev用composeとprod用composeを分ける
devはホットリロードを最優先

WSL2のディスク位置が悪い

症状

Windows側のパスで作業している

なぜ起きる

WSL2のLinuxファイルシステムと
Windowsファイルシステムの間のアクセスは
追加コストが発生しがちです。

対策

可能ならLinux側のパスにプロジェクトを置く

最低限の改善テンプレ

node_modulesをvolumeへ

考え方

ソースはマウント
依存はvolume

これでI Oが劇的に改善することが多いです

ビルドキャッシュを効かせる

lockファイルが変わらない限り依存インストールを再実行しない

まとめチェックリスト

node_modulesをbind mountしていない
生成物ディレクトリを監視対象から除外した
Dockerfileで依存レイヤーが分離されている
devとprodのcomposeが分かれている
可能ならWSL2側のパスで作業している

この5つだけでも
WindowsでのDocker開発の体感はかなり改善します