はじめに

以下随時追記したり、埋まっていない部分もありますがご了承ください🙏

用語編(基礎)

⭐ package

パッケージとはプログラムがたくさん入ったディレクトリ/フォルダーのようなもの2であり、NPM で公開されているほとんどのパッケージは外から使うためのライブラリである。世の中にあるパッケージを使えば自分で一からコードを書かなくとも高度な機能を実現することができる。

パッケージを利用するとなったときに、「直接パッケージをダウンロードして自分のプロジェクトに含めればよいのではないか」、さらには「Git リポジトリに含めてよいのではないか」と思うかもしれない。しかし、もしそのパッケージに新しいバージョンが出て、バグ修正や機能の追加がされたとき、自分のプロジェクト内のパッケージもアップデートしたくなるかもしれない。そうすると自分のプロジェクト内のファイルを手動で更新しなければならなくなる。シェルを使えば簡単に更新できるかもしれないが、全く同じコードが複数の場所(今の場合 NPM と自分の Git リポジトリ)で管理されるというのは無駄であり、「本当に自分のプロジェクトに含まれているパッケージは NPM 上のパッケージと内容が一致しているのか」という懸念も生じる。

よって外部のパッケージは自分のプロジェクトに含めるのではなく、「このプロジェクトは NPM のこのパッケージに依存している」、という依存情報だけを「宣言」するのがよいということに落ち着く。このような依存先のパッケージをこの界隈の言葉で dependency (depend=依存する)と呼ぶ。NPM ではパッケージは別のパッケージに依存し、そのパッケージがまた別のパッケージに依存し...と、パッケージが dependency のネットワークを成すことになる。

わかりやすかったので引用: https://qiita.com/righteous/items/e5448cb2e7e11ab7d477

⭐ module

A module is just a file. One script is one module. As simple as that.
Modules can load each other and use special directives export and import to interchange functionality, call functions of one module from another one:

モジュールはただのファイルです。１つのスクリプトは１つのモジュールです。モジュールは相互に読み込んだりexportとimportを使用して機能をやりとりしたり、あるモジュールの関数を別のモジュールから呼び出したりすることができます。

For a long time, JavaScript existed without a language-level module syntax. That wasn’t a problem, because initially scripts were small and simple, so there was no need.

長い間、JavaScriptは言語レベルのモジュール構文なしで存在していました。最初はスクリプトが小さくて単純だったので、それでも問題ではありませんでした。

→ <script>タグの記述によるjs間の参照はコード量が多くなってくるにつれて煩雑になり、改善が必要となったために最初は以下のようなmodule-bundlerソリューションが生まれた。

AMD
CommonJS(Node.jsで使われている)
UMD

参考: https://javascript.info/modules-intro

⭐ module bundler

module bundlerは文字通りモジュールを一まとめにするツール。
代表格であるwebpackでも使用されており、JavaScriptの依存関係を解決し、それら全てをincludeした一つのファイルにまとめることができる。
まとめることでHTTPリクエストの数を減らしたり、高度なWebアプリケーション開発に役立つ。

module bundlerの例

browserify(単機能でシンプル)
webpack(多機能)
rollup
parcel(WEBアプリケーションバンドラ?)

参考: https://js.studio-kingdom.com/webpack/guides/code_splitting

bundle

上述したようにモジュールを一まとめにする行為を指す。

周辺用語について

(タスクランナー)

2013年ごろのフロントエンドのトレンドとして、GulpやGruntなどのタスクランナーと呼ばれるものも存在していた。
フロントエンドの仕事で面倒なタスクを自動的にやってくれる便利なツールである。
npmではnpm scriptsの機構がこれをほぼ担っている?

(ビルドツール)

単純にコンパイラ&リンカを指す場合と、ビルドを構成するタスクを定義・実行するツールを指す場合がある。
タスク例：
・ソースファイルのコンパイル
・テストや静的解析

モジュールバンドラーやタスクランナーなどの機能を備えるものは大体ビルドツールの一種と考えてもよさそう。

参考: https://alliance7.blogspot.com/2019/03/blog-post.html

⭐ webpack

At its core, webpack is a static module bundler for modern JavaScript applications. When webpack processes your application, it internally builds a dependency graph from one or more entry points and then combines every module your project needs into one or more bundles, which are static assets to serve your content from.

基本的にwebpackは最新のJavaScriptアプリケーション用の静的モジュールバンドラーです。webpackがアプリケーションを処理するとき、1つ以上のエントリポイントから依存関係グラフを内部的に構築し、プロジェクトに必要なすべてのモジュールを1つ以上のバンドルに結合します。これは、コンテンツを提供するための静的アセットです。

参考: https://webpack.js.org/concepts/

(loaderとは)

webpackは通常JavaScriptしか解析できない。
loaderを使ってJavaScript以外のファイルも解析可能にしてバンドルを行う。

⭐ chunk

「chunk: 大きい塊」
大規模なアプリケーションにおいて、全てのコードを1つのファイルに含めてしまうのは得策とは言えず、特定のコードのブロックがある階層下でしか必要とされないケースなどでそれが顕著に現れる。 webpackは必要に応じて、読み込む"chunks"(チャンク/固まり)ごとににコードを分割する機能を備えている。

Chunks come in two forms:
initial is the main chunk for the entry point. This chunk contains all the modules and their dependencies that you specify for an entry point.
non-initial is a chunk that may be lazy-loaded. It may appear when dynamic import or SplitChunksPlugin is being used.
Each chunk has a corresponding asset. The assets are the output files - the result of bundling.

チャンクには2つの形式があります。

initial: エントリポイントのメインチャンク。エントリポイントに指定する全てのモジュールとその依存関係が含まれる。
non-initial: 遅延ロードされる可能性のあるチャンク。dynamic importやSplitChunksPluginが使用されている場合に発生することがある。

参考: https://webpack.js.org/concepts/under-the-hood/#chunks

はじめに

用語編(基礎)

⭐ package

⭐ module

⭐ module bundler

bundle

周辺用語について

(タスクランナー)

(ビルドツール)

⭐ webpack

(loaderとは)

⭐ chunk

最新のビルドツール

vite

snowpack

esbuild

swc

用語編(応用)

⭐ package.json

└dependencies

└devDependencies

└(peerDependencies)

⭐ node_modules

⭐ Dynamic import

⭐ code splitting(コード分割)

code splittingのデメリット

code splittingのパターン

⭐ prefetch/preload

⭐ tree shaking

CoreWebVitals

└LCP (Largest Contentful Paint)

└FID (First Input Delay)

└CLS (Cumulative Layout Shift)

適当なライブラリのサイズを実際に見てみる

前提知識

UIライブラリ系

CSS in JS系

日付系

data fetch系

その他

webpack bundle analyzerで適当なアプリのbundleとchunkを見てみる

パフォーマンス計測/改善について

合成モニタリング

リアルユーザーモニタリング

パーセンタイルについて(p50とかp75みたいなやつ)

RAILモデル

WEBフロントエンドを高速化のための3ポイント

ネットワーク処理

レンダリング処理

スクリプト処理

ページコンテンツ表示速度に関する指標や用語について

First Paint (ページが表示され始めた時)

First Contentful Paint (コンテンツが表示され始めた時)

First Meaningful Paint (ユーザに意味のある表示になった時)

Time To Interactive (ユーザの操作に応答できるようになった時)

Time To First Byte (最初の1バイトを受信するまでの時間)

Speed Index (ATFの性能を表す)

Total Blocking Time

Interaction to Next Paint

表示速度の測定

DOMContentLoaded

load

比較サンプル

サイト例1

サイト例2

クリティカルレンダリングパス

Chrome Developer Toolについて

chrome devtoolの機能

Networkパネル

Timingタブ

🌟ConnectionStart

Performanceパネル

上部分の情報（FPS，CPU，NET，スクリーンショット，Heap）

1段目(ms表示と黄緑色グラフの部分)

2段目(黄色グラフの部分)

3段目(Netと書かれている部分)

4段目(スクリーンショット)

5段目(Heap)

Detailセクション

Bottomセクション (Summaryタブ)