Cumulative layout shift（CLS）は、ページを開いている間に、見えているコンテンツがどれだけ予期せず動いたかを測る指標です。訪問の75パーセンタイルで0.1以下なら良好です（web.dev、2023年4月）。0.25を超えると不良です。スマートフォンでの主な原因は、サイズ指定のない画像、スペースを確保していない広告や埋め込み、上部に差し込まれるバナーやCookie通知、遅れて読み込まれるウェブフォント、レイアウトを動かすアニメーションです。DevToolsでずれた要素を見つけ、読み込まれる前にその場所を確保してください。
cumulative layout shiftとは
CLSは、ページの寿命の中で最も大きなレイアウトシフトの集中のことで、すべてのシフトを足し合わせた値ではありません。各シフトは、影響率と移動距離率を掛けて採点されます。影響率は、動いた要素がビューポートに占める割合です。移動距離率は、要素が動いた最大距離を、ビューポートの最も大きい辺で割った値です。1秒以内に起きたシフトは、最大5秒のセッションウィンドウにまとめられ、CLSはスコアが最も高いウィンドウの値になります（web.dev）。ユーザーの操作から500ms以内に始まったシフトは除外されます（web.dev、Optimize CLS、2025年2月）。
| 評価 | CLS（p75） |
|---|---|
| 良好 | 0.1以下 |
| 改善が必要 | 0.1を超えて0.25まで |
| 不良 | 0.25超 |
これらはGoogleが定めた「良いスコア」の閾値です。web.devは、モバイルとデスクトップの75パーセンタイルを別々に確認するよう勧めています。
スマートフォンでCLSが厳しくなる理由
同じ動きでも、小さな画面では高いスコアになります。両方の割合がビューポートを基準に測られ、スマートフォンの最も大きい辺が短いためです。前述の式で具体例を挙げます。390 × 844 pxのビューポートいっぱいにコンテンツがあるページの上部に、高さ80 pxのCookieバナーが現れ、すべてを下に押し下げるとします。ビューポートのほぼ全体が影響を受けるので、影響率はおよそ1.0です。移動距離率は80 / 844 = 0.095です。スコアは約0.095となり、上限0.1まであと1つのバナーという状態になります。これは説明のための例で、コンテンツがビューポートを埋めていることを前提としています。
原因はデスクトップと同じですが、より小さな領域で採点されます。web.devは、広告のサイズはデバイスの種類によって異なることがあると指摘しています。そのため、デスクトップのサイズに合わせて確保したスペースは、スマートフォンでは間違いになることがあります。
また、CLSはすべてのブラウザで測定されるわけではありません。web-vitalsライブラリは、onCLS()がChromiumでのみ動作すると示しています。他の関数はFirefoxやSafariでも動作します（web-vitalsのREADME）。web-features 3.44.0（2026年10月）でも、Layout Instability APIはChromeとEdgeでのみ示されています。そのため、このライブラリで実地に収集したCLSはChromium系ブラウザを対象とし、iPhoneのSafariからの訪問はこの方法ではCLSを報告しません。
モバイルで動く要素と修正方法
どの原因にも、コンテンツが届く前にスペースを確保する修正方法があります。web.devのCLS最適化ガイド（2025年2月）によると次のとおりです。
| 原因 | 修正方法 |
|---|---|
| サイズ指定のない画像と動画 | widthとheight属性、またはCSSのaspect-ratio |
| 広告、埋め込み、iframe | min-heightかaspect-ratioでスペースを確保する。広告が表示されないときのためにプレースホルダーを残す |
| ページに差し込まれるバナーやCookie通知 | プレースホルダーでスペースを確保する。またはコンテンツの上に重ねて、ページを動かさないようにする |
| 遅いウェブフォント | font-display: optional、近いフォールバックフォント、サイズを合わせたフォールバックのメトリクス |
| アニメーション | top、left、box-shadowではなくtransformをアニメーションさせる |
画像と動画
各画像に固有のサイズを設定すると、ファイルが届く前にブラウザがボックスを確保できます。
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">img {
height: auto;
width: 100%;
}レスポンシブ画像については、web.devはsrcsetの候補すべてで同じアスペクト比を保つよう勧めています。<picture>の場合は、widthとheightを各<source>と<img>に付けます。新しい画像形式はファイルサイズを変えるだけなので、この問題は解決しません。<picture>のパターンはWebP vs AVIFで説明しています。aspect-ratioは2024年3月からBaselineで広く利用可能です（web-features 3.44.0）。
広告、埋め込み、バナー
想定する最小サイズでスロットのスペースを確保し、スマートフォンでサイズが異なる場合はメディアクエリを使います。
.ad-slot { min-height: 250px; }
@media (min-width: 768px) {
.ad-slot { min-height: 90px; }
}2つの高さは例です。実際の広告サイズを使ってください。web.devは3つのヒントを挙げています。想定する最小サイズを最低値として使うこと、広告が返ってこないときはスペースを縮めず、プレースホルダーを表示すること、遅れて読み込むコンテンツはビューポートの下のほうに置くことです。上部近くに差し込まれたコンテンツは、より大きなシフトを引き起こすからです。Cookie通知は、スクリプトが表示を決めてからページを押し下げるのではなく、オーバーレイにするか、最初の描画から高さを確保してください。
ウェブフォント
web.devによると、見えないテキストもフォールバックフォントでレイアウトされるため、不可視テキストの表示も、無スタイルのテキストの表示も、どちらもシフトの原因になり得ます。web.devは、font-display: optionalと近いフォールバックフォント、サイズを合わせたフォールバックのメトリクス、そして重要なフォントのプリロードを勧めています。値、プリロード、フォールバックのコードは、font-display swapのガイドにあります。
アニメーションと戻るボタン
transformでアニメーションさせてください。transformはレイアウトを発生させません。web.devは、コンポジットされるtranslateのアニメーションはCLSに含まれないと述べています。また、戻る／進むのキャッシュの対象になるようにページを作ることもできます。復元されたページは、ユーザーが離れたときの状態で表示され、読み込みによる繰り返しのシフトは起きないからです。ただし、これは初回の読み込みには効きません。
レイアウトシフトの見つけ方
ラボのツールで要素を特定し、フィールドデータで実際のユーザーに起きているかを確認します。web.devは次の方法を挙げています。
- PageSpeed Insights：フィールドのCLS（Chrome UX Reportより）と、Lighthouseのラボでの CLS を比べます。大きな差は、通常、読み込み後のシフトを示しています。ラボの実行では、これは見えません。
- Lighthouse：監査はずれた要素とその寄与を一覧にしますが、原因ではなく影響を受けた要素を示すことが多いです。
- DevToolsのPerformanceパネル：トレースを記録し、Layout shiftsのトラックを開きます。紫のバーはシフトのまとまりを示し、大きなひし形はより大きなシフトを示します。サマリーには、開始時刻、スコア、ずれた要素が出ます。Layout shift culpritsのインサイトは、CLSの合計と考えられる原因を挙げています（web.dev）。
実際の訪問者でどの要素がずれたかを知るには、web-vitalsの帰属ビルドを追加します。最も大きなシフトの対象、時刻、値を報告します。
import {onCLS} from 'web-vitals/attribution';
onCLS(({value, rating, attribution}) => {
console.log(rating, value, {
target: attribution.largestShiftTarget,
time: attribution.largestShiftTime,
score: attribution.largestShiftValue,
});
});web.devによると、iframe内のシフトはWeb APIでは測定できませんが、Chrome UX Reportには表示されます。Lighthouseなどのツールの実行方法は、Lighthouseでのモバイル監査ガイドとモバイルページ速度テストのガイドを参照してください。
スマートフォン幅でレイアウトを確認する
デスクトップとスマートフォンで異なるレイアウトは、スマートフォンの幅で確認すると見つけやすくなります。Mobile View Extensionは、タブをスマートフォンのユーザーエージェント、画面サイズ、ピクセル比で読み込み直します。そのため、ページのモバイル版を見て、読み込み中に何が動くかを確認できます。CLSや速度の指標は測定できず、デスクトップの回線で動作します。そのため、遅いスマートフォンでページをずらすバナーや広告は、速すぎて気づけないことがあります。上のツールで確認してください。ページがスマートフォンで異なって見えるその他の理由は、ウェブサイトがモバイルで違って見える理由を参照してください。
よくある質問
CLSの良いスコアは何ですか？
0.1以下が良好で、0.25を超えると不良です。これはページ読み込みの75パーセンタイルで測定されます（web.dev、2023年4月）。0.1から0.25の範囲は改善が必要です。
スマートフォンでレイアウトシフトの原因は何ですか？
サイズ指定のない画像と動画、スペースを確保していない広告・埋め込み・iframe、差し込まれたバナーやCookie通知、フォールバックより大きく、または小さく表示されるウェブフォント、レイアウトのプロパティを変えるアニメーションです。割合がより小さいビューポートで測られるため、同じ動きでもスマートフォンではスコアが高くなります。
CLSの原因はどう見つけますか？
DevToolsのPerformanceパネルでトレースを記録し、Layout shiftsのトラックを開きます。その後、サマリーでずれた要素を確認します。実際の訪問者については、web-vitalsの帰属ビルドを使い、largestShiftTargetを報告させてください。
CLSはSEOに影響しますか？
Googleは、検索で成功するために良好なCore Web Vitalsを推奨し、主要なランキングシステムが報いようとするものと一致すると述べています。ただし、直接のランキング要素とはしていません（Google Search Central、2025年12月更新）。直接の影響は、ページが跳ねたときに読んでいた位置を失う訪問者に現れます。