遅く感じる瞬間を特定する
商品一覧がすぐに表示されるのに、価格フィルターを変更すると処理が止まる場面を考えてみましょう。別のページでは、フィルターにはすぐ反応するものの、プロモーションバナーが表示されたときにコンテンツ全体が下へずれるかもしれません。どちらも不安定に感じますが、根本の問題は大きく異なる可能性があります。
操作と画面上の反応を書き留めます。たとえば「価格帯を選んでも、処理中の表示がなく、前の商品がそのまま表示される」という具合です。「商品一覧が遅い」よりも具体的で、画像圧縮ですべての遅延が解決すると思い込まずに済みます。
症状に合った指標を使う
Largest Contentful Paint（LCP）は読み込み、Interaction to Next Paint（INP）は応答性、Cumulative Layout Shift（CLS）は視覚的な安定性に関する指標です。これらのCore Web Vitalsは体験の異なる側面を示すため、ひとつの数値が良好でも、ページ全体が速く感じられるとは限りません。
商品一覧では、初回の読み込みだけでなく、操作の前後に何が起きるかも確認します。ブラウザーが応答できるようになるまでの時間と、絞り込み結果を待つ時間は、同じ作業に関係していますが、置き換えて考えられる指標ではありません。
原因に対処する変更を選ぶ
メイン画像の表示が遅い場合は、ファイルサイズだけでなく、ブラウザーが画像を認識するタイミングや配信方法を調べます。タップ後に画面が反応しないなら、その操作で実行される処理を確認します。バナーによって既存のコンテンツが動くなら、あらかじめ表示領域を確保する方法を検討しましょう。
操作へのフィードバックも大切です。処理中の表示があれば、操作が進行中だと伝えられますが、処理そのものが速くなるわけではありません。見た目の改善によってパフォーマンスの問題まで解決したことにしないよう、両者を区別しましょう。
比較条件を確認する
キャッシュが温まった状態のデスクトップ測定と、通信環境に制約のあるスマートフォンでの初回訪問では、分かることが異なります。最適化の前後を比べるときは、ページ、端末、ネットワーク環境、キャッシュの状態を記録してください。条件が変わっただけなのに、実装が変わったと誤解するのを防げます。
条件を管理した測定は、原因の調査に役立ちます。十分なデータがあれば、実際の訪問者の幅広い状況はフィールドデータで確認できます。それぞれの目的に合わせて両方を使い、1回うまくいった測定だけで、すべての訪問者にとって速いと結論づけないようにしましょう。