導入
Web制作の現場で「サイトの表示速度を上げたい」というオーダーは日常茶飯事ですが、皆さんは何を指標にしていますか？多くの方が「Page load time（読み込み時間）」を改善目標に設定しがちですが、実はこれだけを追うのは非常に危険です。ユーザーが体感する「速さ」と、ブラウザの読み込み完了時間は必ずしも一致しません。本記事では、なぜPage load timeが絶対的な指標ではないのか、そして現場で本当に注視すべき指標と実装方法について解説します。
基礎知識
「Page load time」とは、ナビゲーション開始からloadイベントが発火するまでの時間を指します。しかし、この数値は「サーバーからの応答速度」や「デバイスのスペック」「ネットワーク環境」に大きく左右されます。
重要なのは、ユーザーが「表示された！」と感じるまでの「知覚性能（Perceived performance）」です。現在はGoogleが提唱する「Core Web Vitals（LCP、INP、CLS）」のように、ユーザー体験に直結する指標を重視することが、SEOおよびUX向上の鉄則となっています。
実装/解決策
ブラウザの読み込み完了を待つのではなく、ユーザー体験を定量化するために、ブラウザ標準の「Performance API」を活用しましょう。これにより、開発環境ではなく、実際のユーザーのブラウザ上でどの程度の時間がかかっているかを計測できます。
サンプルプログラム
以下のコードは、ページが完全に表示されるまでの時間を計測し、コンソールに出力するシンプルな実装です。実務ではこれをGoogle Analyticsなどのイベントトラッキングに送ることで、実際のユーザー環境のパフォーマンスを把握できます。
// ページ読み込み完了後に計測処理を実行
window.addEventListener('load', () => {
// Navigation Timing APIを使用して時間を取得
const [navigationEntry] = performance.getEntriesByType('navigation');
if (navigationEntry) {
// loadEventEnd: loadイベントが終了した時間
// startTime: ナビゲーション開始時間
const pageLoadTime = navigationEntry.loadEventEnd - navigationEntry.startTime;
console.log("今回のページ読み込み時間: " + Math.round(pageLoadTime) + "ms");
// 応用: 3000msを超えていたら警告を出すなどのログ収集が可能
if (pageLoadTime > 3000) {
console.warn("注意: 表示に3秒以上かかっています。最適化の検討が必要です。");
}
}
});
応用・注意点
現場で陥りがちなミスとして「開発環境の数値だけで満足してしまうこと」が挙げられます。高速な光回線と最新PCで計測した数値は、低速なモバイル回線を利用しているユーザーの実態とはかけ離れています。
現場で役立つ回避策：
1. Lighthouseを活用する： Chrome DevToolsのLighthouseを使用し、モバイルシミュレーション（Slow 4Gなど）で計測を行ってください。
2. 画像最適化の徹底： Page load timeの多くは画像読み込みが占めています。WebPへの変換、適切なサイズ指定（srcset属性）、遅延読み込み（loading=”lazy”）は必須です。
3. 不要なJavaScriptの削除： loadイベントを遅延させる原因の多くは、肥大化したJSライブラリです。本当に必要なもの以外はasync/defer属性を適切に付与し、メインスレッドをブロックしないようにしましょう。
「Page load time」を一つの目安にしつつ、ユーザーがどれだけストレスなく操作を開始できるかという「インタラクティブ性」にも目を向けることが、シニアデザイナーとして求められる視点です。
コメント