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

結論

サイトが遅いときに最初にやることは、原因を回線・端末・タグの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手です。

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