【ITニュース解説】Part 4: Migration to RsBuild

Webアプリケーションを開発する際、ソースコードを実際にWebブラウザで動く形に変換・最適化する作業は非常に重要だ。この変換作業を行うのが「ビルドツール」と呼ばれるもので、まるで料理人が食材（コード）を調理して美味しい料理（アプリケーション））を作り上げるように、コードを整理し、効率的に動くようにしてくれる。この記事では、これまで広く使われてきたビルドツールであるWebpackを使ったプロジェクトを、より新しいビルドツールであるRsbuildに移行した際の具体的な変化と、そのメリット・デメリットについて解説する。

これまでのWebアプリケーション開発では、Webpackというビルドツールが非常に強力で柔軟性があるため、広く利用されてきた。しかし、プロジェクトの規模が大きくなり、機能が追加されていくにつれて、Webpackの設定ファイルが複雑化し、管理しなければならない部品（プラグインやツール）の数も増えていくという課題があった。例えば、前回の開発作業では、テストを実行するJest、CSSを処理するPostCSS、画像などのファイルを扱うアセットハンドリング、そしてアプリケーションのサイズを監視する機能などを追加した結果、基本的なひな形コード（ボイラープレート）が肥大化し、設定コードや依存関係の管理が大変になっていた。このような状況では、開発者が新しい機能を実装するよりも、ツールの設定やメンテナンスに多くの時間を費やしてしまう可能性がある。これを解決するために、専用のパッケージを作成して複雑さを隠すこともできるが、それには継続的なメンテナンスやバージョン管理が必要になる。

そこで、新しいアプローチとして検討されたのがRsbuildへの移行だ。もしWebpackを使い続けるとすれば、パフォーマンスを向上させるために、コード変換ツールをBabelからSWCに、テストツールをJestからVitestに切り替えたり、開発効率を上げるためのソースマップの有効化、アプリケーションの読み込み速度を最適化するチャンク分割の調整、サーバーサイドレンダリング（SSR）のサポートといった多くの改善作業が必要になるだろう。これらはそれぞれ手間のかかる作業であり、今回の記事では、これらの手間をかけずに、よりシンプルにプロジェクトを最適化する方法としてRsbuildへの移行を選んだ。

Rsbuildは、Rspackという高速なビルドエンジンを基盤としている。このRspackはWebpackと互換性のあるAPI（プログラムの命令体系）を持っているため、既存のWebpackプロジェクトからの移行が比較的スムーズに行えるという大きな特徴がある。さらに、RsbuildはViteという別の現代的なビルドツールのように、「必要な機能が最初からすべて揃っている」という開発体験（DX）を提供する。これにより、開発者は複雑な設定をすることなく、すぐに開発を始められる。RsbuildがWebpackよりも高速であり、より少ない設定で動くことも大きな魅力だ。今回の比較では、直接Viteを使わなかったのは、ViteがRustベースのRolldownというツールと組み合わせた場合と比較すべきだが、Rolldownがまだ完全に安定していないためだ。RspackとViteの基盤技術であるRustは、非常に高速な処理能力を持つプログラミング言語であり、これらの新しいビルドツールが高速である理由の一つとなっている。

今回の移行における比較を行うために、いくつかの重要な指標が設定された。具体的には、Webアプリケーションのサイズ（バンドルサイズ）、コードを変換して実行可能な状態にするまでの時間（ビルド時間、ローカル環境とCI環境の両方で計測）、開発中にコードの変更を即座に反映させるための開発サーバーが起動するまでの時間、プロジェクトが依存している外部ライブラリの数（package.jsonの依存関係の数）、プロジェクト全体のディスク容量、プロジェクトの依存関係をインストールする時間、そして基本的なひな形コードの行数だ。これらの指標は、開発者の生産性、アプリケーションのパフォーマンス、そしてプロジェクトの維持管理コストに直接関わるため、ビルドツールを選択する上で非常に重要となる。

具体的な計測は、MacBook Air M1というローカル環境と、GitHub Actionsという自動化されたテスト・ビルド環境（CI環境）で行われた。Node.jsのバージョンは22 LTS、パッケージ管理には既存のnode_modulesが使われた。時間の計測は5回実行して平均値と中央値を採用し、より正確な結果を得ている。

さて、計測結果を見てみよう。まずWebアプリケーションのサイズであるバンドルサイズでは、Webpackでは199.96 KB（圧縮時52.2 KB）だったのに対し、Rsbuildでは143.62 KB（圧縮時45.62 KB）と大幅に小さくなった。これは、Rsbuildが使われていない「core-js polyfills」という古いブラウザ向けの互換性コードを自動的に削除してくれたためだ。ビルド時間も大きく改善された。ローカル環境でのビルド時間は、Webpackの平均3.614秒からRsbuildでは平均0.865秒へと約4分の1に短縮され、CI環境でもWebpackの平均6.418秒からRsbuildの平均1.246秒へと劇的に高速化した。開発サーバーが起動するまでの時間も、Webpackの平均1.024秒からRsbuildではわずか0.03〜0.05秒と、ほぼ瞬時に立ち上がるようになった。

プロジェクトが依存している外部ライブラリの数も、Rsbuildで大きく削減された。Webpackでは開発に必要な依存関係が31個あったのに対し、Rsbuildでは16個と15個も少なくなった。これは、Rsbuildが多くの機能を「必要なものがすべて揃っている」形で提供しているため、別途多くのプラグインを追加する必要がないことを示している。プロジェクト全体のディスク容量は、Webpackが212 MBだったのに対し、Rsbuildでは216 MBとわずかに増えたが、これはRsbuildの内部キャッシュや実行ファイルによるものだ。依存関係のインストール時間も、ローカル環境でWebpackの平均1.556秒からRsbuildの平均1.358秒へ、CI環境でWebpackの平均10.981秒からRsbuildの平均8.527秒へと短縮された。最後に、ひな形コードの行数は、Webpackの285行からRsbuildでは256行と少なくなり、プロジェクトの設定がよりシンプルになったことを示している。

これらの結果からわかるように、従来のWebpackとBabelの組み合わせは、最新のRsbuildに比べて純粋なパフォーマンスで劣ることは予想通りだ。しかし、この移行は単なる技術的な改善に留まらず、ビジネス上の多くのメリットをもたらす。例えば、ビルドやデプロイの時間が短縮されることで、緊急のバグ修正がより迅速に行えるようになり、システム停止によるコストを削減できる。また、新機能のリリースサイクルが短縮され、より早く市場に価値を提供できるようになる。組織規模で考えれば、ビルド時間の短縮はサーバーやクラウドの利用コスト削減にもつながるだろう。依存関係が減り、パイプラインが単純化されることで、メンテナンスにかかる時間が減り、エラーの発生や再実行の頻度も減少する。さらに、Webアプリケーションのサイズが小さくなることで、ユーザーがWebサイトにアクセスした際のデータ転送量（帯域幅）やコンテンツ配信ネットワーク（CDN）のコストが安くなり、何よりもページ表示が速くなることで、ユーザーの離脱率が減り、Webサイトでの目標達成（商品の購入など）につながる可能性が高まる。開発者にとっても、開発サーバーの起動が速く、ローカルでのビルドやコードの変更が即座に反映される（HMR: Hot Module Replacement）ことで、待ち時間が減り、開発効率とモチベーションが向上する。

もちろん、Rsbuildへの移行にはいくつかのトレードオフも存在する。Webpackは長年の歴史があり、非常に多くのプラグインが開発され、提供されているため、そのエコシステム（関連ツールの広がり）はまだRsbuildが追いついていない。また、Rspackの設計目標は、WebpackのAPIと100%完全に互換性があることではないため、一部の機能で挙動が異なる可能性もある。そのため、Webpackと全く同じ成果物（ビルドされたファイル）が作成されるわけではないという点も理解しておく必要がある。さらに、現在のRsbuildはブラウザ側でのWASM（WebAssembly）という技術のサポートには対応していない。WASMは、Web上で高性能な処理を行うための新しい技術であり、今後活用を考えている場合は注意が必要だ。

しかし、これらのトレードオフを考慮しても、今回の移行はプロジェクトに大きなメリットをもたらしたと結論づけられる。Gitの変更履歴を見ると、この移行によって5,721行のコードが削除され、930行のコードが追加されたと示されており、これは約80%近くのコードが削減され、プロジェクトが大幅に簡素化されたことを意味する。設定がシンプルになり、パフォーマンスが向上することで、開発者はより本質的なアプリケーションの機能開発に集中できるようになり、結果として高品質で高速なWebアプリケーションを効率的に提供できるようになるだろう。