はじめに
本記事の目的
本記事はWebパフォーマンス指標について分かりやすく解説します。ページの表示速度や操作の滑らかさがどのようにユーザー体験やビジネス成果に影響するかを、具体例を交えて説明します。
なぜ重要か
ページが遅いと訪問者が離れ、購入や問い合わせにつながりにくくなります。例えば、読み込みに3秒以上かかると離脱が増えるという実例があります。反対に早いページは満足度とコンバージョンを高めます。
この記事で学べること
- Webパフォーマンスの基本的な定義
- Core Web Vitalsなど主要な指標の役割
- パフォーマンステストで注目すべき指標と計測ツールの使い方
読み方のポイント
専門用語はできるだけ噛み砕いて説明します。実務で使えるヒントも盛り込みますので、開発者だけでなく企画や運用の方にも役立ちます。
Webパフォーマンスとは
1. 定義と何が含まれるか
Webパフォーマンスは、ウェブサイトやアプリがどれだけ速く、快適に動くかを指します。具体的にはページの読み込み時間、画面が操作可能になるまでの時間、スクロールやクリック時の反応速度、アニメーションの滑らかさなどを総合的に評価します。
2. ユーザーが感じること（具体例）
例えば、画像が多くてページ表示が遅いとユーザーは待ちきれず離脱します。フォーム送信に時間がかかれば購入をやめるかもしれません。逆に初回表示が速く、スクロールも滑らかなら閲覧が続き、信頼感が増します。
3. 技術的な要素（わかりやすく）
主な原因は次の3つです。
– 資源のサイズ：大きな画像や未圧縮のファイルは読み込みを遅くします。
– ネットワーク遅延：サーバー応答が遅いと表示も遅れます。
– ブラウザ側の処理：複雑なスクリプトや多量のDOM操作は操作感を悪くします。
4. ビジネスへの影響
パフォーマンス低下はユーザー離脱や売上減少に直結します。短い遅延でも離脱率が上がるため、改善は投資効果が高い施策です。
5. 最初に取り組むこと
まずは代表的な遅延要因（画像最適化、不要なスクリプト削除、サーバー応答の改善）を確認し、優先度の高い部分から改善します。小さな改善がユーザー体験を大きく向上させます。
Core Web Vitals（コア ウェブ バイタルズ）
Core Web Vitalsとは
Core Web Vitalsは、ユーザー体験の要を測る指標群です。読み込みの速さ、操作に対する応答性、画面の安定性の観点から評価します。目安となる数値を使い、改善点を具体的に見つけられます。
各指標の意味と目安
- Largest Contentful Paint（LCP）
- 主要なコンテンツ（見出しや大きな画像）が表示されるまでの時間です。目安は2.5秒以下が良好です。例えばトップ画像が遅ければLCPが悪化します。
- Interaction to Next Paint（INP）
- ユーザー操作（クリックやスクロール）に対する応答性を示します。200ミリ秒未満が良好です。ボタンを押して反応が遅いとINPが悪くなります。
- Total Blocking Time（TBT）
- ページが入力に応答できない合計時間の指標で、200ミリ秒未満が望ましいです。重いスクリプトが長時間動くとTBTが増えます。
- Speed Index（SI）
- 画面に視覚的に表示される速さを示します。3.4秒以下が良好とされ、ページが見た目で速く表示されるかを評価します。
実践的な改善ポイント
- 画像は適切なサイズと遅延読み込みを使うとLCPが改善します。
- JavaScriptを分割したり、長い処理を分離するとINPやTBTが改善します。
- レイアウトの安定化にはサイズ指定（width/height）やプレースホルダーを使います。
測定のコツ
- 本番に近い環境で計測してください。ブラウザや端末で差が出ます。
- 改善は小さな変更を順に行い、指標の動きを確認すると効果が見えやすいです。
パフォーマンステストの重要指標
レスポンスタイム（応答時間）
ユーザーが操作してからシステムが返答するまでの時間です。ページ表示やAPIの応答で特に重要です。短いほど快適で、例えばページ読み込みは1秒以内、APIは数百ミリ秒が目安になります。中央値（p50）だけでなく、遅い方のp95やp99も確認します。
同時接続ユーザー数
同時にシステムを利用するユーザーの数です。負荷テストでは実際の利用状況に近い同時接続数で試すと効果的です。例えばセール時は通常より多くの同時接続を想定して検証します。段階的に増やし、どの時点で性能が落ちるかを見ます。
レイテンシ
ネットワークや処理の遅延を示します。リアルタイム性が必要なチャットや音声通話、ゲームで特に重要です。数十ミリ秒の違いが体感に影響します。ネットワーク遅延とサーバ処理時間の両方を分けて測ると原因特定が楽になります。
スループット（処理量）
単位時間あたりに処理できるリクエスト数です。高いスループットは多くの要求をさばけることを意味しますが、レスポンスが遅くなると意味がありません。レスポンス時間と合わせて評価します。
エラー率
失敗したリクエストの割合です。エラーが増えるとユーザー体験が悪化します。通常は1%以下を目標にし、増加した場合はログや監視で原因を追います。
測定時の実用ポイント
実運用に近いデータを使い、複数回の試行で結果のブレを確認します。サーバのCPU・メモリ・ネットワークも同時に監視するとボトルネックが見つかりやすくなります。
パフォーマンス計測ツール
PageSpeed Insights（PSI）
- 何をするか：URLを入力すると、実際の読み込み結果（実データ）と実験室データ（ラボデータ）を両方提示します。ページの課題を検出し、改善案をわかりやすく示します。
- 使い方：解析したいページのURLを入れて実行するだけです。結果にはLCP・FID/INP・CLSなどの指標が含まれ、どのリソースが遅いかを指摘します。
Vercel利用者向けのポイント
- Vercelはデプロイ単位でURL管理が行われるため、パスや公開日時ごとにPSIで比較できます。複数のデプロイを順に測定して、改善の効果を追跡できます。
Chrome DevTools
- Performanceパネル：ページの読み込みやユーザー操作を録画して、タイムラインやフレーム落ちを詳しく確認できます。フレームごとの処理時間やJavaScriptの実行部分（フレームチャート）を見て、どこがボトルネックか特定します。
- Networkパネル：リソースのウォーターフォール（読み込み順・時間）を確認します。大きい画像や遅いサーバ応答はここで一目でわかります。
- メモリ・JavaScript分析：Heapスナップショットやプロファイリングでメモリ使用や長時間実行する関数を見つけます。
実用的な手順（短く）
- PageSpeed Insightsでページ全体のスコアと提案を確認する。実データを優先的に見る。
- Chrome DevToolsで問題のあるページを録画し、具体的な処理時間とリソースを特定する。
- 修正後は同じ手順で再測定し、変化を比較する。
ヒント
- まずはユーザーが実際に使うページで測ること。ラボデータは再現性に便利です。
- 画像最適化、キャッシュ、不要なサードパーティの遅延読み込みを疑うと改善が早いです。
