Webパフォーマンス最適化
Web Performance Optimizationうぇぶ・ぱふぉーまんす・さいてきか
Webパフォーマンス最適化とは、サイトの表示速度と操作の快適さを、実際の利用者から得られた数値にもとづいて改善する取り組みのこと。内容を読んでもらう前に離脱されている分を取り戻す作業であり、記事や広告に投資する前の土台になります。
読まれなかったのではなく、表示される前に閉じられている
サイトの成果が伸びないとき、原因は文章や構成に求められがちです。しかし実際には、本文が画面に出る前に閉じられているケースが相当数あります。とくに影響が大きいのはスマートフォンからの流入です。電車の中や外出先の回線は、オフィスの光回線とは条件がまったく違います。制作した本人はPCの高速な環境で確認しているため、この差に気づけません。「自分の環境では普通に見える」という感覚が、最も判断を誤らせます。
Googleは、この「体感の速さ」を測るための指標としてコアウェブバイタルを定義しています。中身は3つです。LCP（Largest Contentful Paint）は、画面の中で最も大きな要素が表示されるまでの時間。良好とされる基準は2.5秒以内です。INP（Interaction to Next Paint）は、タップやクリックに画面が反応するまでの時間で、良好の基準は200ミリ秒以内。2024年3月に、それまでのFIDに代わってコアウェブバイタルの指標となりました。CLS（Cumulative Layout Shift）は、読み込み途中でレイアウトがずれる量を示し、良好の基準は0.1以下です。押そうとしたボタンが広告の読み込みでずれて別の場所を押してしまう、あの現象を数値化したものだと考えると分かりやすくなります。これらはページの体験を評価する要素として検索でも使われますが、順位のためだけの指標ではありません。3つとも「訪問者が不快に感じる瞬間」を測っている点に意味があります。
もうひとつ重要なのが、測定データには2種類あるという点です。PageSpeed InsightsやLighthouseで得られるのは、決まった条件で試験的に測った値（ラボデータ）。Search Consoleのレポートで見られるのは、実際にサイトを訪れた人の端末から集まった値（フィールドデータ）です。改善の優先順位を決めるときは後者を見ます。試験環境で90点でも、実際の利用者の回線と端末では基準を外していることがあるからです。逆に、ラボの点数を満点に近づけること自体を目的にすると、成果に結びつかない細かな調整に時間を使うことになります。見るべきは点数ではなく、実利用者のデータで基準を外している指標がどれか、です。
速さは機能ではなく、相手の時間を奪わないという態度として伝わる。
顧客心理の視点では、表示の遅さは「不便」ではなく軽い不信として蓄積します。訪問者は待たされたことを覚えていませんが、「この会社のサイトは重かった」という漠然とした印象は残ります。しかも遅さは、相手が最も急いでいるときに最も効きます。比較検討中に何社かのサイトを続けて開いている人は、開くのが遅い1社をそのまま候補から外します。負けたのは提案内容ではなく、開くまでの数秒ということが実際に起きます。さらにやっかいなのは、この離脱がアクセス解析上ほとんど見えないことです。表示される前に閉じた人は、そもそも計測タグが動いていない場合すらあります。「見られていないページ」と「見る前に閉じられたページ」は数字の上で似た顔をしますが、打ち手はまったく違います。まずスマートフォンを持って、自社サイトを外の回線で開いてみる。ここで感じた数秒が、顧客が毎日受け取っているものです。
仕組み化の視点では、パフォーマンスは放っておくと必ず悪化する性質を前提に運用を組みます。サイトは更新のたびに重くなります。新しいバナー画像が加わり、計測タグが増え、キャンペーン用のスクリプトが差し込まれ、そのまま外し忘れる。1回ごとの追加は小さくても、1年分が積み上がれば体感は明確に変わります。だから必要なのは大規模な作り直しではなく、月に一度、決まった手順で測って記録する習慣のほうです。手順は4つです。①Search Consoleのコアウェブバイタルのレポートで、実利用者データが基準を外している指標を確認する ②原因の大きい順に1つだけ手を入れる ③画像・スクリプト・フォントのどれが重いかを記録する ④次回の更新時に「追加したもの」を一覧に残す。とくに④は効きます。何を足したかの記録があれば、悪化したときに原因を探す時間がほぼゼロになるからです。あわせて、新しいタグやツールを追加するときに「これを入れると何秒増えるか」を判断する担当を決めておくと、増え続ける流れそのものを止められます。
AI活用の視点では、原因の切り分けと修正案づくりを任せられます。測定ツールの出力を貼り付けて「成果への影響が大きい順に、中小企業が自力で対応できる項目だけ挙げる」と指示すれば、専門用語の羅列を実行可能な作業リストに変換できます。画像の一括変換や不要スクリプトの洗い出しといった作業も、手順化すれば自動で回せます。ARGASのような追跡の仕組みがあれば、改善の前後で直帰の傾向や問い合わせ数がどう動いたかを実データで突き合わせられます。ただし注意点があります。AIは技術的に正しい提案を出しますが、その多くは効果が小さい項目です。上位3件だけに絞らせる、費用と工数の見積もりも一緒に出させる、といった制約を先に与えておくと、実務で使えるリストになります。
図解：3つの指標と、効果の大きい順の打ち手
上段は、Googleが定義する3指標と、それぞれが測っている「訪問者の不快な瞬間」。下段は、中小企業のサイトで効果が出やすい順に並べた4つの打ち手です。
事例で見る：国内・海外
Googleによる指標の刷新 ── 「速さ」の定義が体感寄りに変わった
Webの速さは長らく「ページの読み込みが完了するまでの秒数」で語られてきました。しかしこの数え方には問題がありました。画面の下のほうにある要素の読み込みが終わるまで待っても、訪問者の体感とは関係がないからです。逆に、本文はすぐ出たのに操作に反応しない状態は、数値上は速く見えても実際には不快です。こうした差を埋めるためにGoogleが定義したのがコアウェブバイタルで、主役の要素が出るまでの時間（LCP）、操作への反応（INP）、レイアウトのずれ（CLS）という3つに整理されました。2024年3月には、操作の応答性を測る指標がFIDからINPへ切り替わっています。FIDは最初の操作に対する反応だけを見ていましたが、INPは滞在中の操作全体を対象とするため、実際の使い心地に近い評価になりました。指標が体感に寄ってきたことで、数字を良くする作業と、訪問者にとって快適にする作業が一致しやすくなったのがこの変化の意味です。個別サイトの改善率などの数値は条件によって大きく異なるため、ここでは扱いません。
更新のたびに重くなった小売業のサイト ── 犯人は3年分の「外し忘れ」
たとえば、実店舗とオンラインショップを併営する小売業が、数年運用してきた自社サイトを持っている場合を考えます。制作直後は快適だったのに、いつからかスマートフォンでの表示が明らかに重くなっている。原因を調べると、大規模な問題はどこにもありません。あるのは小さな追加の積み重ねです。キャンペーンごとに追加した計測タグ、試用して契約しなかったチャットツールの読み込み、SNSの埋め込み、トップページに並ぶ高解像度のままの商品写真。どれも単体では数百ミリ秒ですが、合計すると体感は別物になります。ここでの進め方は単純です。まずSearch Consoleで実利用者データを確認し、基準を外している指標を特定する。次に、トップページの画像を表示サイズに合わせて縮小・変換し、画面外の画像は遅延読み込みにする。続いてタグ管理画面を開き、現在使っていないタグをすべて外す。この2つだけで体感は大きく変わることが多く、サイトの作り直しは必要ありません。最後に、今後タグを追加するときの承認担当を1人決めておく。これは特定企業の実績ではなく、数年運用したサイトで起きやすい代表的なパターンとして示しています。
現場での使い方：5ステップ
- 外の回線で自社サイトをスマートフォンで開く社内の高速なPCで見た印象は当てにならない。顧客が置かれている条件で、開くまでの数秒を自分で体験する。
- 実利用者のデータで、外している指標を特定するSearch Consoleのコアウェブバイタルのレポートを見る。試験環境の点数ではなく、実際の訪問者から集まった値で判断する。
- 画像から手を付ける効果と手間の比が最もよい。表示サイズに合わせて縮小し、新しい形式に変換し、画面外の画像は遅延読み込みにする。
- 使っていないタグとツールを外す試用のまま残った計測タグやチャットが操作の反応を鈍らせる。棚卸しして、必要なものだけに戻す。
- 月1回測り、追加したものを記録するサイトは更新のたびに重くなる。何を足したかの一覧があれば、悪化したときの原因調査がほぼ不要になる。
関連用語
まとめ：内容を読んでもらう前の数秒を、取り戻す
Webパフォーマンス最適化は、表示の速さと操作の快適さを実測にもとづいて改善する取り組みです。遅いサイトは、内容の良し悪しを判断される前に閉じられます。この離脱は解析画面にほとんど残らないため、社内では「反応が薄い」としか見えません。見るべきは試験環境の点数ではなく、実際の訪問者から集まったデータで基準を外している指標です。打ち手は画像、タグ、配信の順に効きます。そして最も大事なのは、サイトは更新のたびに重くなるという前提を持ち、月1回測って追加したものを記録する習慣にすること。原因の切り分けはAIに任せ、判断は外の回線で自分が感じた数秒で行う。待たされない設計は、顧客が自然に本題へ進むための最短の条件です。
