JavaScript のダウンサイズ: バンドラーの最適化をマスターする

導入

過去 15 年間にわたって、JavaScript エコシステムは急速に拡大し、開発を容易にする無数のツールが導入されました。ただし、これらのツールにはバンドル サイズの増大という代償が伴います。実際、HTTP アーカイブのデータによると、ページごとに転送される JavaScript の平均量は、2010 年の 90 KB から 2024 年の 650 KB まで急増しています (出典)。

圧縮の導入と進歩にもかかわらず、この傾向は衰える兆しがありません。機能を追加し続けると、次のような課題が残ります: どうすれば配布される JavaScript を減らすことができますか?

奇妙なことに、解決策は簡単でもあり、難しいものでもあります。簡単な部分は、プロジェクトレベルの調整ですぐに成果が得られることです。難しいのは、永続的な影響を与えることであり、バンドラー、ライブラリ、ツールを改善するためにコミュニティ全体の変更が必要です。

この記事は、プロジェクトの実用的な改善に焦点を当てており、以下の内容をカバーしています。

• バンドラー: ビルド ツールを最適化して出力サイズを削減します。
• ライブラリ: 外部依存関係を賢く選択して使用します。
• あなたのプロジェクト: バンドルを縮小するための実践的な手順。

今後の記事では、エコシステム全体の改善点について取り上げますが、現時点では、これらの要因がバンドルの肥大化にどのように寄与するのか、またその管理方法について考えてみましょう。

JavaScript の最適化が重要な理由

JavaScript は最新の Web インタラクティブ性を支えるエンジンですが、無料ではありません。 JavaScript は、ブラウザが処理する必要があるリソースの中で最も計算コストが高くなります。肥大化したバンドルはレンダリングをブロックし、全体的なパフォーマンスを低下させる可能性があるため、多くの場合、ページが速く感じるか遅く感じるかを決定するボトルネックになります。

JavaScript バンドルが大きくなるほど、ロード、解析、コンパイル、実行に時間がかかります。これにより、コンテンツの表示やユーザーによるページの操作など、他のすべてが遅れます。ファイバー接続を備えたハイエンドのラップトップを使用している人にとって、これは小さな迷惑かもしれません。しかし、低電力の携帯電話や不安定なネットワークを使用している人にとっては、サイトに留まるか完全に離れるかの違いになる可能性があります。

JavaScript バンドル サイズを縮小するための最初のステップは、ツリー シェーク (または「デッド コードの削除」) です。これは、ほとんどのバンドラーがすぐに実行できます。しかし、すべてのバンドラーは平等なのでしょうか?

バンドラー

JavaScript でのバンドルは、手動による連結やタスク ランナーから洗練されたバンドラーまで、長い道のりを歩んできました。現在、バンドラーのパフォーマンスが重要な焦点となっており、開発者はより高速なビルドを優先しています。ただし、ビルド速度がすべてではありません。同様に重要なのは、生成されるバンドルのサイズです。バンドルが小さいほど、ユーザーの読み込み時間は速くなります。

より良いパフォーマンスを求めて、私たちは JavaScript でのバンドラーの作成から Rust や Go などの言語に移行しました。この切り替えでは、バンドラーを最初から作成する必要があるため、古いバンドラーに存在していたすべての機能と最適化を再実装する必要があります。長期的には、これはおそらく報われるでしょう。しかし、短期的には、優れたツリーシェイキングなど、JavaScriptバンドラーが何年もかけて開発してきたいくつかの機能が欠けていることを意味します。そして、これこそがバンドル サイズを最小限に抑えるのに役立つ機能です。

ベンチマーク

もちろん、話は安いので、数字を見てみましょう?

8 つの人気のあるライブラリを比較し、7 つの人気のあるバンドラーとバンドルしてみましょう。公平性を保つために、私は以下を使用しました:

• ノード 22.12.0
• 自己申告のビルド時間
• 特に Parcel などのツールの場合、キャッシュをウォームアップするための 3 回目の実行のタイミング
• バンドラーの処理方法が異なるため、ライセンスを含むすべてのコメントを削除する構成

正確な構成については、ベンチマーク セットアップ リポジトリをチェックアウトできます。

テストされたバンドラー:

• エスビルド (0.24.0)
• 小包 (2.13.2)
• ロールダウン (0.15.0-snapshot-993c4a1-20241205003858)
• ロールアップ (4.28.0)
• Rspack (1.1.5)
• ヴァイト (6.0.3)
• webpack (5.97.1)

この記事の執筆時点では、Rolldown はまだアルファ版であるため、不利な点があり、その結果は時間の経過とともに改善される可能性があることに注意してください。

テストされたライブラリ:

• chart.js
• ckeditor5
• d3
• ハンサム
• ルクソン
• mobx
• tippy.js
• ゾッド

これらのライブラリはサイズや機能が異なり、スタンドアロン アプリケーションとほぼ同じように機能するものもあります。

ビルド速度

ビルド速度から始めましょう。これは開発者が非常に気にしているようです。これらのライブラリをすべてバンドルすると、ビルド時間は 192 ミリ秒となり、esbuild が最適になります。最も遅いビルド時間の 7.23 秒と比較すると、37 倍以上高速です。

これらの結果に基づいて、バンドラーを次の 3 つのカテゴリにグループ化できます。

1. 超高速™: esbuild、Parcel、Rolldown (
2. 高速: Rspack (2.2 秒)。
3. 遅い: ロールアップ、Vite、Webpack (それぞれ 5 秒)。

その違いは明らかです。たとえば、Rolldown と Rspack は、古い対応物である Rollup と webpack よりもそれぞれ 11.5 倍と 3.3 倍高速であり、すべて理論的な下位互換性を維持しています。これらの新しいバンドラーに切り替えると、大規模プロジェクトの生産性が大幅に向上する可能性があります。

出力サイズ

出力サイズに関しては、ビルド時間ほど大きな違いはありませんが、依然として重要です。

集計結果

8 つのライブラリをすべてバンドルすると、Vite が勝者となり、出力サイズは 2087 KiB になります。最大出力サイズの 2576 KiB と比較すると、出力は 23.5% 以上小さくなります。

出力サイズの 23.5% の差はかなり大きくなります: 遅い 3G 接続では、最小のバンドルのダウンロードには約 5.7 秒かかる可能性がありますが、最大のバンドルは 7 秒近くかかります。解析時間と実行時間もバンドル サイズに応じて変化するため、実際の違いはさらに顕著になる可能性があります。

これらの結果に基づいて、バンドラーの出力を再度 3 つのカテゴリにグループ化できます。

1. 最小: esbuild、Parcel、Rollup、および Vite (~2085–2160KiB)。
2. わかりました: webpack (~2317KiB).
3. ビッグ: ロールダウン、Rspack (~2490–2580KiB)。

個別のライブラリ

上記にリストされているすべてのライブラリをプロジェクトで使用する可能性は低いため、集計結果だけでは全体像がわかりません。さらに興味深いのは、これらのバンドラーが個々のライブラリをどのように処理するかです。

chart.js や mobx などのライブラリの場合、バンドラーの選択が出力サイズに大きく影響する可能性があり、その差は 70% に達します。これは、特定の依存関係を使用してバンドラーをテストすることの重要性を強調しています。他のほとんどの場合、その差ははるかに小さく、約 20 ～ 30% です。

さらに、Webpack は全体としては中位に終わりましたが、8 ケース中 6 ケースで最高のパフォーマンスを発揮しました。ただし、handsontable と chart.js をバンドルするとパフォーマンスが大幅に低下したため、最終的には元の状態になりました。これは、使用するライブラリによっては、webpack が適切な選択肢になる可能性があることを意味します。

スペクトルの反対側には、ロールダウンがあります。 8 件中 7 件でパフォーマンスが最悪でした (まだアルファ版であることに注意してください)。
RSpack も同様の話です。ロールダウンよりもパフォーマンスは優れていましたが、それでも他のバンドラーよりもはるかに大きなバンドルを生成しました。

新しいバンドラーへの移行を検討している場合は、使用するライブラリでテストし、出力サイズの増加を犠牲にしてビルド速度が向上するかどうかを確認してください。

バンドルサイズと出力速度の関係

示されているように、新しいバンドラーははるかに高速ですが、より大きなバンドルを生成する可能性があります。古いバンドラーから移行する場合は、ビルド時間を比較するだけでなく、結果のバンドル サイズも比較してください。より大きなバンドルを得るために、より高速なビルドをトレードしていることに気づくかもしれません。

たとえば、Angular が webpack から esbuild に切り替わった後、空の Angular アプリのサイズが約 20 KB 増加したと一部の開発者が報告しました。これは、ビルド速度とバンドル サイズのトレードオフを完全に強調しています。

開発者の生産性と幸福度にとって重要であるため、ビルド速度に注目すべきではないというわけではありません。 CI のビルド時間とコードのマージに必要な時間の間には相関関係もあります。

バンドラーを選択するときは、まずバンドラーが提供する機能を確認してください。次に、ビルド速度とバンドル サイズのバランスを目指します。無理のない時間内で最小のバンドルを作成できるバンドラーを選択してください。
プロジェクトからいくつかの代表的なライブラリをテストします。依存関係がコードベースの大部分を占めている場合、これらのベンチマークで見られる違いは、状況を予測する優れた指標となる可能性があります。

図書館

リストの次は外部ライブラリです。これは多くの場合、JavaScript バンドルの大部分を占めます。私がこれまでに取り組んだアプリケーションのほとんどではないにしても、多くのアプリケーションでは、バンドル サイズの大部分を占めていました。だからこそ、それらを賢く選択 (そして使用) することが非常に重要です。

ゴールドだが古い

私たちの多くは、単一の関数を使用するためだけに lodash、axios、moment などのライブラリをインストールしており、アプリケーションが肥大化してしまいます。これらのライブラリは素晴らしく、歴史的に重要ですが、人気が高まるにつれて、より軽量な代替ライブラリが作成され、その機能の一部が言語自体に追加されました。

それを活用できます。これらのライブラリのネイティブ API や、新しくて小規模な代替手段を列挙することもできますが、それをカバーする記事はすでにたくさんあります。他にも非常に多くのライブラリがあるため、すべてをカバーすることは不可能です。

そのため、私は、使用しているライブラリを調べて、それらを削除したり、ネイティブ API やより小規模な代替物に置き換えたりできるかどうかを確認するという一般的なアドバイスのみを提供します。 YOU MIGHT NOT NEED * Web サイトは、始めるのに最適なリソースです。

最適化されたインストール パス

ほとんどのライブラリはデフォルトではサイズが最適化されていませんが、一部のライブラリは特別なインストール パスや部分的なビルドを提供します。テストに使用したライブラリの中でも、chart.js、handsontable、ckeditor5 は、必要な部分のみを含めることでライブラリのサイズを削減する方法を提供します。例として ckeditor5 を見てみましょう。

デフォルトのインストール パスでは、バンドル サイズは 660 ～ 800 KiB になります。ただし、最適化されたインストール パスを使用すると、バンドル サイズは 603 ～ 653 KiB に低下し、Rolldown によって生成されるバンドルのみが約 750 KiB になります。これは、バンドラーによって異なりますが、サイズが 7% から 23% 削減されます。

依存関係の重複

もう 1 つ注意すべきことは、依存関係の重複です。これは、JavaScript アプリケーションで驚くほど一般的な問題です。たとえば、Bluesky 埋め込みウィジェットには 2 つのバージョンの zod 検証ライブラリがありました。重複を削除すると、バンドル サイズが約 9% 削減されました。

通常、この問題は、同じライブラリの 2 つの異なるバージョンをプルしたために発生するのではなく、外部ライブラリの 1 つが同じライブラリに依存しているがバージョンが異なるために発生します。多くの場合、これは依存するライブラリを更新することで解決できます。

あなたのプロジェクト

これらすべてを念頭に置いて、いよいよパズルの最後のピースであるプロジェクトに進むことができます。バンドルを縮小してパフォーマンスを向上させるためにできることは次のとおりです。

バンドルを検査する

最初のステップは 可視化です。バンドルの中に何が入っているかを理解していなければ、バンドルのサイズを減らすことは推測ゲームになります。これには、私が作成した Sonda というバンドル アナライザーとビジュアライザーを使用できます。これは、上記のほとんどのバンドラー (Parcel を除く) で動作し、バンドルに寄与する個々のファイルのサイズを正確に表示します。

プロジェクトにインストールし、バンドルの一部を視覚的に検査することから始めることができます。

バンドルの内容をよく理解し、最適化できる部分を特定したら、グラフ タイルをクリックして以下を確認できます。

• 圧縮前後のファイル サイズ
• 選択したファイルをインポートするファイルのリスト、
• さらに、バンドルに含まれるソース コードの一部を検査することもできます。

Sonda は重複した依存関係についても警告するため、問題の根本をすぐに特定して修正できます。

理想的には、1 回限りの検査を行うだけでなく、CI パイプラインの一部として継続的な監視を設定する必要があります。特に大規模なプロジェクトの場合、時間の経過とともに変更を追跡すると、小さな変更が雪だるま式に増えて時間の経過とともに大幅に肥大化するのを防ぐことができます。

外部ライブラリを削除または最適化する

最速のコードは、出荷されないコードです。可能な限り:

• ネイティブ API で置き換えられるライブラリを削除します。
• 重量のあるライブラリをより小さな代替ライブラリに置き換えます。
• ライブラリがサポートしている場合は、最適化されたインストール パスを使用します。

コード分​​割を使用する

アプリケーションの一部を削除できない場合は、コード分割を試してください。コード分​​割により、アプリの特定部分の読み込みを必要になるまで延期できるため、初期読み込み時間が短縮されます。

動的 import() を使用して、オンデマンドでモジュールをロードします。たとえば、ユーザーがボタンをクリックするまで特定の機能が必要ない場合は、その瞬間までその機能の読み込みを延期します。

最新のフロントエンド フレームワークは、すぐに使える遅延読み込みをサポートしているため、コード分割をワークフローに統合することがこれまでより簡単になります。

ベストプラクティスに従ってください

これは一般的なアドバイスですが、繰り返す価値があります。次のようなベスト プラクティスに従ってください。

• コードが不必要にトランスパイルされたりポリフィルされたりしないように、可能な限り最新のターゲットを使用してください。一部のポリフィルは、最新のブラウザではまったく必要のない多くのコードを追加できますが、多くの環境では依然としてデフォルトでそれらが追加されています。毎年目標を更新するリマインダーを設定することもできます。
• 依存関係を定期的に更新します。新しいバージョンの方が小さいか高速であることがよくあります。これにより、セキュリティの脆弱性や重複した依存関係に対処する必要がなくなる可能性もあります。
• すでに所有している、または追加を検討している各依存関係を評価します。サイズを正当化できない場合は、追加しないか、より小さい代替品を探してください。

エコシステム パフォーマンス (e18e) コミュニティに参加してください

Web を高速化することに興味がある場合、または単に新しいことを学ぶことに興味がある場合は、Ecosystem Performance コミュニティへの参加を検討してください。私たちは 3 つの主要な領域に重点を置いています:

• クリーンアップ — 冗長な依存関係を削除するか、最新の代替パッケージに置き換えることによってパッケージを改善します。
• スピードアップ — 広く使用されているパッケージのパフォーマンスを向上させます。
• レベルアップ — 古いパッケージに代わる最新のパッケージを構築します。

結論

この記事が、より少ないコードで同じ機能を提供できることを説明できれば幸いです。バンドルのサイズは管理しないと制御不能になる可能性がありますが、小さな変更でもパフォーマンスを大幅に向上させることができます。

今すぐ始めましょう: バンドルを分析したり、新しいツールをテストしたり、重量のあるライブラリを置き換えたりしてください。そのインパクトに驚かれることでしょう。

---

この記事を楽しんでいただければ幸いです。ご質問やコメントがある場合、または特定のトピックについて詳しく知りたい場合は、以下のコメント欄でお知らせください。 JavaScript のパフォーマンス、バンドル、ツリーシェイキングのトピックについて詳しく知りたい場合は、ここまたは BlueSky で私をフォローして、e18e コミュニティに参加してください。

以上がJavaScript のダウンサイズ: バンドラーの最適化をマスターするの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。