Performance API は「なんとなく速い／遅い」を数字にするための道具
「このページ、なんか重いな…」
「この処理、体感遅いけど、どれくらい遅いんだろう？」
Performance API は、
こういう“なんとなく”を 数字で測るためのメジャー です。
ページの読み込みに何ミリ秒かかったか
ある関数の実行に何ミリ秒かかったか
ユーザーが操作してから画面が反応するまで何ミリ秒かかったか
こういう「時間」を、ブラウザが細かく教えてくれます。
プログラミングが上手い人ほど、
「感覚」ではなく「数字」でパフォーマンスを語ります。
Performance API は、そのための入り口です。
一番最初に覚えるべきは performance.now()
Date.now() との違いをちゃんと理解する
JavaScript で時間を測るとき、
最初に思いつくのは Date.now() かもしれません。
const start = Date.now();
// 重い処理
const end = Date.now();
console.log(`かかった時間: ${end - start} ms`);
これでも一応測れますが、
Performance API の performance.now() の方が、
パフォーマンス計測には向いています。
const start = performance.now();
// 重い処理
const end = performance.now();
console.log(`かかった時間: ${end - start} ms`);
違いはざっくりこうです。
Date.now()
現在時刻（1970 年からのミリ秒）
精度はそこまで高くない（ミリ秒単位）
performance.now()
ページが開かれてからの経過時間（ミリ秒）
小数点以下までの高精度（マイクロ秒レベル）
パフォーマンスを測るときに欲しいのは
「今何時か」ではなく「どれくらい時間がかかったか」なので、performance.now() を使うのが基本 だと思ってください。
関数の処理時間を測るミニ例
「この処理、どれくらい重いの？」を数字で見る
例えば、配列をソートする処理の時間を測ってみます。
function heavyTask() {
const arr = [];
for (let i = 0; i < 200000; i++) {
arr.push(Math.random());
}
arr.sort();
}
const start = performance.now();
heavyTask();
const end = performance.now();
console.log(`heavyTask にかかった時間: ${(end - start).toFixed(2)} ms`);
ここでやっていることはシンプルです。
処理の前に performance.now() を呼ぶ
処理の後にもう一度呼ぶ
差分を取って「かかった時間」を出す
これだけで、
「この処理はだいたい 50ms くらいかかるのか」
「100ms 超えると体感ちょっと重いな」
みたいな感覚が、数字とセットで 身についていきます。
重要なのは、
「なんとなく重い」から「この処理は平均 80ms」へ
頭のモードを切り替えることです。
ページ読み込みのタイミングを知る PerformanceTiming 系
「ページがどこで時間を食っているか」をざっくり見る
ページ全体の読み込み時間を知りたいときは、performance.timing（古い API）やperformance.getEntriesByType("navigation")（新しい API）を使います。
まずは新しめの書き方から。
const [nav] = performance.getEntriesByType("navigation");
console.log("全体のロード時間:", nav.duration, "ms");
console.log("DOM 構築完了まで:", nav.domComplete - nav.startTime, "ms");
nav には、ページ読み込みに関するいろいろなタイミングが入っています。
nav.duration
ページのナビゲーション開始からロード完了までの時間
nav.domComplete
DOM の構築が完了したタイミング
nav.startTime
ナビゲーションの開始（通常 0）
ここから、
「ネットワークが遅いのか」
「JavaScript の実行が重いのか」
「画像の読み込みで詰まっているのか」
といったことを、少しずつ分解していけます。
初心者のうちは、まず
nav.duration（ページ全体のロード時間）nav.domComplete（DOM 完成までの時間）
このあたりを眺めて、
「自分のページ、だいたい何 ms くらいで開いてるんだろう？」
と感覚を掴むだけでも十分価値があります。
performance.mark / performance.measure で「区間」に名前をつける
「ここからここまで」をラベル付きで測る
performance.now() で前後を測るのもいいですが、
もう少し整理されたやり方としてperformance.mark と performance.measure があります。
イメージとしては、
ここがスタート地点（mark）
ここがゴール地点（mark）
スタートとゴールの間を measure で測る
という感じです。
performance.mark("task-start");
doSomethingHeavy();
performance.mark("task-end");
performance.measure("task-duration", "task-start", "task-end");
const measures = performance.getEntriesByName("task-duration");
const m = measures[0];
console.log(`doSomethingHeavy の時間: ${m.duration.toFixed(2)} ms`);
ここでのポイントは、
「どの処理を測っているか」に名前をつけられる
あとから getEntriesByName でまとめて取り出せる
ということです。
大きめのアプリになると、
API 呼び出し
画面の描画
初期化処理
など、いろんな場所で時間を測りたくなります。
そのときに「名前付きの区間」として管理できると、
「どこがボトルネックか」を整理して見つけやすくなる んです。
PerformanceObserver で「パフォーマンスイベント」を監視する
「何か起きたら教えてもらう」スタイル
Performance API には、PerformanceObserver という「監視役」もいます。
これは、
リソースの読み込み（画像・スクリプトなど）
ナビゲーション（ページ遷移）
長いタスク（Long Task）
などの「パフォーマンスイベント」が発生したときに、
通知を受け取る仕組みです。
例えば、「長すぎるタスク」を検出する例。
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(
"Long Task 発生:",
entry.duration.toFixed(2),
"ms",
"開始時刻:",
entry.startTime.toFixed(2)
);
}
});
observer.observe({ entryTypes: ["longtask"] });
「Long Task」とは、
メインスレッドを 50ms 以上占有してしまう処理のことです。
これが多いと、
スクロールがカクつく
クリックしても反応が遅い
といった「体感の重さ」につながります。
PerformanceObserver を使うと、
「どこで 50ms 以上の重い処理が走っているか」 を
自動でログに出せるようになります。
初心者のうちは、
「へえ、こうやって“重い瞬間”を検出できるんだ」
くらいの理解で十分です。
「パフォーマンスを測る」ことの本質
感覚ではなく、数字で会話できるようになる
Performance API の一番大事な価値は、
「議論を感覚から数字に引き上げる」 ことです。
「この画面、なんか重い気がする」
よりも、
「この画面の初期描画に平均 800ms かかっている」
と言えた方が、圧倒的に強いです。
さらに、
「API 呼び出しに 500ms、描画に 300ms かかっている」
「API はどうにもならないから、描画を 150ms まで削ろう」
というふうに、
「どこを改善すべきか」 が見えてきます。
パフォーマンスの世界では、
測る → 数字を見る → 仮説を立てる → 直す → もう一度測る
というサイクルを回せる人が強いです。
Performance API は、そのサイクルの「測る」を支える道具です。
初心者として Performance API でまずやってみてほしいこと
いきなり全部を完璧に理解する必要はありません。
最初の一歩として、次の 3 つだけやってみてください。
関数の処理時間を performance.now() で測ってみる
ページ読み込み後に performance.getEntriesByType("navigation") を console.log して眺めてみる
「重そうだな」と思う処理に performance.mark / performance.measure を挟んでみる
これだけでも、
「自分のコードがどれくらいの時間を食っているのか」
「ページ全体がどれくらいで開いているのか」
が、ぼんやりではなく 数字で 見えてきます。
そこから先は、
「この数字をどう減らすか」を考えるフェーズです。
それはもう、立派な“パフォーマンスチューニング”の世界です。
あなたが「なんか重い」から一歩進んで
「この処理は 120ms、ここを 60ms にしたい」と言えるようになったら、
それだけでエンジニアとしての視界が一段上がっています。
