サイトが遅いとき、どこから直すか｜自社サイトを測って切り分けた記録

結論

サイトが遅いときに最初にやることは、原因を回線・端末・タグの3つに切り分けることです。

ここを飛ばすと、画像を小さくしても速くならない、という時間の使い方になります。

このメディア自身のページを、条件を1つずつ変えて測った結果です（モバイル相当・3回の中央値・基準はLCP 916ms）。

• 遅延だけ速くする（150ms → 40ms）：−232ms
• 帯域だけ上げる（1.6Mbps → 9Mbps）：−264ms
• CPUの制限だけ外す：−172ms

つまり、いまのこのページは回線側の2つがほぼ同じだけ効いていて、端末性能はその半分という状態です。片方だけ直しても半分しか戻りません。

ここを2つ同時に変えて測ると、原因を取り違えます。実際、最初に測ったときは帯域と遅延を一緒に速くしてしまい、「帯域が効いている」と読みかけました。変数は1つずつです。

この記事で扱う範囲

遅い原因の切り分けと、測り方に絞ります。

ページの中身の作りは広告のリンク先ページは何でできているかと長く回り続けるLPの要素、計測タグが入っているかの確認は計測タグは入っているか。

合格ラインは、実際のユーザーの数字で決まる

GoogleはCore Web Vitalsとして、3つの目安を示しています。

同じページには、Core Web Vitalsが「その他のページ エクスペリエンス要素とともに、Google のコア ランキング システムがランキングを決定する際に考慮する要素」だと書かれています。順位のためだけに追う数字ではありませんが、無関係でもありません。

測るときは、条件を固定する

今回の測定条件は次のとおりです。数字の絶対値ではなく、条件をそろえた比較のために置いています。

• 画面 390×844（スマートフォン相当）
• 4G相当の回線（下り1.6Mbps・遅延150ms）
• CPUは4倍遅くする（実機のスマホに寄せるため）
• 各条件3回測って中央値

3回の中央値を取るのは、1回だけだと外れ値を拾うためです。平均ではなく中央値にすると、たまたま重かった1回に引っ張られません。

実測1: 効いているのは回線か、端末か

同じページを、条件を1つずつ変えて測りました。

読み方は単純です。条件を1つ外したときに、いちばん数字が動いたものがボトルネックです。

• 帯域（−264ms）と遅延（−232ms）は、ほぼ同じだけ効いています。 どちらか片方を直しても半分です
• 両方を速くすると−472msで、単独の差の合計（496ms）とほぼ一致します。おおむね足し算で効きます
• CPUは−172ms。回線側の1つぶんより小さい
• ただし、メインスレッドの詰まりはCPUを等倍にすると0ms。ここは回線をいくら速くしても消えません

読み込みの時間は回線側で決まっていて、操作の重さは端末の性能で決まっている、という状態です。前者はファイルの大きさと数、後者はJavaScriptの量の話になります。

実測2: 計測タグはどれだけ重いか

GA4とMicrosoft Clarityを入れているページで、タグを遮断しながら測りました。上の表とは別の実行です。設定は同じにそろえてありますが、同じ「4G + CPU4倍」でも基準値は916msと932msでずれます（約2%）。比べるのは同じ実行の中の差だけにしてください。

LCPで見ると、タグの影響はほとんど出ません。 932ms・916ms・928msで、上下の幅は実行ごとのばらつきと同じ程度です。「計測タグを入れても遅くならない」と言えそうに見えます。

ところが、メインスレッドの詰まりは 356ms → 97ms。タグが約260ms分の処理を足しています。ここはLCPには出にくく、タップしたときの反応（INP）の側に出ます。

実際に効いた修正

このサイトで実際に入れて、数字が動いた修正は次のとおりです。

計測タグの読み込みを、ページの表示が終わったあとに回した。 GA4とClarityが、画面を組み立てているいちばん混む時間に動いていました。当時のコードには「CPU4倍でLCPが4.6秒あった」という記録が残っています。いまの同じ条件での実測は916〜932msです。その間に画像とフォントの見直しも入っているので、この差のすべてがタグの移動によるもの、とは言えません。

ただしトレードオフがあります。読み込み完了後にタグが動くので、1秒以内に離脱した人はGA4に記録されません。 集計の目的によっては、この差が問題になります。速度と計測は、どちらかを選ぶ場面があるということです。

そのうえで、削れなかったものもあります。JavaScriptの大半はサイトの土台（フレームワーク）そのもので、記事の側から減らせません。フォントも、読ませたい書体を捨てる判断になります。「全部速くする」ではなく、動かせるところを動かすのが実務です。

中小企業のサイトで、最初に見る3つ

測る道具がない段階でも、当たりを付けられる項目があります。

この3つは、制作会社に依頼するときも「どれを直したいか」を指定しやすい項目です。

確認項目

直しにかかる前に、切り分けが済んでいるかを確かめます。

今日やること

まず、Search Consoleの「Core Web Vitals」レポートを開いて、不良と判定されたURLがあるかだけを見てください。ここが空なら、体感の遅さは別の場所（サーバーの応答や特定の端末）にあるかもしれません。

不良のURLがあるなら、そのページでいちばん大きい画像のファイルサイズを確認します。ブラウザでその画像を直接開けば分かります。数MBあれば、そこが最初の1手です。

計測タグを足す予定があるなら、足す前の数字を控えておいてください。あとから「重くなった気がする」を検証する方法が、それしかありません。タグが入っているかどうかの確かめ方は計測タグは入っているか。