内部改善ロードマップ Vol.7【前編】｜CLS（レイアウトシフト）の実務対策：画像・広告・フォント・UIの揺れを防ぐ設計ガイド

「読んでる途中で広告がズレてきた…!?」
「タップしようとしたボタンが急に動いて押し間違えた…！」

こんな “レイアウトのガタつき” をまとめて数値化した指標が CLS（Cumulative Layout Shift） です。
しかも、原因はわりとはっきりしていて、

• 画像サイズが未指定

• 広告の遅延描画

• Webフォントの読み込み待ち

• アコーディオンや目次など動的UIの開閉

このあたりに集中していることが多いんです。

本記事（前編）では、CLSを
「測る → 見つける → 設計で未然に防ぐ」
という流れで、実務向けに体系化します。

特定ピクセル値や広告コードなど環境依存の部分には踏み込みすぎず、
どのCMS・どのテーマでも再現できる“設計の型” に落とし込んで解説します。

「画像・広告・フォント・UIの揺れ」が起きる理由と、
“揺れをゼロに近づける”ための考え方をセットで整理していきます！

本記事でわかること

• CLSの見つけ方（簡易ルート＋ラボ/フィールド両面）
  どこでレイアウトシフトが起きているかを“最短”で把握する方法。

• 画像・動画・埋め込みのサイズ宣言とプレースホルダ設計
  width/height・aspect-ratio をどう使うか、どこまで指定すれば十分か。

• 広告・ウィジェットの予約枠の作り方と差し替え戦略
  記事冒頭やファーストビュー周辺でズレないための枠設計の型。

• フォント読み込みの安定化（FOUT/FOIT対策）
  “フォントの一瞬のズレ”を防ぐための、メトリクス、サブセット、読み込み戦略。

• 動的UI（アコーディオン・目次・通知バー）の安全な開閉
  開閉しても周囲が押し出されないための、最低限の実装ルール。

初心者〜中級の方でも、
「この順番で見直せば CLS は確実に下がる」
という実践ロードマップとして使える内容になっています。

まず“どこでズレるか”を見つける

レイアウトシフトは「なんとなく起きている気がする」では対策できません。
まずは “どの要素が、どのタイミングで、どれくらい動いているか” を特定するところからスタートします。

実務では、
①ラボ（ツール）での目視確認 → ②フィールド（実利用）での傾向把握
この2段構えで見るのが最短ルートです。

読み進めながら「自分のサイトならどこが怪しい？」と当てはめてみてください！

観測の型 — ラボ（ツール）で発生箇所を目視＋フィールドで傾向を見る

まずは ラボ環境（手元のPC・計測ツール）で“現象を再現”すること が重要です。

ラボ側では、

• 記事ページを開いて スクロールしながら動く要素を目で追う

• 遅延読み込みの画像が読み込まれた瞬間に コンテンツが押し下がっていないか

• 記事冒頭に広告が差し込まれた瞬間に 文字がずれていないか

• フォント適用の瞬間に 見出しのサイズがピョンと変わっていないか

こういった「目視でしか見つからない動き」が大量に見つかります。

一方、実際のユーザー環境での挙動＝フィールドデータ も欠かせません。
フィールド側では、

• 特定ページだけCLSが高い のか

• 特定端末（スマホ/タブレット）でだけ悪化している のか

• 広告回りだけ急にCLSが増えている のか

といった “傾向” を把握します。ラボでは再現しなくても、フィールドでは起きていることはよくあります。

この ラボ×フィールドの二重チェック が、CLS診断の土台になります。

よくある発生帯 — ファーストビュー直下／記事冒頭の広告差し込み／目次展開／画像lazy直後

実際に多くのブログ・メディアで CLS の原因になっている箇所をまとめると、
“繰り返し出てくるパターン” がほぼ固定しています。

▼ 1. ファーストビュー直下の「広告・SNSウィジェット」

ページを開いた瞬間の、
「ヘッダーのすぐ下」「タイトル直下」
はもっともズレが起きやすいゾーンです。

理由はシンプルで、
広告やウィジェットが遅延読み込み → 後から差し込まれ → 既存テキストを押し下げる
という流れがほぼ毎回発生するため。

▼ 2. 目次の開閉（アコーディオンUI）

「目次を開いた瞬間に本文が押し下がる」
これは初心者〜中級で特に多いパターンです。

目次は高さが可変なので、
“閉じたときの高さを基準にした設計” をしてしまうとズレが発生します。

▼ 3. lazyloadした画像の直後

画像の寸法が宣言されていないと、
lazyloadの読み込み完了時に ガクッ とズレます。

幅・高さ・aspect-ratio の未指定が原因。

▼ 4. 記事途中の広告（インフィード・レコメンド）

読み進めたタイミングで広告が入るタイプは、
“高さ未定 → 読み込み後にドンッと現れる”
という動きが発生しがちです。

これらの “よくある発生帯” を押さえておくと、
あなたのブログにも 必ず同じパターンが潜んでいる のが見えてくるはずです。

次の章からは、これらの原因を 設計段階でゼロに近づける方法 を解説していきます！

画像・動画・埋め込みの安定化

CLSの大半は、じつは 「メディア要素のサイズ宣言不足」 が原因です。
画像や動画、iframe など “後から読み込まれるもの” は、
「どれくらいのスペースを使うか」 を事前に宣言しない限り、
読み込み完了時に周囲のコンテンツを押し下げてしまいます。

逆に言えば、
“枠を先に用意する” だけでかなりのCLSが消える
ということでもあります。

ここでは、どのCMSでも再現できる メディア安定化の型 をまとめていきます。

寸法を“属性で”宣言 — width/height または aspect-ratio を常に指定

画像のレイアウトシフトは、
width と height が指定されていないこと がほぼすべての原因です。

「CSSでサイズ決めてるから大丈夫っしょ？」
と思いがちですが、CLS観点では HTML属性（width/height）側に値があるかどうか が超重要です。

▼ なぜ属性が必要なの？

ブラウザは属性を読むことで、
読み込み前に“縦横比”を算出 → 空き枠を確保
できます。

この「縦横比の宣言」があるだけで、
画像が読み込まれる前から安定したスペースができます。

▼ aspect-ratio も有効

最近は CSS の aspect-ratio もよく使われます。
比率だけ分かれば、あとは CSS 側で柔軟にサイズ調整可能なので、

• 画像をレスポンシブにしたい

• 幅が可変のCMSテーマを使いたい

という場合にとても便利です。

▼ 実務の判断基準

• どんなCMSでも：width/heightを付けるのが最優先

• 比率だけ管理したい：aspect-ratioで宣言

• iframeや埋め込み：外枠の比率（縦横比）をCSSで固定

このセットが “ほぼ万能” の安定化パターンです。

プレースホルダ設計 — 余白を確保するダミー枠／低解像度プレビュー

画像を lazyload していると、
読み込みまでの一瞬が「何もない状態」 になりがちです。
この “空白状態” が、もっともズレを生みやすい時期。

ここで役立つのが プレースホルダ（仮枠） の設計です。

▼ プレースホルダの役割

• 画像がロードされる前に 高さ を確保する

• 読み込み中でも「ここが画像ですよ」と分かる

• テキストが押し下がるのを防止する

▼ よく使われる3パターン

① aspect-ratio + 背景色のシンプル枠

もっとも軽量で、画像以外でも使えます。

② 低解像度プレビュー（LQIP）

ぼかしプレビューを置いておく手法。
視覚的な違和感が少ないので、メディア系サイトとも相性良し。

③ 透明なSVGで比率確保

とても軽く、比率が正確。広告や埋め込みでも使えます。

▼ 実務で大事な考え方

プレースホルダは “仮の画像”ではなく、“予約席” のようなもの。
「ここにこれくらいのスペースが必要だよ」と最初から告げておくだけで、
CLSはごっそり消えます。

iframe/埋め込み — 固定の外枠サイズ＋内側スクロールで吸収

iframe や外部ウィジェットは
“中身の高さが読み込み後に変わる”
という特徴があるため、CLSの原因になりやすい要素の筆頭です。

▼ 安定させる鉄則：外枠だけでも固定する

iframeの中身は制御できませんが、
外枠（親コンテナ）の高さを固定 or 比率固定 することで
ほぼ100% レイアウトシフトを防げます。

▼ どんなウィジェットでも応用できる型

• 親要素に aspect-ratio（または固定高さ） を設定

• iframeには width:100% / height:100% / borderなし

• 中身の高さが変わっても、外枠の中でスクロールさせる・余白で吸収させる

▼ 特に注意すべきケース

• SNS埋め込み（X/Instagram/YouTube）

• レコメンド系ウィジェット

• 広告のインフィード枠

これらはロード後に高さが変わる前提なので、
“外枠を先に決める” 設計は必須です。

広告・ウィジェットの予約枠

CLSをもっとも生みやすい領域といえば、間違いなく 広告まわり です。
特に「ファーストビュー直下」「記事冒頭」「目次の近く」「記事中のインフィード」など、
読者が注視しているゾーンに “後から広告が差し込まれる” と、一気にズレが発生します。

しかし、広告は非同期で読み込まれ、サイズも状況次第。
完全に統一するのは難しいですよね？

そこで前提を変えます。

広告は「後から来る」のが普通 → だから最初に“席だけ”用意しておく。

この発想に切り替えるだけで、CLSがガクッと下がります。
ここからは ほぼすべての広告・ウィジェットに使える安定化の型 をまとめます。

確保の原則 — 差し込み位置に最低限の高さを先に確保

広告でレイアウトが崩れる最大の理由は、
表示前の高さが0 → ロード後に高さが出て押し下がる
という動きが起きるためです。

ということは、解決策はシンプル。

“読み込み前から、広告が入りうる高さを確保しておく”

これがすべての基本になります。

▼ 座席予約のやり方（概念）

• その広告枠が とり得る最小〜最大の高さ を把握する

• 最小値より少し余裕を持った 固定高さ or aspect-ratio を指定

• 非表示の瞬間も高さ0にしない（特にレスポンシブ広告）

▼ この方法のメリット

• 実際に広告が来る前に スペースが確定

• 読み込み後に 高さが変化しにくい

• 記事本文が上下に動く量を限りなくゼロに近づけられる

▼ 注意点

広告ネットワークによっては、
“実際の高さ” が微妙に変わることがあります。

そのため 少し余裕を持った最低限の高さ の確保がポイント。
ギチギチに合わせるほどズレやすくなります。

差し替え戦略 — 未読込時は簡易プレースホルダ→後から本体に置換

広告が非同期で読み込まれる以上、
「枠だけ先に確保する」という発想は合っています。

でも、ただの空白だと見た目が不自然ですよね？
そこで使えるのが 差し替え型プレースホルダ です。

▼ 差し替え戦略の流れ

1. 広告枠のプレースホルダ（仮枠）を先に描画

   • aspect-ratio

   • 背景色

   • シンプルな「広告準備中」風のダミー要素

2. 広告本体が読み込まれたら
   → プレースホルダをそのまま置換するだけ

この方式なら、読み込み前後で高さが変わらないため
CLSがゼロ に近づきます。

▼ 実務で多いパターン

• 記事中の インフィード広告

• ファーストビュー直下の レスポンシブ広告

• フッター前の レコメンド枠

これらはほとんど「予約枠＋差し替え」で安定します。

崩れの典型 — レスポンシブ広告の遅延描画／見出し直下のサイズ変動

広告まわりのCLSで、特に“やられがちなパターン”をまとめておきます。

▼ 典型1：レスポンシブ広告の急な伸び縮み

レスポンシブ広告は、画面幅によって 高さが自動調整 されます。
これが最大の落とし穴。

• 600px の高さで来る日もあれば

• 250px で収まる日もある

この変動がそのままCLSの原因になります。

→ 対策：高さの上限を決める / 最低枠を確保する

▼ 典型2：見出し直下の広告が遅延表示で押し下げる

H2/H3 のすぐ下に広告を置くテーマは多いですが、
ここに “高さ0” のまま広告をロードすると、
見出しがガクッと押し下がって読者が迷子になります。

→ 対策：見出しと広告の間に「最低限の空き枠」を常に確保

▼ 典型3：外部ウィジェットの高さ変動

レコメンドウィジェットなどは、
ロード後にアイテム数が確定 → 高さが変動
という流れがほぼ必ず発生します。

→ 対策：外枠を高さ固定 or 比率固定にする

広告は唯一、
「何がいつ、どんな高さで来るか完全には制御できない」
という特殊な存在です。

だからこそ、
“座席を先に決めておく”
という設計の転換がCLS対策のカギになります。

フォントの安定化

画像や広告の次に、じわじわとCLSを悪化させるのが フォント読み込みの“遅れ” です。
Webフォントが読み込まれる瞬間に、

• 見出しが急に太くなる

• 本文の文字幅が微妙に変わる

• 1行あたりの文字数が変わって段落がズレる

といった “フォント特有の揺れ” が起きます。

これらはパッと見では気づきにくいのですが、
CLSの中では かなり高頻度 に発生する要素です。

ここからは、フォントの読み込みを安定させるための
“実務で再現しやすい方針セット” をまとめます。

FOUT/FOITの回避 — 代替フォントのメトリクス近似／表示戦略のスワップ方針

フォント読み込み時の揺れには、2つの現象があります。

• FOUT（Flash of Unstyled Text）
  → 最初にシステムフォントで表示され、後からWebフォントに切り替わる

• FOIT（Flash of Invisible Text）
  → Webフォントの準備が整うまで“文字が見えない”状態が続く

どちらもユーザー体験に影響し、CLSの揺れにも直結します。

▼ 対策1：代替フォントのメトリクス（字幅）を近づける

もし Webフォントとシステムフォントの 字幅（メトリクス）が近ければ、
切り替え時のズレはほぼゼロ になります。

日本語は完全一致が難しいものの、

• 「本文はシステムフォント中心」

• 「見出しだけWebフォント」

のように用途を絞ると、揺れがほぼ見えない状態まで抑えられます。

▼ 対策2：font-display: swap（もしくは optional）

実務では font-display: swap が最も扱いやすい選択です。

• 読み込み中はシステムフォントで表示

• 完了したらすぐ Webフォントに切り替え

これで FOIT（文字が消える）を防げます。
CLSへの影響も最小限にできます。

「もう少し慎重に切り替えたい」という場合は
optional を使うと「ネットワーク状況が悪ければシステムフォントのまま」にできます。

サブセット/事前接続 — 文字セットを使う分だけ／事前接続で待ちを短縮

フォントの読み込みが遅いと、
切り替えのタイミングが遅れ → レイアウトの変動も大きくなります。

ここでは 読み込みスピード自体を改善する方針 をまとめます。

▼ サブセット化（必要な文字だけロード）

Webフォントは「必要な文字だけを含む軽い版」を配布できる場合があります。
これだけで読み込みサイズが減り、CLSを起こすまでの時間が短縮されます。

特に、

• 見出し専用の太字フォント

• 英数字だけのキャッチ系フォント

などは、フルセットではなくサブセット版を選ぶのが定石です。

▼ 事前接続（preconnect）

フォントCDNに早めに接続しておくことで、
「待ち時間」を数百ミリ秒単位で削減 できます。

これにより、フォント切り替えまでの秒数が短くなり、
CLSの発生リスクも下がります。

見出しと本文で分離 — 見出しのみWebフォント、本文はシステムフォント等の折衷

意外と効果が大きいのが
「Webフォントを欲張らない」 という運用方針です。

見出しも本文も全部Webフォントにすると、
読み込み遅延が増え、切り替え時のズレ幅も大きくなります。

そこで実務ではこんな分離が鉄板です。

▼ 分離パターン（おすすめ）

• 本文：システムフォント（最速で表示、揺れない）

• 見出し：Webフォント（アクセントをつける）

こうすることで、

• フォントサイズのズレが発生する「面積」が小さくなる

• CLSの変動幅も最小限に抑えられる

• デザイン性も両立できる

というメリットが得られます。

▼ どんなサイトにも向いている理由

本文は読む時間が長いため、
可読性＝安定性が最優先。
ここにWebフォントを使うと揺れがダイレクトにCLSへ響きます。

一方、見出しは「固定配置の少量テキスト」なので、
多少の切り替えでも読者のストレスが少ない。
デザイン性を保つならこちらに限定するのが王道です。

フォントの安定化は、
“派手ではないけれど確実に効くCLS対策” の代表格です。

次は、読者操作によるズレが最も起こりやすい
「動的UIの安全な開閉」 に進みます。

動的UIの安全な開閉

CLSが発生するのは “読み込み時” だけではありません。
記事を読んでいる途中で、

• 目次を開いたとき

• アコーディオンを展開したとき

• 通知バーが画面にニュッと出てきたとき

こういった 「動的UI（ユーザー操作で高さが変わる要素）」 が、
本文を押し下げたり、スクロール位置をズラしたりしてしまうことがあります。

しかもこれは読者が 操作の瞬間に発生する ため、
体感ダメージがかなり大きいタイプのCLSです。

ここでは、動的UIの開閉を “揺れない形” にするための設計原則 をまとめます。

アコーディオン/目次 — 開閉で周囲を押し出さないレイアウト（高さ確保・スクロール補正）

目次やアコーディオンUIは、
「開閉で高さが変わるもの」 の代表です。

なにも対策せずに開閉させると、
本文が一気に押し下がって読者の視線が迷子になり、
結果として大きなCLSにつながります。

▼ 原則1：開く前提の高さ（または最小枠）を確保する

実務では2つの方式があります。

① 開閉時に高さを固定（max-heightなど）

中身が100%可変でないなら、
あらかじめ 最大高さ（または想定上限）をCSSで保持 する方法。

② 開閉後のスクロール位置を補正する

目次のように中身が可変の場合は、
開閉した瞬間、元の位置にスクロールを戻す ことで押し下げを打ち消す方法です。

▼ 原則2：アニメーションは「高さ固定」前提で設計

アニメーションを height の可変でやると、
ブラウザが再レイアウトを何度も計算するため、
細かいズレが多発します。

→ 対策としては

• transform（スライド）

• opacity（フェード）

など、レイアウトを変えないアニメーション に寄せると安定します。

通知バー・クッキーバナー — ビューポート侵入時に本文を押し下げない設計

通知バーやクッキーバナーは、
多くのサイトで「後から画面に侵入してくる」タイプのUIです。

これが最悪で、
本文を押し下げる → 読者のタップ位置がズレる
というCLSの温床になります。

▼ 原則：本文を押し下げず “かぶせる” 方式が基本

通知バーは、
画面上部 or 下部に固定して重ねる（position: fixed）
方式にすると、本文には一切影響しません。

▼ バナーを閉じる時も揺らさない

閉じるときも同様で、

• height を0にする → 押し上げが発生（NG）

• opacity や transform でフェードアウト → 押し上げゼロ（OK）

という違いがあります。

“レイアウト変更を伴わない動き” にするのが重要です。

実装ポリシー — アニメーションは高さ一定を前提に

動的UIでやりがちなミスが、
「height のアニメーション」 を使うことです。

高さが変わるアニメーションは、
途中で何度も再レイアウトが発生し、
CLSが出るだけでなくスクロール位置もガタつきます。

▼ 実務での安定パターン

• 開閉は基本 display切り替え or transform

• サイズ可変の要素は max-heightで上限固定

• フェードイン/アウトは opacityのみ

• スライドは translateYのみ（上下の余白は固定）

これらはすべて、
“レイアウトが変わらない” アニメーション
として扱われるため、CLSのリスクをほぼゼロにできます。

動的UIは読者の操作に直結するため、
小さな揺れでも大きなストレスに感じられる領域 です。

この章の設計原則を押さえておくと、
目次・バナー・アコーディオンなど “動くUI全般” が安定し、
記事読み体験の質が大きく向上します。

まとめ：CLS対策は“先に枠を確保”——画像・広告・フォント・UIの予約と宣言で揺れをゼロへ

CLS（レイアウトシフト）は、
「読み込み後に高さが変わる要素」 をどれだけ事前に制御できるかで決まります。

本記事で扱ったように、

• 画像・動画は width/height や aspect-ratio を宣言

• 広告・外部ウィジェットは 座席（予約枠）を先に用意

• フォントは 代替フォントのメトリクス調整＋font-display

• 動的UIは 高さの変動を起こさない設計＋スクロール補正

という “設計段階でのひと工夫” が、CLS改善のほぼすべてです。

華やかなテクニックよりも、
「最初にスペースを確保する」 という基本を徹底するだけで、
読者の視線もタップ位置も安定し、記事体験がグッと快適になります。

次の後編では、CLSと並んで悩みの多い INP（操作→反応の遅さ） を扱います。
「見た目の揺れを止める」から「反応の遅さを減らす」へ。
内部改善をさらに一段深く進めていきましょう！

用語ミニ辞典

CLS（Cumulative Layout Shift）

ページ閲覧中に 要素が予期せず動いた量 を数値化した指標。
画像のサイズ未指定、広告の遅延描画、フォント切り替え、UI開閉などが原因となり、
読者の視線やタップ位置を狂わせる“体験劣化”に直結します。

FOUT / FOIT（フォント読み込み時のちらつき）

FOUT: まずシステムフォントで表示され、後からWebフォントに切り替わる現象。
FOIT: Webフォントが読み込まれるまで 文字が見えない 時間が発生する現象。
どちらもCLSの原因になりやすく、font-display や代替フォント調整で防ぎます。

プレースホルダ（placeholder）

画像・広告などが読み込まれる前に スペースだけ先に確保する“仮枠” のこと。
aspect-ratio や低解像度プレビューを使い、
後から本物の要素が来てもレイアウトが動かないようにする設計手法です。

別記事への導線（キーワード入り）

Vol.7【後編】｜INPの実務対策：イベント処理・第三者スクリプト・初回相互作用を軽くする設計

操作してから画面が動くまで“モッサリ”する原因を洗い出し、
INPを下げるための 発見→削減→分離→遅延 のロードマップを詳しく解説します。

Vol.4【後編】復習｜画像配信のlazy・優先度・srcsetでCLSとLCPを同時にケア

画像の遅延読み込みや優先度設定を見直すことで、
CLS（揺れ）とLCP（読み込み速度） の両方を改善する再入門ガイド。

今回はここで終わりにしたいと思います！

最後までお読みいただきありがとうございました！

このブログでは「ChatGPT×副業」をテーマに、AIをフル活用したリアルな副業チャレンジを発信しています🎶

むずかしい話はナシで、「ちょっとやってみたいかも」と思えるような内容を目指しています😁

私は現在、ChatGPTを使ってTシャツのデザインを作って販売したり、

LINEスタンプのキャラ制作に挑戦したりしています👍

デザインの知識ゼロでも、AIの画像生成機能を使えばかなりいい感じになりますよ！

ブログの内容やSEO対策も、ぜんぶChatGPTに相談しながら書いています。

アイデアが出ないときも、相棒みたいに助けてくれます🎶

さらに、楽天ルームのレビュー文章もChatGPTと一緒に考えたり、

X（旧Twitter）の投稿や運用方法も提案してもらったりと、あらゆる場面でAIに頼っています。😅

「AIって便利そうだけど、自分にも使えるのかな？」

と思っている人には、ぜひ読んでほしいです。

このブログは、AI初心者でも副業が始められるように、

体験ベースでわかりやすく書いています。

私の成功も失敗もまるごとシェアしていくので、よかったら気軽に読んでいってくださいね。

Xでも日々の活動をゆるっと更新しているので、ぜひのぞいてみてください！

明日のあなたがより豊かになりますように😌

それでは、おやすみなさい😴