本番環境
Parcelのproductionモードは、アプリケーションを本番環境向けに自動的にバンドルし、最適化します。 parcel build
コマンドを使用して実行できます。
parcel build src/index.html
サイズ最適化
#Parcelには、バンドルサイズを削減するために設計された多くの最適化が含まれています。自動ミニファイ、ツリーシェイキング、画像の最適化などです。
ミニファイ
#Parcelには、JavaScript、CSS、HTML、SVGのミニファイアーがデフォルトで含まれています。ミニファイは、空白を削除し、変数名を短い名前に変更するなど、多くの最適化を行うことで、出力バンドルのファイルサイズを削減します。
デフォルトでは、parcel build
コマンドを使用するとミニファイが有効になります。必要に応じて、--no-optimize
CLIフラグを使用してミニファイとその他の最適化を無効にすることができます。
ParcelはJavaScriptのミニファイにSWCを、CSSにlightningcssを、HTMLにhtmlnanoを、SVGにsvgoを使用します。必要に応じて、.terserrc
、.htmlnanorc
、またはsvgo.config.json
設定ファイルを使用してこれらのツールを設定できます。詳細については、JavaScript、CSS、HTML、SVGのドキュメントを参照してください。
ツリーシェイキング
#本番ビルドでは、Parcelは各モジュールのインポートとエクスポートを静的に分析し、使用されていないものをすべて削除します。これは「ツリーシェイキング」または「デッドコードの削除」と呼ばれます。ツリーシェイキングは、静的および動的なimport()
、CommonJSおよびESモジュール、さらにはCSSモジュールを使用した言語間でもサポートされています。
また、Parcelは可能な場合、各モジュールを個別の関数でラップするのではなく、モジュールを単一のスコープに連結します。これは「スコープホイスト」と呼ばれます。これは、ミニファイの効果を高め、モジュール間の参照を動的なオブジェクトルックアップではなく静的にすることで、ランタイムのパフォーマンスを向上させます。
ツリーシェイキングをより効果的にするためのヒントについては、スコープホイストのドキュメントを参照してください。
開発ブランチの削除
#parcel build
は、NODE_ENV
環境変数を自動的に production
に設定します。この環境変数は、ライブラリで本番ビルドでバンドルサイズを削減するために削除できる開発専用のデバッグ機能を有効にするためによく使用されます。Parcelはこの環境変数をインライン化し、比較を最適化してデッドブランチを削除します。
独自のコードでもこの機能を利用できます。たとえば、if文を使用してNODE_ENV
環境変数をチェックできます。
if (process.env.NODE_ENV !== 'production') {
// Only runs in development and will be stripped in production builds.
}
環境変数のインライン化の詳細については、Nodeエミュレーションのドキュメントを参照してください。
画像の最適化
#Parcelは、画像のサイズ変更、変換、最適化をサポートしています。HTML、CSS、またはJavaScriptで画像を参照するときにクエリパラメータを使用して、画像を変換する形式とサイズを指定できます。同じソース画像から複数のサイズまたは形式をリクエストできます。これにより、さまざまなタイプのデバイスまたはブラウザを効率的にサポートできます。
<picture>
<source type="image/webp" srcset="image.jpg?as=webp&width=400, image.jpg?as=webp&width=800 2x">
<source type="image/jpeg" srcset="image.jpg?width=400, image.jpg?width=800 2x">
<img src="image.jpg?width=400" width="400">
</picture>
画像のサイズ変更と変換は、開発モードと本番モードの両方で行われるため、正しい画像の寸法と形式でテストすることもできます。詳細については、画像トランスフォーマーのドキュメントを参照してください。
Parcelは、本番モードでJPEGおよびPNGのロスレス画像最適化をデフォルトで含んでいます。これにより、画質に影響を与えることなく画像のサイズが削減されます。これを使用するためにクエリパラメータや設定は必要ありません。ただし、最適化はロスレスであるため、可能なサイズ削減は、`quality` クエリパラメータを使用するか、WebPやAVIFなどの最新の形式を使用する場合よりも少ない場合があります。
差分バンドル
#Parcelは、最新のJavaScript構文を含む `<script type="module">` と、必要に応じて古いブラウザ向けのフォールバック `<script nomodule>` を自動的に生成します。これにより、クラス、async/awaitなどの機能のトランスパイルを回避することで、大多数のユーザーのバンドルサイズが削減されます。詳細については、ターゲットドキュメントの差分バンドルを参照してください。
圧縮
#Parcelは、GzipとBrotliを使用したバンドルの圧縮をサポートしています。多くのサーバーはオンザフライでデータを圧縮しますが、事前に圧縮されたペイロードを事前にアップロードする必要があるサーバーもあります。これにより、すべてのネットワークリクエストで実行するには遅すぎる、より良い圧縮が可能になる場合もあります。
すべての人がそれを必要とするわけではないため、圧縮はデフォルトでは有効になっていません。有効にするには、`.parcelrc` に `@parcel/compressor-gzip` および/または `@parcel/compressor-brotli` を追加します。
yarn add @parcel/compressor-gzip @parcel/compressor-brotli --dev
{
"compressors": {
"*.{html,css,js,svg,map}": [
"...",
"@parcel/compressor-gzip",
"@parcel/compressor-brotli"
]
}
}
これで、元の圧縮されていないバンドルと一緒に `.gz` ファイルと `.br` ファイルが取得されます。上記の例にリストされているよりも多くのテキストベースのファイルタイプがある場合は、それに応じてglobを拡張する必要があります。
圧縮されていないバンドルが必要ない場合は、上記の例から `"..."` を削除して、*圧縮ファイルのみ*を出力することもできます。たとえば、`.gz` ファイルのみを出力するには、次の設定を使用できます。
{
"compressors": {
"*.{html,css,js,svg,map}": ["@parcel/compressor-gzip"]
}
}
キャッシュの最適化
#Parcelには、コンテンツハッシュ、バンドルマニフェスト、共有バンドルなど、ブラウザとCDNのキャッシュに関連するいくつかの最適化が含まれています。
コンテンツハッシュ
#Parcelは、すべての出力ファイルの名前にコンテンツハッシュを自動的に含めます。これにより、長期的なブラウザキャッシュが可能になります。バンドルの内容が変更されるたびに、ファイル名に含まれるハッシュが更新され、CDNおよびブラウザキャッシュの無効化がトリガーされます。
デフォルトでは、すべてのバンドルには、エントリと名前が安定している必要がある特定の依存関係タイプを除いて、コンテンツハッシュが含まれています。たとえば、サービスワーカーは正常に機能するために安定したファイル名が必要であり、HTMLの `<a>` タグはユーザーが判読できるURLを参照します。
`--no-content-hash` CLIフラグを使用してコンテンツハッシュを無効にすることもできます。名前にはまだハッシュが含まれますが、ビルドごとに変更されることはありません。 ネーミングプラグインを使用して、バンドルのネーミングを完全にカスタマイズできます。
カスケード無効化
#Parcelは、各エントリバンドルでマニフェストを使用して、多くの場合カスケード無効化の問題を回避します。このマニフェストには、安定したバンドルIDから最終的なコンテンツハッシュファイル名へのマッピングが含まれています。1つのバンドルが別のバンドルを参照する必要がある場合、コンテンツハッシュ名ではなくバンドルIDを使用します。これは、バンドルが更新されると、そのバンドルとエントリのみをブラウザキャッシュで無効化する必要があり、中間バンドルは変更されないことを意味します。これにより、デプロイメント全体のキャッシュヒット率が向上します。
エントリバンドルのサイズがしきい値(デフォルトでは100 KB)を超えると、マニフェストは自動的に個別のバンドルに分割されます。マニフェストはビルドごとに変更されるため、エントリ内の他のコードが変更されていない場合でも、エントリバンドル全体が無効になるのを回避できます。これは、ユーザーが更新を受信するためにダウンロードする必要があるバイト数を削減するのに役立ちます。マニフェストを独自のバンドルに分割するサイズしきい値は、プロジェクトルートの `package.json` ファイルで設定できます。ミニファイ前のバイト単位で定義されます。
{
"@parcel/runtime-js": {
"splitManifestThreshold": 10000
}
}
共有バンドル
#本番ビルドでは、Parcelはアプリケーションのバンドルグラフを自動的に最適化して、重複を削減し、キャッシュ可能性を向上させます。アプリケーションの複数の部分が同じ共通モジュールに依存している場合、それらは自動的に個別のバンドルに重複排除されます。これにより、よく使用される依存関係をアプリケーションコードと並行してロードし、ブラウザで個別にキャッシュできます。
たとえば、アプリの複数のページが `react` と `lodash` に依存している場合、それらは各ページで複製されるのではなく、個別のバンドルに移動される可能性があります。こうすることで、ユーザーがあるページから別のページに移動したときに、既にキャッシュされているライブラリを再ダウンロードするのではなく、そのページの追加コードのみをダウンロードする必要があります。
これを設定する方法の詳細については、コード分割のドキュメントを参照してください。
バンドルサイズの分析
#Parcelには、バンドルサイズを分析するのに役立つツールがいくつか含まれています。
詳細レポート
#Parcelは、デフォルトで本番ビルド時にターミナルにバンドルレポートを出力します。レポートには、各出力バンドルのサイズとビルド時間が含まれます。各バンドルを構成するファイルの詳細を確認するには、--detailed-report
CLIオプションを使用します。デフォルトでは、各バンドル内の最大10個のファイルがサイズ順に表示されます。この数を増やすには、数値を渡すこともできます。例:--detailed-report 20
。
バンドルアナライザー
#@parcel/reporter-bundle-analyzer
プラグインを使用すると、各バンドル内の各アセットの相対サイズを視覚的に示すツリーマップを含むHTMLファイルを生成できます。 --reporter
CLIオプションを使用して実行できます。
parcel build src/index.html --reporter @parcel/reporter-bundle-analyzer
これにより、プロジェクトルートに、すべてのターゲットのHTMLファイルを含む`parcel-bundle-reports`フォルダが生成されます。
すべてのビルドでバンドルアナライザーを自動的に実行する場合は、.parcelrc
ファイルの"reporters"
にこれを追加することもできます。
バンドルバディ
#@parcel/reporter-bundle-buddy
プラグインを使用すると、Bundle Buddyと互換性のあるレポートを生成できます。 --reporter
CLIオプションを使用して実行できます。
parcel build src/index.html --reporter @parcel/reporter-bundle-buddy
生成された`dist`ディレクトリ内のファイルをBundle Buddyのウェブサイトにアップロードします。