CLSの改善とは？サーチコンソールでCLSの問題が出たら、PageSpeed Insightsの「レイアウト シフトの原因」でずれる場所を探す

Search Consoleの「ウェブに関する主な指標」を開いたら、モバイルの表に、CLSが0.1(あるいは0.25)を超えているという行が出ていた。あるいは、スマホで自分の記事を読み返していたら、広告や画像が出た瞬間に本文がガクッと下にずれた。広告のせいだろうと見当はついても、どこを直せばいいのか、広告を外さないといけないのかまでは分からない。そこで手が止まっていないでしょうか。

この記事は、Search ConsoleでCLSの問題が出た、またはスマホで読むと画面がずれる個人ブロガーに向けて書いています。読み終えたときには、CLSが何の数字なのか、0.1と0.25が何の線なのか、ずれているのがどこかをどの画面で探せばいいのか、ブログでずれやすいのがどこなのかが分かるはずです。根拠にしたのは、Googleの開発者向けサイト web.dev の「Cumulative Layout Shift（CLS）」と「Cumulative Layout Shift の最適化」、Chromeの開発者向けサイトの分析情報のページ「レイアウト シフトの原因」とブログ記事「Lighthouse 13 の新機能」、Search Consoleのヘルプ「Core Web Vitals レポート」、Google 検索セントラルのページ エクスペリエンスの説明で、2026年10月14日に日本語版と英語版の原文で確かめました。web.dev とChromeの開発者向けサイトの日本語版はAIによる翻訳と注記されているので、引用はどれも英語版と同じ意味かを見て、訳が崩れている文は英語版を私が訳しています。

私はこの記事のためにSearch ConsoleやPageSpeed Insightsの実際の画面を開いて確かめてはいません。画面や項目の名前は、上の説明ページに書かれている字で呼んでいます。また、CLSが0.1を超えている、という表の行の名前(問題名)の字は、今のSearch Consoleのヘルプには日本語版にも英語版にも見当たりませんでした。ヘルプにあるのは、低速・改善が必要・良好のステータスと、しきい値の表です。この記事では、行の名前は検索でよく使われる言い方として扱い、ヘルプの字としては引きません。レポートそのものの読み方、たとえば表に出たURLが似たページのグループの代表にすぎないことは、ウェブに関する主な指標レポートの見方は？URLグループとデータなしに書きました。

結論:上の欄と下の欄のCLSを比べ、「レイアウト シフトの原因」でずれた要素の上を見る

web.dev とSearch Consoleのヘルプに書かれていることと、そこから私が決めている進め方をまとめると、次の4つです。

• CLSは、見えている要素が予期せず動いた量の点数。読者がボタンを押した直後のずれは数えられませんが、スクロールして読み進めている途中のずれは数えられます
• 0.1以下が良好、0.25を超えると低速、その間が改善が必要。Search Consoleのヘルプは、「低速」から直すよう勧めています
• まずPageSpeed Insightsで、上の欄と下の欄のCLSを比べる。近ければ読み込み中のずれ、上の欄だけ大きければ、読み込みのあとのずれを疑います
• 分析情報「レイアウト シフトの原因」に挙がった要素の、すぐ上を見る。挙がるのは押された側のことが多く、原因は寸法の無い画像、サイズの決まっていない広告や埋め込み、Webフォントであることが多い、と web.dev は書いています

CLSとは:見えている要素が、予期しないタイミングで動いた量

web.dev のCumulative Layout Shift（CLS）は、CLSをこう説明しています。

CLS は、ページのライフサイクル全体で発生した予期しないレイアウト シフトのレイアウト移動スコアの最大バーストを測定する指標です。
— web.dev「Cumulative Layout Shift（CLS）」

英語版は "CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page." です。レイアウト シフトは、画面に見えている要素の位置が、ある瞬間から次の瞬間に変わることです。ずれは1回ごとに、画面のどれだけの広さが動いたかと、どれだけの距離を動いたかを掛け合わせて点数にします。間隔が1秒未満で続いたずれは、最大5秒まで1つのまとまり(セッション ウィンドウ)として足し合わせ、ページを開いている間でいちばん点数の大きいまとまりがCLSになります。秒やミリ秒で測るLCPやINPと違い、CLSは単位の無い数字です。

数えないずれもあります。リンクを押す、ボタンを押す、検索窓に入力する、といった操作から500ミリ秒以内に起きたずれは、計算から外せるようになっています。読者が自分で押したのだから、画面が変わるのは予期できる、という考え方です。ただし同じページは、スクロールやドラッグ、拡大・縮小のような続けて行う操作は、この「最近の入力」に入らないとも書いています。記事をスクロールしている途中で広告や画像が入って本文がずれたら、それはCLSに数えられる、ということです。

ずれの原因として、同じページは「レイアウトのずれの原因としては、サイズが不明な画像や動画、初期のフォールバックよりも大きくまたは小さくレンダリングされるフォント、サイズを動的に変更するサードパーティの広告やウィジェットなどがあります。」と書いています。画像・書体・広告や外から読み込む部品の3つは、あとの章でブログに当てはめます。なお、Search Consoleのヘルプの用語の説明は、CLSを「個々のレイアウト シフトの合計スコア」を測るものと書いています。web.dev のページは、ページを開いている間のずれをすべて足していたのは以前の計り方だと注記しているので、ヘルプの説明は古い計り方の言い方のまま残っている、と私は読んでいます。

しきい値:0.1以下が良好、0.25を超えると低速

web.dev のCumulative Layout Shift の最適化は、目標をこう書いています。

優れたユーザー エクスペリエンスを提供するには、サイトで少なくとも 75% のページ訪問で CLS を 0.1 以下に収めるようにします。
— web.dev「Cumulative Layout Shift の最適化」

英語版は "sites should strive to have a CLS of 0.1 or less for at least 75% of page visits" です。同じページの図の説明も、良好は0.1以下、0.25より大きいと低速です。一方、「Cumulative Layout Shift（CLS）」のほうの日本語版は、本文も図の説明も良好の線を「0.1 未満」と書いていますが、英語版はどちらも "0.1 or less"(0.1以下)です。ちょうど0.1は良好に入る、と英語版の意味で読んでください。また「Cumulative Layout Shift（CLS）」は、判定には、実際の訪問のうち75パーセンタイル、つまり4回に3回の訪問がその値か、それより小さい値を使い、モバイルとパソコンを分けて見るよう勧めています。

Search Consoleのヘルプの表も、CLSは0.1以下が良好、0.25以下が改善が必要、0.25を超えると低速で、数字は同じです。この表に当てはめると、0.1を超えているという問題は「良好」に届いていないこと、0.25を超えているという問題は「低速」に当たることを示している、と私は読んでいます。ヘルプは、まず「低速」を直すよう勧め、「改善が必要」は改善の余地はあるが「低速」より重要度が下がる、と書いています。3つの指標を並べた表と、ステータスの決まり方はウェブに関する主な指標レポートの見方は？URLグループとデータなしにまとめました。

手順1:PageSpeed Insightsで、上の欄と下の欄のCLSを比べる

「Cumulative Layout Shift の最適化」は、PageSpeed Insightsの上の欄を日本語版で「[実際のユーザーが体験していることを確認する]」、下の欄を「[パフォーマンスの問題を診断する]」と呼び、上には実際の訪問者が体験したCLS、下には読み込みの試験(ラボ)で測ったCLSが出る、と書いています(英語版は "Discover what your real users are experiencing" と "Diagnose performance issues" です。どちらも web.dev が書いている名前で、今の実際の画面の見出しの字は確かめていません)。そのうえで、こう続けています。

これらの値の差は、読み込み後の CLS の結果である可能性があります。
— web.dev「Cumulative Layout Shift の最適化」

英語版は "Differences between these values are likely the result of post-load CLS." です。下の欄のLighthouseは、ページを1回読み込むところまでしか見ないことが多く、読者が記事をスクロールしたあとのずれは拾いにくい、という説明です。そこで、2つの数字をこう読み分けます。

• 上と下がおおむね同じ:読み込み中のずれ。Lighthouseが見つけているので、次の手順2の分析情報で要素が分かりやすい
• 上の欄だけ大きい:読み込みのあとのずれ。同じページは、スクロールしたときに遅延読み込みの内容が場所を空けずに入ってくることと、ポインタを合わせたときに内容が動くことを、よくある原因に挙げています

もう1つ、出てきた数字が記事1本のものかを確かめてください。同じページは、PageSpeed InsightsはURLのデータが無いとオリジン(サイト全体)のデータを出そうとする、と注記し、「常に表示されているデータを確認し、オリジンの他のページに実際に存在する CLS の問題を追跡しようとして時間を無駄にしないようにしてください。」と書いています。上下の欄がそれぞれ何を測っているかはPageSpeed Insightsの見方は？上の実際のユーザーのデータが先、下の点数はLighthouseの試験で毎回変わるに書きました。

手順2:下の欄の分析情報「レイアウト シフトの原因」で、ずれた要素を見る

どの要素がずれたかは、下の欄の分析情報で見ます。Chromeの開発者向けサイトの「Lighthouse 13 の新機能」には「Lighthouse 13 以降では、次の監査が置き換えられました。このバージョンでは、置き換えられた監査は使用できません。」とあり、置き換えの表では、レイアウト シフトの監査(layout-shifts)が cls-culprits-insight という分析情報に置き換わっています。今の分析情報の一覧でCLSの原因を扱っているのは「レイアウト シフトの原因」(英語名 Layout shift culprits)で、そのページは次のように書いています。

この分析情報では、観察されたレイアウト シフトの原因について最良の推測が提示される場合があります。
— Chrome for Developers「レイアウト シフトの原因」

英語版は "The insight may offer a best guess for the cause of the observed layout shifts." です。原因はあくまで「推測」で、出ないこともある、ということです。同じページは「原因が示されていない場合でも、すべてのレイアウト シフトを軽減できます。」とも書き、よくある原因として、サイズ指定されていない画像、挿入された iframe(広告など)、最適化されていないアニメーション、Webフォントを挙げています。この分析情報に合格する条件は、英語版では "Have a "good" (0.1) or better CLS."、つまりCLSが良好の0.1かそれより良いこと、です(私の訳。日本語版はここを「以上」と訳していて、数字の上では逆に読めてしまいます)。

cls-culprits-insight が「レイアウト シフトの原因」のことだというのは、IDの字面と、ページのアドレス(cls-culprit)からの私の読みで、それを結ぶ字は読んだページにありません。古い layout-shifts の監査が日本語で何と表示されていたかも、古いページが開けなかった(404)ので確かめられませんでした。また同じ「Lighthouse 13 の新機能」には、幅と高さの無い画像を見る監査(unsized-images)と、ずれにつながりうるアニメーションの監査(non-composited-animations)は、まとめられずに別の診断として残った、という注記があります。日本語の表示名は確かめられなかったので、IDだけ書いておきます。今のPageSpeed InsightsがどのバージョンのLighthouseを使っているかと、実際の画面に出る字も、私は確かめていません。新旧の名前の対応はPageSpeed Insightsの「レンダリングをブロックしているリクエスト」とは？下の欄の項目は分析情報。直すかは上の欄で決めるに書きました。

挙がった要素は、ずれた側。原因はその上にあることが多い

要素を見るときに、いちばん覚えておきたいのがこの点です。「Cumulative Layout Shift の最適化」はこう注記しています。

Lighthouse は移動した要素を特定しますが、多くの場合、CLS の原因となっている要素ではなく、影響を受けた要素を特定します。
— web.dev「Cumulative Layout Shift の最適化」

英語版は "Lighthouse will identify the elements that were shifted, but often these are the ones impacted rather than the elements causing the CLS." です。たとえば新しい要素が上に差し込まれると、挙がるのはその下で押し下げられた要素で、本当の原因は上に入った新しい要素のほうだ、という例が続きます。ブログに当てはめると、本文の段落や見出しが挙がっていたら、その段落の直前にある画像、広告の枠、埋め込み、見出しの上のバナーを疑う、という読み方になります。これは私の当てはめで、同じページの文書は、ずれた要素が分かれば原因を探す手がかりには十分だ、と書いています。

Chromeのデベロッパーツールの[パフォーマンス]パネルでも、ずれを見られます。同じページによると、記録すると[レイアウト シフト]のトラックに、紫の線でまとめられたずれが1つずつひし形で並び、ひし形が大きいほどずれが大きく、押すとずれの動きと、ずれた要素が表示されます。そこから左の[インサイト]パネルの「レイアウト シフトの原因」にもつながっている、とあります(日本語版はここを「分析情報」ではなく「インサイト」と訳していて、同じ名前の訳が割れています)。読み込みのあとのずれは、ライブ指標の表示で、ページを操作しながらCLSの数字を見て探せる、とあります。パネルの開き方はINPの改善とは？サーチコンソールで「改善が必要」と出たら、PageSpeed InsightsとChromeで遅い操作を探すに書きました。

ブログでずれやすい場所:web.dev が挙げる4つ

「Cumulative Layout Shift の最適化」は、CLSが悪くなるいちばんよくある原因として、次の4つを挙げています(英語版の "The most common causes of a poor CLS are:" を私が訳したもの。日本語版はここを「CLS が低い」と訳していますが、CLSは低いほど良い数字なので、英語版の "poor"(悪い)とずれています)。

• 寸法(幅と高さ)の書かれていない画像
• サイズの決まっていない広告・埋め込み・iframe
• 広告・埋め込み・iframe のように、サイズの決まっていないまま後から差し込まれる内容
• Webフォント

以下、ブログで当てはまりやすい形に置き換えて並べます。どれもコードの書き換えまでは書きません。設定がどこにあるかは、使っているブログサービスやテーマ、広告の説明で確かめてください。

画像:幅と高さが書かれていない

画像のタグに幅(width)と高さ(height)が書かれていないと、ブラウザは画像を読み込むまで高さが分からず、読み込んだ瞬間に下の本文が押し下げられます。web.dev は画像と動画に必ず width と height を書くか、CSSの aspect-ratio などで場所を空けておくよう書いています。画面の幅に合わせて画像を縮める作りでも、2つの数字があればブラウザが比率から高さを先に計算できる、という説明です。自分の記事で幅と高さが入っているかの確かめ方はブログの画像サイズは何px？本文は枠の幅から決め、アイキャッチはDiscover推奨の1200px・16:9が目安に書きました。

広告:「最大の原因の一つ」。場所を空ける、消さない、空けられないなら下へ

広告について、同じページははっきり書いています。

広告は、ウェブ上のレイアウト シフトの最大の原因の一つです。
— web.dev「Cumulative Layout Shift の最適化」

英語版は "Ads are one of the largest contributors to layout shifts on the web." です。広告の配信ではサイズを固定しない作りがよく使われ、そのほうがクリックされやすく収益も上がりやすい一方、読んでいる本文を下に押し出すことがある、という説明が続きます。直し方として書かれているのは、主に次の3つです。

• あらかじめ場所を空けておく。CSSの min-height(最低の高さ)や aspect-ratio で、広告が入る前から枠の高さを取っておく。ただし高さの決まらない広告は、ずれを完全に無くすだけの場所を正確には空けきれないことがあり、大きく空ければそのぶん空白が増える。最小のサイズで空けて、大きい広告のときの多少のずれは許す、という選び方も挙がっています
• 空けた場所を消さない。広告が返ってこなかったときに枠ごとたたむと、それもずれになります。同じページは「要素用に確保されたスペースを削除すると、コンテンツを挿入した場合と同じくらいの CLS が発生する可能性があります。」と書いています
• 空けられないなら、ページの下のほうに置く。「挿入するコンテンツのスペースを予約できない場合は、CLS への影響を軽減するため、ページの下部に配置することをおすすめします。」とあります。画面の上のほうに差し込まれる内容ほど、ずれが大きくなりやすいからです

スマホとパソコンで広告や枠のサイズが少し違うことを考えに入れる必要がある場合もある、とも書かれています。モバイルだけで問題が出るときは、スマホで記事を開き、本文の上や途中に入る広告の枠が、広告が出る前から空いているかを目で見るのが手早い、と私は考えています。広告は収益にかかわるので、CLSのためだけに一律に外すことは勧めません。広告を入れる前と後で、順位やCTRと一緒にずれを見比べる方法はアドセンス合格後にやることは？広告を貼る前後で比べる数字と設定に書きました。

広告に似たものとして、同じページは、ページを開いたときに画面の上や下から出てくるバナーやフォームも挙げています。読者登録のお願いや告知の帯が本文を押し下げる作りなら、出る前から場所を空けておくか、本文の上に重ねて表示して、本文の流れに入れないようにするよう勧めています。

埋め込み:動画やSNSの投稿は、読み込むまで大きさが分からない

動画、地図、SNSの投稿などの埋め込みについて、同じページは、こうした部品は読み込むまで中身の大きさを知らないことが多い、と書いたうえで、こう続けています。「そのため、埋め込みを提供するプラットフォームは、ウィジェットのスペースを常に予約しているわけではなく、最終的に読み込まれたときにレイアウト シフトが発生します。」。直し方は広告と同じで、埋め込みの枠の高さを先に取っておくことです。また、iframe の中で起きるずれは、ページに入れた計測のコード(Web API)からは測れないのに、読者には見えるのでCrUX(実際の訪問者のデータ)には入る、という注記もあります。PageSpeed Insightsの上の欄だけ大きいときは、埋め込みの中で動いているものがないかも見てください。

Webフォント:書体が切り替わると、文字の幅が変わる

サーバーから読み込む書体(Webフォント)は、読み込むまでの間、代わりの書体で文字を出しておいて後から差し替えるか、文字を見えなくしておいて後から出すかのどちらかになります。同じページは「どちらの方法でもレイアウト シフトが発生する可能性があります。」と書いています。文字が見えないときも、代わりの書体で並べた形で場所を取っているので、本物の書体に替わったときに、文字のかたまりとその周りが動く、という説明です。

減らす方法として挙がっているのは、CSSの font-display を optional にして、最初の配置に間に合ったときだけWebフォントを使うこと、近い代わりの書体を指定しておくこと、大事な書体を早めに読み込むことです。LCPの記事では、font-display を auto と block 以外にすると読み込み中も文字が出る、という web.dev の説明を書きました。optional もその2つ以外の値の1つで、CLSの側から見ると、後から書体が差し替わらないぶんずれが起きにくい、という位置づけだと私は読んでいます。LCPの側から見た書体の話はLCPの改善とは？サーチコンソールでLCPの問題が出たら、PageSpeed InsightsでLCPの要素と4つの内訳を確かめるに書きました。

アニメーション:位置を動かす作りは、ずれに数えられることがある

分析情報のページは、最適化されていないアニメーションも原因に挙げています。「Cumulative Layout Shift の最適化」によると、CSSの top や left を変えて要素を動かすアニメーションはずれになり、transform を使って動かすものはほかの要素に影響しないのでCLSに数えられません。スライドショーや、スクロールに合わせて動く飾りをテーマの機能で入れているなら、ずれた要素の近くにないかを見る場所の1つになる、と私は考えています。

順位にどこまで効くかは、レポートの記事と同じ結論

Googleは、検索セントラルのページ エクスペリエンスの説明で「Google のランキング システムでは Core Web Vitals が使用されます。」と書いています。同じページには、次の文もあります。

Search Console の Core Web Vitals レポートのようなレポートやサードパーティのツールで良い結果が得られても、Google 検索の検索結果で上位に表示されることが保証されるわけではありません。
— Google 検索セントラル「ページ エクスペリエンスが Google 検索の検索結果に与える影響について」

英語版は "...doesn't guarantee that your pages will rank at the top of Google Search results" です。この記事も、その両方を書いたウェブに関する主な指標レポートの見方は？URLグループとデータなしの結論を越えません。個人ブログで速度や安定性に手を付ける順番はページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つに書いています。

直したあと、Search Consoleで[トラッキングを開始]を押すと、28日間のモニタリングが始まり、その間どのURLでも問題が出なければ解決したと判断されます。検証の仕組みも、上のレポートの記事に書きました。

よくある質問

PageSpeed Insightsの下の欄ではCLSが小さいのに、Search Consoleでは問題が出ます

手順1のとおり、下の欄は読み込みの試験で、読者がスクロールしたあとのずれを拾いにくいからです。上の欄(実際の訪問者)の数字のほうを見て、スマホで記事を最後までスクロールしながら、途中で入ってくる広告や画像、埋め込みで本文がずれないかを確かめてください。上の欄にサイト全体のデータが出ていないかも見ます。

「レイアウト シフトの原因」に、原因が何も出ません

分析情報のページ自身が、原因は「推測」で、示されないこともあると書いています。その場合も、ずれた要素は分かることが多いので、その要素のすぐ上に後から入るものがないかを見ます。Chromeの[パフォーマンス]パネルで、ずれの動きを再生して確かめる方法もあります。

モバイルだけ問題が出て、パソコンは良好です

Search Consoleはモバイルとパソコンを別々に判定するので、珍しいことではありません。画面の幅が違えば、画像の高さも広告のサイズも変わります。PageSpeed Insightsでもモバイルに切り替えて、同じ手順で見てください。

広告を外せばCLSの問題は消えますか

広告が原因なら減る可能性はありますが、web.dev が勧めているのは外すことではなく、場所を空けておくことです。画像や埋め込み、Webフォントが原因のこともあるので、まずは「レイアウト シフトの原因」でずれた要素を見てから決めてください。直したあとにSearch Consoleの判定が変わるまでには、28日間のモニタリングが要ります。

まとめ

• CLSは、見えている要素が予期せず動いた量の点数。操作の直後のずれは数えないが、スクロール中のずれは数える
• 0.1以下が良好、0.25を超えると低速、その間が改善が必要。web.dev の「Cumulative Layout Shift（CLS）」の日本語版は「未満」だが、英語版は「以下」
• PageSpeed Insightsで上の欄と下の欄のCLSを比べる。上の欄だけ大きければ、読み込みのあとのずれを疑う
• 下の欄の分析情報「レイアウト シフトの原因」でずれた要素を見る。挙がるのは押された側が多く、原因はその上にあることが多い
• ブログでずれやすいのは、幅と高さの無い画像、場所の空いていない広告や埋め込み、Webフォント。広告は場所を空ける、消さない、空けられないなら下へ
• 順位については、Googleは Core Web Vitals を使うと書く一方、良い結果でも上位表示は保証されないとも書いている

CLSに手を入れるのは、ずれた要素と、その上にあるものの見当がついてからで十分です。それまでの時間は、すでに検索結果に出ている記事のうち、どれの中身やタイトルを直すかを決めるほうに回せます。

CLSの問題が出たURLグループが複数あると、どのグループから手を付けるかも迷います。私は、検索結果にすでに出ていて、中身やタイトルを直す候補になっている記事を含むグループを先に見ています。その候補を決めるには、記事を掲載順位と表示回数で並べ替える必要があります。ここから先は、その並べ替えを機械にやらせる自作ツールの宣伝です。

Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位が4.0〜20.5位のページを拾い、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分けます。並び順は、通常判定 → 参考判定 → 本文中心の監査の順。前2つの中は CTR機会差の多い順、30回未満は表示回数の多い順です。 判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分がそろうとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページ分の数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ 判定に使うのは、Google検索のページごとの平均掲載順位・表示回数・CTRです(診断カードでは選んだ1ページの本文を読みます)。このツールは、表示速度もCLSもCore Web Vitalsも測りません。診断カードが本文を読むときも、文字と画像の代替テキストを読むだけで、画像や広告を読み込んでページを表示するわけではないので、どこがずれるかは分かりません。CLSの確かめ方は、この記事の手順でPageSpeed Insightsを使って手で行ってください。判定に出た記事がSearch ConsoleのどのURLグループに入っているかを見比べるのも、手作業です。表示回数が0の行は読み込み時に除くので、検索結果に出ていない記事は候補に出てきません。並べ替えるだけで、順位やクリック数が上がることを約束するものではなく、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。