CLS対策の進め方｜レイアウトシフトを4つの発生源に分けて直す手順

CLSの改善は、原因を4種類に分けた時点でほぼ終わる

結論を先に書きます。CLS（Cumulative Layout Shift）が悪化する原因は、実務上「寸法を指定していない要素」「後から差し込まれる要素」「Webフォントの切り替え」「操作なしで挿入される要素」の4種類しかありません。どれに当たるかを特定すれば、対策は各原因に対応した1つの手当てで済みます。改善が長引くのは、原因の特定を飛ばして施策を並べているときです。

この記事は、自社サイトをCMSで運用しているWeb担当者を想定しています。制作は外部に頼み、その後は自分たちで記事や商品を追加してきた。途中で広告タグ、チャットツール、バナー、Webフォントを足してきた。そういう状態のサイトで、Search Consoleに「改善が必要」と表示されたところから読み始める方向けです。エンジニアが常駐していて日常的に計測している組織には、本記事の粒度は粗すぎます。

CLSは「ページのライフサイクル全体で発生した予期しないレイアウト シフトの最大バースト」を測る指標で、優れたユーザー体験のためにはスコアを0.1未満に収めることが推奨されています。スコアは「layout shift score = impact fraction × distance fraction」、つまり不安定な要素がビューポートに与える影響率と、要素が移動した距離率の掛け算で算出されます（出典：web.dev「Cumulative Layout Shift（CLS）」最終更新 2023年4月12日）。この式から読み取れるのは、画面の大部分を占める要素が大きく動いたときに最も悪化するということです。小さなアイコンのずれを直すより、ファーストビューの主要ブロックの動きを止めるほうが効きます。

Search Consoleの「改善が必要」は何を意味しているのか

Core Web Vitals レポートでは、CLSは0.1以下が「良好」、0.25以下が「改善が必要」、0.25超が「低速」に分類されます（LCPは2.5秒以下／4秒以下／4秒超、INPは200ms以下／500ms以下／500ms超）。データはCrUXレポートに基づいており、「実際にユーザーが URL にアクセスしたときのパフォーマンス時間について、匿名化された指標（フィールド データ）が収集されます」と説明されています。URLは体験が類似するページにグループ化され、「グループ内のすべての URL へのアクセスの 75% は、表示されるグループ ステータスに該当します」とされています（出典：Google Search Console ヘルプ「Core Web Vitals レポート」）。

ここから実務上の結論が2つ出ます。1つ目は、レポートの数値は自分のPCで測った値ではなく実ユーザーの分布であるため、手元の環境で再現しなくても問題は存在しうるということ。2つ目は、URLがグループ単位で扱われるため、テンプレートを直せばグループ全体が同時に動くということです。個別ページを1つずつ直す発想は、CMS運用のサイトでは効率が悪くなります。

現場で起きるCLSの失敗パターン

失敗1：記事本文に画像を貼るとき、幅と高さを指定していない

CMSの管理画面から画像をドラッグして貼る運用では、width と height が付かないまま公開されることがあります。画像の読み込みが終わるまでスペースが確保されず、読み込み完了と同時に本文全体が下へ押し出されます。本文は画面の大部分を占めるため、影響率が大きく、スコアへの寄与も大きくなります。

失敗2：ヘッダー直下にお知らせバーやキャンペーンバナーを後から差し込んだ

後から追加した要素がページ上部に入ると、その下にある全コンテンツが移動します。距離率も影響率も大きくなるため、単体で「改善が必要」に転落させる力があります。追加した当日は誰も気付かず、数週間後にレポートで発覚するのが典型的な流れです。

失敗3：Webフォントの切り替えで、見出しと本文が一斉にずれる

Webフォントがダウンロードされる前は代替フォントで描画され、切り替わった瞬間に文字の幅が変わります。web.devは、フォント読み込み前にFOUTまたはFOITが発生してテキストが移動すると説明し、対策として font-display: optional の使用、適切なフォールバックフォントの指定、size-adjust などのAPIによるサイズ差の最小化、<link rel=preload> による重要フォントの早期読み込みを挙げています（出典：web.dev「Cumulative Layout Shift（CLS）を最適化する」最終更新 2025年2月7日）。

失敗4：チャットツールやレコメンドが、操作なしにコンテンツを挿入する

ユーザーが何もしていないのに要素が現れる形は、そのまま予期しないシフトになります。web.devは、初期レイアウトでスペースを予約する、固定サイズのコンテナ内で古いコンテンツを置き換える、ユーザーの操作を起点に読み込ませる、という3つの方向を示しています。

そのまま使える判断軸：シフト源4分類

本記事では、CLSの原因を発生源で4つに分け、分類ごとに対策を1つに固定する枠組みをシフト源4分類と呼びます。上から順に確認し、当てはまったところで対策を実施して再計測する、という使い方をします。複数を同時に直すと、どれが効いたか分からなくなります。

分類	見分け方	対策	効きやすい場所
寸法未指定型	画像・動画・iframe に width/height または aspect-ratio がない	サイズ属性を付ける、CSS の aspect-ratio でスペースを予約する、高さに固定値を使わず height: auto を設定する	記事本文、商品一覧
後入れ挿入型	広告・埋め込み・お知らせバーが読み込み後に出現する	min-height でスペースを予約する、aspect-ratio を使う、読み込みが遅い要素をビューポート下部に置く	ヘッダー直下、サイドバー
フォント切替型	初回表示時に文字の幅が変わって行が動く	font-display: optional、フォールバックフォントの指定、size-adjust、重要フォントの preload	見出し、本文全体
動的注入型	操作していないのに要素が現れる	初期レイアウトでスペースを予約する、固定サイズのコンテナ内で置き換える、ユーザー操作を起点にする	チャット、レコメンド、通知

確認手順（上から順に、1つずつ）

1. Core Web Vitals レポートで「改善が必要」のURLグループを開き、代表URLを1つ選ぶ
2. そのページのテンプレートを特定する。記事詳細か、一覧か、商品詳細か
3. 本文領域の画像に寸法指定があるかを確認する。なければ寸法未指定型として先に対処する
4. ページ上部に後から追加した要素がないかを、公開履歴と照らして確認する
5. 初回表示で文字が動くかを、キャッシュを消した状態で目視確認する
6. 操作なしで現れる要素を数える。1つでもあれば動的注入型として扱う
7. 1つ対策したら再計測する。CrUXは実ユーザーのデータを集計するため、反映には時間差がある前提で待つ

手順6までで原因が絞れない場合、原因はテンプレートではなく個別ページの記述にあります。表示速度全体の考え方はCore Web Vitals の見方、画像まわりの最適化は画像SEOの基本、CMSのテーマ側に原因がある場合はテーマ選定の観点を参照してください。

テンプレート別に、どこを最初に見るか

Core Web Vitals レポートがURLをグループ単位で扱う以上、点検の単位もテンプレートになります。テンプレートごとに、経験上シフトが集中する場所は決まっています。以下の表は、点検の開始地点を決めるためのものです。上から全部を見るのではなく、自社のレポートで「改善が必要」になっているグループに対応する行だけを見てください。

テンプレート	最初に疑う場所	該当しやすい分類	直したときの波及範囲
記事詳細	本文中の画像、アイキャッチ、目次の開閉	寸法未指定型、動的注入型	記事全件
商品詳細	メイン画像の切り替え、レビュー欄の読み込み、在庫表示	寸法未指定型、後入れ挿入型	商品ページ全件
一覧・カテゴリ	サムネイルの寸法、無限スクロール、絞り込みの再描画	寸法未指定型、動的注入型	一覧ページ全件
トップページ	ヒーロー画像、お知らせバー、スライダー	後入れ挿入型	1ページのみ
フォーム	エラーメッセージの表示領域、確認事項の展開	動的注入型	フォーム全件

この表で注意すべきなのは、トップページだけは波及範囲が1ページに閉じることです。訪問数が多いため気になりますが、改善作業の投資効率で見れば、記事詳細や商品詳細のテンプレートを直すほうが先になります。どのテンプレートに何ページ属しているかを数えてから着手順を決めてください。

修正の記録を残さないと、同じ問題が再発する

CLSの厄介な点は、一度直しても運用の中で戻ることです。新しいバナーを足す、タグを1つ追加する、記事に画像を貼る。日常の更新作業のどれもが、シフトの原因を再び持ち込みます。再発を防ぐ方法は技術的なものではなく、運用のルールを短い形で残すことです。

1. ページ上部に要素を追加するときは、追加前に高さを決め、その高さをCSSで固定してから中身を入れる
2. 画像を本文に貼る手順書に「寸法が入っているか」の確認項目を1行足す
3. 外部タグを追加した日付を記録する。レポートが悪化したとき、追加日と突き合わせれば原因の候補が絞れる
4. テンプレートを改修したら、対象グループのURL数と改修日をメモする。CrUXの反映を待つ期間の目安になる
5. 四半期に一度、Core Web Vitals レポートのグループ構成が変わっていないかを確認する

これらはいずれも作業としては数分で終わりますが、記録がない状態では「いつから悪化したのか」を特定できず、原因の切り分けに何倍もの時間がかかります。CLSの改善で実際に工数を食うのは修正そのものではなく、原因の特定です。記録は、その特定にかかる時間を短くするための投資だと考えてください。

直す順番を決める3つの条件

複数のテンプレートが同時に「改善が必要」になっている場合、次の3条件で順番を決めます。条件はこの順に優先します。

優先順位	条件	判断の仕方
1	問い合わせや購入の直前にあるか	フォーム、カート、商品詳細を先に直す。取りこぼしが金額に直結するため
2	属しているURL数が多いか	1回の修正で動くページ数が多いテンプレートを優先する
3	原因が1つに絞れているか	分類が確定しているものから着手する。複合しているものは後回しにする

この順番を守ると、最初の1〜2回の修正で成果が確認できるため、社内で継続の合意を取りやすくなります。逆に、原因が複合していて波及範囲も小さいページから着手すると、工数をかけたのに数値が動かず、施策そのものが止まりやすくなります。

CLSの改善は、どの経路で売上に効くのか

CLSは検索順位の一要素であると同時に、ページ内での離脱に直接効きます。経路を分けると次の式になります。

問い合わせ数 = 表示回数 × クリック率 × ページ滞在の継続率 × 入力完了率

CLSが悪いときに落ちるのは、後半の2つです。読もうとした瞬間に文章が動く、押そうとしたボタンが移動する、入力途中のフォームがずれる。この3つは、順位やクリック率とは無関係に、すでに来ている訪問者を取りこぼします。つまりCLSの改善は「新しい流入を増やす施策」ではなく「すでに払った獲得コストの歩留まりを上げる施策」として評価するのが正確です。

計算の型は次のとおりです。数値はすべて自社の実測値に置き換えてください。

変数	取得元	自社の値
対象テンプレートの月間セッション数	アクセス解析	（　）
改善前の問い合わせ転換率	アクセス解析のコンバージョン	（　）％
改善後の問い合わせ転換率	改善後、同期間で再計測	（　）％
問い合わせからの受注率	営業管理データ	（　）％
平均受注単価	受注管理・会計	（　）円

増分は「月間セッション数 ×（改善後の転換率 − 改善前の転換率）× 受注率 × 平均受注単価」で計算できます。テンプレート単位で直せば同じグループのURL全体に効くため、1回の修正が全ページ分の分母に掛かる点が、この施策の投資効率を決めています。修正にかかった工数に自社の人件費単価を掛けたものが投資額で、上の増分で割れば回収月数が出ます。

よくある質問

手元のブラウザで測ったら数値が良いのに、Search Consoleでは「改善が必要」と出ます

Core Web Vitals レポートのデータはCrUXに基づく実ユーザーのフィールドデータです。手元の回線速度や端末は、実ユーザーの分布とは一致しません。また、グループ内アクセスの75%が該当ステータスになるという集計のため、一部の遅い環境の体験が反映されます。手元の値ではなく、レポートの分布で判断してください。

CLSはどこまで下げれば十分ですか

web.devは0.1未満を目安として示しています。Core Web Vitals レポートでも0.1以下が「良好」です。0.1を切ったあとにさらに下げる作業は、他の指標や本文の改善に比べて優先度が下がります。

直したのにレポートの数値が変わりません

CrUXは実ユーザーのアクセスを集計するため、修正の反映には時間差があります。加えて、URLがグループとして扱われるので、同じテンプレートの他のページに未修正の要素が残っていればグループのステータスは動きません。直したページ単体ではなく、テンプレート全体を見直してください。

広告を載せていると、CLSは諦めるしかないですか

web.devは広告や埋め込みに対して、min-height でスペースを予約する、aspect-ratio を使う、読み込みが遅いコンテンツをビューポート下部に配置する、という対策を挙げています。枠の高さを先に確保できれば、広告の読み込み自体はシフトの原因になりません。

CLSを直せば検索順位は上がりますか

順位が上がると断定できる根拠は公開情報にはありません。確実に言えるのは、CLSが悪いと読者がページ内で操作を誤りやすくなり、すでに獲得した訪問を取りこぼすということです。順位への期待ではなく、歩留まりの改善として投資判断するのが妥当です。

まとめ：分類してから直す

CLSの改善で最も無駄が出るのは、原因を特定しないまま複数の対策を同時に入れることです。シフト源4分類で発生源を1つに絞り、対応する対策を1つ実施し、CrUXの反映を待って再計測する。この順序を守れば、テンプレート単位の修正がURLグループ全体に効き、少ない工数で「良好」に届きます。

参考にした一次情報

• web.dev「Cumulative Layout Shift（CLS）」（最終更新 2023年4月12日）https://web.dev/articles/cls?hl=ja
• web.dev「Cumulative Layout Shift（CLS）を最適化する」（最終更新 2025年2月7日）https://web.dev/articles/optimize-cls?hl=ja
• Google Search Console ヘルプ「Core Web Vitals レポート」https://support.google.com/webmasters/answer/9205520?hl=ja