2021/08/20 に公開972 views
@potato4d が @spring_raining に、 LINE公式アカウントの管理画面開発で行っている webpack のチューニングについて話を聞いてみました。
チューニングの経緯
- 7月末ごろから久々にLINE公式アカウントの管理画面開発を行っている
- 開発環境を久しぶりに立ち上げたところ、尋常ではない重さになっていた
- dev serverの立ち上げに6〜8分ほど
- ちょうど急ぎではないタイミングだったので、ビルド速度改善を試みた
build/dev serverの高速化のためにやったこと
- esbuild-loaderの導入
- https://github.com/privatenumber/esbuild-loader
- 体感1分ほど短縮。大きな差とは言えなかった
- thread-loaderの導入
- https://webpack.js.org/loaders/thread-loader/
- ほとんど差がなかった
- thread loader 自体が loader の並列化の仕組みであるため、今回有効とは言えない
- 特別並列化が有効なloaderを使ってるわけではないので効果が薄い
- オーバーヘッドもあるため、結果として違いがない状態に
-
Each worker is a separate node.js process, which has an overhead of ~600ms.
-
- 大規模なプロジェクトなので、数十個のサブコンポーネントがぶら下がる形になっており、その中には開発が活発でないものもある
- cache-loaderの導入
- 優位な差は得られなかった
- https://www.npmjs.com/package/cache-loader
- サブコンポーネント単位で予めビルド
- 開発に関わる部分以外を事前にビルドし、 resolve alias で解決する方法
- LINE公式アカウントでは、機能ごとにある程度コードが独立しているため
- ビルド対象が大幅に減ることで、8→2分程度に速度は改善
- productionとdevelopmentのビルド結果の同一性が疑わしいため、最終的には先にサブコンポーネントをビルドする点では変わらない
「推測するな計測せよ」をやりたい
- 今回は一度の試行にかかる時間が 8 分ということもあり、まずは手当たりしだいに思い浮かぶ方法を実装した
- 一方で、息の長いプロダクトは遅くなっている原因も複合的な物が多い
- 改善のためには、何が原因かは調べておきたい
- 一方で、ビルド時間自体を詳細に計測する方法自体の構築にはコストがかかる
- bundle sizeに関してはBundle analyzerがある
- ビルド時間の計測は自前でnode inspectを使う形になりそう
今後について
- webpack 4.x のままなので、 5.x へのアップデートを試みる
- ビルドが複雑であるためまだできていないが、一部を削ったときには単体でビルドが2分半ほどになった
- webpack 5 へは上げる前提で、現在は作業を進めている