【WordPress高速化】CLSの原因を検証ツールで探す方法

記事内には広告が含まれます

2026年10月22日

はじめに

今回から、WordPressブログの表示速度や見やすさを改善する「WordPress高速化」シリーズを始めます。第1回は、ページの表示がガタッとずれるCLSの原因を、Google Chromeの検証ツール（DevTools）で見つける方法です。

きっかけは、当サイトで実際に起きた問題でした。PageSpeed Insightsで記事を測ると良好なのに、Search Consoleではパソコンの「CLS に関する問題: 0.25 超」が174件も出ていたのです。

Search Consoleの「ウェブに関する主な指標」のPCのグラフ。2026年9月10日ごろに「改善が必要」から「不良」に変わり、不良URLが174件になっている

記事単体の点数は良いのに、なぜ不良なのか。この記事では、その理由と、Chromeの検証ツールを使って「どこがずれているのか」を突き止める手順を解説します。

この記事の画面は、パソコン版のGoogle Chrome（日本語表示）のものです。Chromeのバージョンによって、メニューの位置や表記が少し違うことがあります。

CLSとは？

CLS（Cumulative Layout Shift）は、ページを見ている間に、文章や画像が後から動いた量を表す数値です。Googleが重視する「ウェブに関する主な指標（Core Web Vitals）」の1つです。

CLSの値	評価
0.1以下	良好
0.1〜0.25	改善が必要
0.25超	不良

読もうとした文章が急に下へ押し下げられたり、押そうとしたボタンの位置がずれたりする、あの「ガタッ」が数値になったものです。ブログでは、後から読み込まれる広告、JavaScriptで後から作られる目次、後から表示される関連記事などが、よくある原因です。

PageSpeed Insightsは良好なのにSearch Consoleで不良になる理由

PageSpeed Insightsの結果ページには、2つの欄があります。

PageSpeed Insightsの上の欄「実際のユーザーの環境で評価する」。デスクトップのCLSは0.05で、過去28日間、セッション全体の長さと書かれている。右上は「この URL」が灰色で「オリジン」が選ばれている

PageSpeed Insightsの下の欄「パフォーマンスの問題を診断する」。CLSは0で、最初のページ読み込み、デスクトップのエミュレーションと書かれている

上の欄がフィールドデータ（実際の訪問者の記録）、下の欄がラボデータ（Googleのテスト用ブラウザで1回測った結果）です。

「ラボ」と「フィールド」の違い。ラボはテスト用ブラウザで1回、最初のページ読み込みだけを測り、スクロールしない。フィールドは実際の訪問者の28日分で、ページを閉じるまでを測り、スクロールもする

画面の下部にも、それぞれ「最初のページ読み込み」「セッション全体の長さ」と書かれています。ラボは読み込み直後の数秒しか見ていないため、読んでいる途中やスクロールしたときにずれる要素は、ラボでは見つかりません。Search Consoleが使っているのは、フィールドのほうです。

確認するときのポイントは次の3つです。

画面上部の「携帯電話」「デスクトップ」を切り替えて、両方を見る（Search Consoleもパソコンとモバイルを別々に評価しています）
上の欄の右上が「オリジン」になっているときは、その記事だけではデータが足りず、サイト全体の値が表示されています
フィールドは過去28日分なので、直してから反映されるまで約28日かかります

ラボだけを見て「良好だから大丈夫」と判断すると、当サイトのように問題を見逃します。実際にずれている場所は、自分のブラウザで、読者と同じように操作して探すのが確実です。

準備：検証ツールを開いて、下に表示する

Chromeでブログの記事を開き、F12キーを押すと、検証ツール（DevTools）が開きます。

最初に、検証ツールを画面の下に表示しておきましょう。右側に表示したままだと、ページの表示幅が狭くなり、パソコンなのにスマホ用のレイアウトで表示されてしまうことがあるためです（SWELLは画面幅960px未満でスマホ用の表示に切り替わります）。

検証ツールの右上にある「︙」をクリックし、「固定サイド」の中から、下に表示するアイコンを選びます。

検証ツールの「︙」メニュー。上部の「固定サイド」に表示位置のアイコンが並び、「その他のツール」にマウスを乗せると、右側に「レンダリング」などのメニューが表示されている

方法1：「パフォーマンス」タブでCLSの数値を見る

検証ツールの上部にある「パフォーマンス」タブを開くと、「ローカルの指標」に、自分のブラウザで測ったCLSが表示されます。

「パフォーマンス」タブを開いたまま、ページを再読み込み（F5）する
読者と同じように、ゆっくり下へスクロールする
「Cumulative Layout Shift (CLS)」のカードの数値を見る

ここでは説明用に、読み込みの3秒後に広告風の箱が3つ入るテストページを用意して試しました。

「パフォーマンス」タブの「ローカルの指標」。CLSのカードに、オレンジ色で0.21と表示され、その下に「最も影響の大きいクラスタシフト回数: 3」と表示されている

CLSは0.21（改善が必要）でした。この数値は、ページを開いている間、スクロールなどの操作に合わせて更新されます。ラボと違い、読んでいる途中のずれも数えてくれるのがポイントです。

ずれた要素を一覧で見る

カードの「シフト回数: 3」をクリックすると、下の「レイアウトシフト」タブに、ずれた要素の一覧が表示されます。

「レイアウトシフト」タブの一覧。Layout shift score 0.1310の行に div.p-toc.-double と p.wp-block-paragraph などが並び、0.0452の行にサイドバーのウィジェットが並んでいる

一番上の「0.1310」のグループには、div.p-toc.-double（SWELLの目次）や本文の段落が並んでいます。これは、目次や本文そのものが悪いのではなく、その上に後から入った広告の箱に押し下げられたことを表しています。一覧に出るのは「動かされた側」の要素なので、その少し上で、後から現れたものが原因だと考えて探しましょう。

方法2：「レンダリング」で、ずれた場所を青く表示する

どこがずれたのかを、ページの上で目で見て確かめる方法です。

検証ツールの「︙」→「その他のツール」→「レンダリング」を選ぶ
下に開いた「レンダリング」パネルで、「レイアウトシフト領域」にチェックを入れる

「レンダリング」パネル。「レイアウトシフト領域」にチェックが入っており、「シフトされたページの領域（青）をハイライト表示します」と説明が書かれている

この状態でページを再読み込みし、スクロールすると、ずれた部分が一瞬、青く光ります。

広告の箱が入った瞬間に、押し下げられた段落や箱が青くなりました。青い部分がたくさん光る場所のすぐ上に、原因の要素があります。

パネルにも書かれているとおり、点滅が苦手な方は長時間の使用に注意してください。確認が終わったら、チェックを外しておきましょう。外さないと、普段の閲覧中も青く光り続けます。

方法1の一覧で「どの要素が」、方法2の青い表示で「どのタイミングで、どこが」ずれたかがわかります。両方を組み合わせると、原因をかなり絞り込めます。

方法3：ずれた要素の高さを測る

原因の要素がわかったら、その要素の高さを測ります。CLSの対策の基本は、「後から中身が入る場所に、先に高さを確保しておく」ことで、そのときに必要になる数値です。

ページ上の要素を右クリックし、「検証」を選ぶ（方法1の一覧の要素名をクリックしても選べます）
「要素」パネルの右側にある「計算済み」タブを開く

「要素」パネルで目次（div.p-toc.-double）を選んだ画面。ページ上の目次に「718.42 × 170.95」と大きさが表示され、右側の「計算済み」タブに、外側の余白64、枠線4、内側の余白32、中身654.417×98.951の図が表示されている

要素にマウスを乗せると、ページ上に「幅 × 高さ」が表示されます。この目次は高さ170.95pxでした。「計算済み」タブの図では、中身・内側の余白（padding）・枠線（border）・外側の余白（margin）の内訳もわかります。

どこに min-height を設定するか

設定するのは、一覧に出てきた「動かされた側」ではなく、後から中身が入る入れ物（原因の側）です。SWELLでよくある例は次のとおりです。

原因	設定する場所（SWELLの例）
目次（JavaScriptで後から作られる）	`.p-toc.-double`
目次前・記事下の広告	広告を囲む枠（`.w-beforeToc` など）
後から表示される関連記事	`.l-articleBottom__section.-related`

たとえば、さきほど測った目次（高さ170.95px）なら、次のように書きます。

/* パソコン表示（画面幅960px以上）のときだけ、目次の高さを先に確保する */
@media screen and (min-width: 960px) {
	.p-toc.-double {
		min-height: 171px;
	}
}

測った高さをそのまま使える：SWELLは全要素にbox-sizing: border-boxを指定しているため、「計算済み」で見た高さ（内側の余白と枠線を含む）をそのまま書けます。外側の余白（margin）は含めません。
heightではなくmin-height：中身が多い記事では、自然に下へ伸びます。ただし、目次のように記事ごとに高さが変わる要素は、値を大きくしすぎると、短い記事で空白が目立ちます。
パソコンとスマホで値を分ける：画面幅で高さが変わるので、@mediaでそれぞれの値を書きます。

CSSは「外観」→「カスタマイズ」→「追加CSS」、または子テーマのstyle.cssに追加します。当サイトで実際にどの要素にいくつ設定したか、逆に悪化させてしまった書き方（content-visibility）は、次回くわしく紹介します。

パソコンとスマホの両方で確認する

Search Consoleは、パソコンとモバイルを別々に評価します。当サイトのようにパソコンだけ不良ということもあるので、両方で確認しましょう。

パソコン：検証ツールを下に表示し、ブラウザの幅を広げた状態で確認する
スマホ：検証ツールの左上にあるスマホとタブレットの形のアイコン（デバイスツールバー、Ctrl＋Shift＋M）で、画面幅をスマホのサイズに切り替えて確認する

広告やサイドバーの有無、目次の幅など、パソコンとスマホでは表示が大きく違います。確保する高さも、パソコン用とスマホ用で別々に測る必要があります。

CLSの原因を見つける流れ。1 Search ConsoleやPageSpeed Insightsで気付く、2 パフォーマンスタブのローカルの指標で数値を見る、3 レンダリングのレイアウトシフト領域で場所を見る、4 要素パネルの計算済みで高さを測る

よくある質問・エラー対処

Q. 「ローカルの指標」の数値が、PageSpeed InsightsやSearch Consoleと違います

→ 測っている条件が違うためです。「ローカルの指標」は、自分のブラウザで、今の1回を測った値です。広告の出方や回線の速さ、スクロールの仕方で毎回変わります。何度か再読み込みして、傾向をつかみましょう。

Q. ずれが起きるはずなのに、CLSが0のままです

→ クリックやキー入力の直後（0.5秒以内）に起きたずれは、CLSに数えられません。たとえば、ボタンを押して開いた部分によるずれは対象外です。スクロールで読み進めたときのずれを確認しましょう。また、Chromeの拡張機能が影響することもあるので、シークレットウィンドウで試すのもおすすめです。

Q. 検証ツールを右側に出すと、レイアウトが変わってしまいます

→ ページの表示幅が狭くなり、スマホ用のレイアウトに切り替わっているためです。パソコンの表示を確認するときは、検証ツールを画面の下に表示しましょう。