この Codelab では、ユーザーがランダムな猫を評価できるこのシンプルなアプリのパフォーマンスを改善します。トランスパイルされるコードの量を最小限に抑えることで、JavaScript バンドルを最適化する方法を学習します。
サンプルアプリでは、単語や絵文字を選択してそれぞれの猫への好みを伝えることができます。ボタンをクリックすると、現在の猫の画像の下にボタンの値が表示されます。
測定
なんらかの最適化を行う前に、まずウェブサイトを調べることをおすすめします。
- サイトをプレビューするには、[アプリを表示] を押してから、全画面表示
を押します。
- `Ctrl+Shift+J`(Mac では `command+option+J)キーを押して DevTools を開きます。
- [Network] タブをクリックします。
- [キャッシュを無効にする] チェックボックスをオンにします。
- アプリを再読み込みする。
このアプリケーションでは 80 KB 超のデータを使用します。次に、バンドルの一部が使用されていないかどうかを確認します。
Control+Shift+P
(Mac ではCommand+Shift+P
)を押して [コマンド] メニューを開きます。「
Show Coverage
」と入力してEnter
を押すと、[一致率] タブが表示されます。[Coverage] タブで [再読み込み] をクリックして、カバレッジをキャプチャしながらアプリケーションを再読み込みします。
メインバンドルで使用されたコードの量と読み込まれた量を確認します。
バンドルの半分以上(44 KB)はまったく利用されていません。これは、古いブラウザでアプリが動作するように、コード内の多くのコードがポリフィルで構成されているためです。
@babel/preset-env を使用する
JavaScript 言語の構文は、ECMAScript または ECMA-262 と呼ばれる標準に準拠しています。新しいバージョンの仕様は毎年リリースされており、提案プロセスに合格した新機能が含まれています。これらの機能のサポートは、主要なブラウザごとに異なる段階にあります。
このアプリケーションでは、次の ES2015 機能が使用されます。
次の ES2017 機能も使用されます。
src/index.js
のソースコードを詳しく調べて、すべてがどのように使用されているかを確認してみてください。
これらの機能はすべて最新バージョンの Chrome でサポートされていますが、サポートしていない他のブラウザの場合はどうでしょうか。アプリに組み込まれている Babel は、新しい構文を含むコードを古いブラウザや環境が理解できるコードにコンパイルするために使用される最も一般的なライブラリです。これは次の 2 つの方法で行われます。
- 新しい ES2015 以降の関数をエミュレートするためにポリフィルが含まれているため、ブラウザでサポートされていない場合でも API を使用できます。以下に、
Array.includes
メソッドのpolyfillの例を示します。 - プラグインは、ES2015 コード(またはそれ以降)を古い ES5 構文に変換するために使用されます。これらは構文に関連する変更(アロー関数など)であるため、ポリフィルではエミュレートできません。
package.json
を参照して、どの Babel ライブラリが含まれているかを確認します。
"dependencies": {
"@babel/polyfill": "^7.0.0"
},
"devDependencies": {
//...
"babel-loader": "^8.0.2",
"@babel/core": "^7.1.0",
"@babel/preset-env": "^7.1.0",
//...
}
@babel/core
は Babel コア コンパイラです。これにより、すべての Babel 構成がプロジェクトのルートにある.babelrc
で定義されます。babel-loader
には、webpack のビルドプロセスに Babel が含まれています。
次に、webpack.config.js
を見て、babel-loader
がルールとしてどのように含まれているかを確認します。
module: { rules: [ //... { test: /\.js$/, exclude: /node_modules/, loader: "babel-loader" } ] },
@babel/polyfill
は、新しい ECMAScript 機能に必要なポリフィルをすべて提供し、それをサポートしていない環境でも動作できるようにします。src/index.js.
の一番上にすでにインポートされています。
import "./style.css";
import "@babel/polyfill";
@babel/preset-env
には、ターゲットとして選択されたブラウザまたは環境に必要な変換とポリフィルを指定します。
Babel 構成ファイル .babelrc
を見て、その内容を確認します。
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions"
}
]
]
}
Babel と webpack の設定です。webpack と異なるモジュール バンドラを使用する場合は、アプリケーションに Babel を含める方法をご確認ください。
.babelrc
の targets
属性は、対象となるブラウザを示します。@babel/preset-env
は browserlist と統合されています。つまり、このフィールドで使用できる互換性のあるクエリの一覧については、browserlist のドキュメントをご覧ください。
"last 2 versions"
値を指定すると、すべてのブラウザの直近 2 つのバージョンについて、アプリ内のコードがトランスパイルされます。
デバッグ
ブラウザのすべての Babel ターゲットと、含まれているすべての変換とポリフィルを完全に確認するには、debug
フィールドを .babelrc:
に追加します。
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions",
"debug": true
}
]
]
}
- [ツール] をクリックします。
- [ログ] をクリックします。
アプリを再読み込みし、エディタの下部にある Glitch ステータス ログを確認します。
ターゲット ブラウザ
Babel は、コンパイル プロセスに関する詳細情報をコンソールに記録します。ログには、コードがコンパイルされたすべてのターゲット環境が含まれます。
このリストには、Internet Explorer などの廃止されたブラウザも含まれています。サポートされていないブラウザには新しい機能が追加されず、Babel はそのブラウザ向けに特定の構文をトランスパイルし続けるため、これは問題です。ユーザーがこのブラウザを使用してサイトにアクセスしない場合、バンドルのサイズが必要以上に大きくなります。
Babel は、使用されている変換プラグインのリストもログに記録します。
かなり長いリストです。これらは、すべての対象ブラウザで ES2015+ 構文を古い構文に変換するために Babel が使用する必要があるプラグインです。
ただし、Babel で使用されている特定のポリフィルは表示されません。
これは、@babel/polyfill
全体が直接インポートされるためです。
ポリフィルを個別に読み込む
デフォルトでは、Babel は @babel/polyfill
をファイルにインポートするときに、完全な ES2015+ 環境に必要なすべてのポリフィルを含めます。対象のブラウザに必要な特定のポリフィルをインポートするには、構成に useBuiltIns: 'entry'
を追加します。
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions",
"debug": true
"useBuiltIns": "entry"
}
]
]
}
アプリケーションを再読み込みする。含まれるすべての特定のポリフィルを表示できるようになりました。
"last 2 versions"
に必要なポリフィルのみが追加されましたが、それでも非常に長いリストです。これは、新しい機能ごとに対象ブラウザに必要なポリフィルがまだ含まれているためです。属性の値を usage
に変更し、コード内で使用されている機能に必要な要素のみが含まれるようにします。
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions",
"debug": true,
"useBuiltIns": "entry"
"useBuiltIns": "usage"
}
]
]
}
これにより、必要に応じてポリフィルが自動的に含まれます。つまり、src/index.js.
の @babel/polyfill
インポートを削除できます。
import "./style.css";
import "@babel/polyfill";
これで、アプリケーションに必要なポリフィルのみが含まれるようになりました。
アプリケーション バンドルのサイズが大幅に削減されました。
サポートされているブラウザのリストを絞り込む
含まれるブラウザ ターゲットの数は依然として非常に多く、Internet Explorer などの廃止されたブラウザを使用するユーザーは多くありません。構成を次のように更新します。
{
"presets": [
[
"@babel/preset-env",
{
"targets": "last 2 versions",
"targets": [">0.25%", "not ie 11"],
"debug": true,
"useBuiltIns": "usage",
}
]
]
}
取得したバンドルの詳細を確認します。
アプリケーションは非常に小さいため、これらの変更による違いはほとんどありません。ただし、ブラウザのマーケット シェアの割合(">0.25%"
など)を使用するとともに、ユーザーが使用していないことが確実な特定のブラウザを除外することをおすすめします。詳しくは、James Kyle による「最後の 2 つのバージョン」は有害とみなされる記事をご覧ください。
<script type="module"> を使用する
まだ改善の余地があります。多数の未使用のポリフィルが削除されましたが、一部のブラウザでは不要なポリフィルも多数リリースされています。モジュールを使用すると、不要なポリフィルを使用せずに新しい構文を直接記述してブラウザに提供できます。
JavaScript モジュールは、すべての主要なブラウザでサポートされている比較的新しい機能です。type="module"
属性を使用してモジュールを作成すると、他のモジュールからインポートおよびエクスポートするスクリプトを定義できます。例:
// math.mjs
export const add = (x, y) => x + y;
<!-- index.html -->
<script type="module">
import { add } from './math.mjs';
add(5, 2); // 7
</script>
新しい ECMAScript 機能の多くは、JavaScript モジュールをサポートする環境ですでにサポートされています(Babel は必要ありません)。つまり、Babel 構成を変更して、2 つの異なるバージョンのアプリケーションをブラウザに送信することができます。
- モジュールをサポートする新しいブラウザで動作し、大部分がトランスパイルされていないがファイルサイズが小さいモジュールを含むバージョン
- 従来のブラウザで動作する、大型のトランスパイルされたスクリプトを含むバージョン
Babel での ES モジュールの使用
アプリケーションの 2 つのバージョンに対して個別の @babel/preset-env
設定を指定するには、.babelrc
ファイルを削除します。アプリケーションのバージョンごとに 2 つの異なるコンパイル形式を指定することで、webpack の構成に Babel 設定を追加できます。
まず、以前のスクリプトの構成を webpack.config.js
に追加します。
const legacyConfig = {
entry,
output: {
path: path.resolve(__dirname, "public"),
filename: "[name].bundle.js"
},
module: {
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
loader: "babel-loader",
options: {
presets: [
["@babel/preset-env", {
useBuiltIns: "usage",
targets: {
esmodules: false
}
}]
]
}
},
cssRule
]
},
plugins
}
"@babel/preset-env"
に targets
値を使用する代わりに、値が false
の esmodules
が使用されます。つまり、Babel には、まだ ES モジュールをサポートしていないすべてのブラウザを対象にするために必要な変換とポリフィルがすべて含まれています。
webpack.config.js
ファイルの先頭に、entry
、cssRule
、corePlugins
の各オブジェクトを追加します。これらはすべて、ブラウザに提供されるモジュールとレガシー スクリプトの両方で共有されます。
const entry = {
main: "./src"
};
const cssRule = {
test: /\.css$/,
use: ExtractTextPlugin.extract({
fallback: "style-loader",
use: "css-loader"
})
};
const plugins = [
new ExtractTextPlugin({filename: "[name].css", allChunks: true}),
new HtmlWebpackPlugin({template: "./src/index.html"})
];
同様に、legacyConfig
が定義されたモジュール スクリプト用の config オブジェクトを作成します。
const moduleConfig = {
entry,
output: {
path: path.resolve(__dirname, "public"),
filename: "[name].mjs"
},
module: {
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
loader: "babel-loader",
options: {
presets: [
["@babel/preset-env", {
useBuiltIns: "usage",
targets: {
esmodules: true
}
}]
]
}
},
cssRule
]
},
plugins
}
ここでの主な違いは、出力ファイル名に .mjs
ファイル拡張子が使用される点です。ここでは esmodules
値が true に設定されています。つまり、このモジュールに出力されるコードはサイズが小さく、コンパイル度が低いスクリプトであり、この例では変換処理を一切行いません。使用される機能は、モジュールをサポートするブラウザですでにサポートされているためです。
ファイルの最後に、両方の構成を 1 つの配列としてエクスポートします。
module.exports = [
legacyConfig, moduleConfig
];
これにより、サポートしているブラウザには小さなモジュールがビルドされ、古いブラウザにはトランスパイルされたスクリプトが大きくなります。
モジュールをサポートするブラウザは、nomodule
属性を含むスクリプトを無視します。逆に、モジュールをサポートしていないブラウザは、type="module"
を含むスクリプト要素を無視します。つまり、モジュールとコンパイル済みフォールバックを含めることができます。理想的には、アプリの 2 つのバージョンは、次のように index.html
内にある必要があります。
<script type="module" src="main.mjs"></script>
<script nomodule src="main.bundle.js"></script>
モジュールをサポートするブラウザは、main.mjs
を取得して実行し、main.bundle.js.
を無視します。モジュールをサポートしていないブラウザでは、この逆の処理が行われます。
通常のスクリプトとは異なり、モジュールのスクリプトは常にデフォルトで遅延されることに留意してください。同等の nomodule
スクリプトも遅延させ、解析後にのみ実行する場合は、defer
属性を追加する必要があります。
<script type="module" src="main.mjs"></script>
<script nomodule src="main.bundle.js" defer></script>
最後に行う必要があるのは、module
属性と nomodule
属性をそれぞれモジュールと以前のスクリプトに追加することです。webpack.config.js
の一番上に ScriptExtHtmlWebpackPlugin をインポートします。
const path = require("path");
const webpack = require("webpack");
const HtmlWebpackPlugin = require("html-webpack-plugin");
const ScriptExtHtmlWebpackPlugin = require("script-ext-html-webpack-plugin");
構成の plugins
配列を更新して、このプラグインを含めます。
const plugins = [ new ExtractTextPlugin({filename: "[name].css", allChunks: true}), new HtmlWebpackPlugin({template: "./src/index.html"}), new ScriptExtHtmlWebpackPlugin({ module: /\.mjs$/, custom: [ { test: /\.js$/, attribute: 'nomodule', value: '' }, ] }) ];
これらのプラグイン設定では、すべての .mjs
スクリプト要素に type="module"
属性が追加され、すべての .js
スクリプト モジュールに nomodule
属性が追加されます。
HTML ドキュメントでモジュールを配信する
最後に必要な作業は、従来のスクリプト要素と最新のスクリプト要素の両方を HTML ファイルに出力することです。残念ながら、最終的な HTML ファイル HTMLWebpackPlugin
を作成するプラグインは現在のところ、モジュール スクリプトと nomodule スクリプトの両方の出力をサポートしていません。BabelMultiTargetPlugin や HTMLWebpackMultiBuildPlugin など、この問題を解決するための回避策や個別のプラグインが用意されていますが、このチュートリアルでは、モジュールのスクリプト要素を手動で追加するより簡単なアプローチを使用しています。
src/index.js
のファイルの末尾に次のコードを追加します。
...
</form>
<script type="module" src="main.mjs"></script>
</body>
</html>
次に、Chrome の最新バージョンなど、モジュールをサポートするブラウザにアプリケーションを読み込みます。
モジュールのみがフェッチされます。大部分がトランスパイルされないため、バンドルサイズははるかに小さくなります。他のスクリプト要素は、ブラウザによって完全に無視されます。
古いブラウザでアプリケーションを読み込む場合は、必要なポリフィルと変換をすべて含む、大型のトランスパイルされたスクリプトのみが取得されます。こちらは、古いバージョンの Chrome(バージョン 38)で行われたすべてのリクエストのスクリーンショットです。
まとめ
ここでは、@babel/preset-env
を使用して、対象ブラウザに必要なポリフィルのみを提供する方法を学習しました。また、JavaScript モジュールがアプリケーションの 2 つの異なるトランスパイル バージョンを配布することにより、パフォーマンスをさらに向上させる方法についても理解しました。これらの方法でバンドルサイズを大幅に削減する方法を十分に理解したうえで最適化に進みましょう。