Cumulative Layout Shift (CLS) とは何か、その改善方法

Cumulative Layout Shift (CLS) とは？

Cumulative Layout Shift (CLS) は、Core Web Vitals の「視覚的安定性」を担う指標です。Cumulative Layout Shift (CLS) は、コンテンツがレンダリングされたり、新しいコンテンツがページに表示されたりする際のページの動きを測定します。ページのどの程度の範囲が予期せず移動しているか、そしてどの程度の距離を移動しているかに基づいてスコアを算出します。このようなコンテンツの移動は非常に煩わしく、読み始めた記事の場所を見失ったり、さらに悪い場合には間違ったボタンをクリックしてしまう原因となります。

良好な Cumulative Layout Shift (CLS) スコアとは？

良好な CLS スコアは 0 から 0.1 の間です。CLS スコアが 0.1 から 0.25 の間であれば改善が必要です。CLS スコアが 0.25 を超えると不良と見なされます。Cumulative Layout Shift の Core Web Vitals に合格するには、訪問者の少なくとも 75% が「良好」な CLS スコアである必要があります。

ウェブパフォーマンスと user experience における CLS の重要性

Cumulative Layout Shift (CLS) は、読み込み中にウェブページがどの程度安定し予測可能に感じられるかに直接影響するため、ウェブパフォーマンスと user experience の両方に関連しています。重要な理由は以下のとおりです：

• UX、エンゲージメント、ブランド認知： 予期しないレイアウトシフトはユーザーの操作フローを乱し、情報の発見、ボタンのクリック、意図したとおりのページ操作を困難にします。このフラストレーションは、ユーザーがウェブサイトを完全に離脱してしまう悪い体験につながる可能性があります。ウェブサイトの user experience はその背後にあるブランドに反映されます。頻繁なレイアウトシフトは、設計や保守が不十分なウェブサイトという印象を与え、ユーザーエンゲージメントを損ない、インタラクションの減少や直帰率の上昇につながる可能性があります。
• アクセシビリティ： レイアウトシフトは、支援技術やスクリーンリーダーに依存する障害を持つユーザーにとって特に大きな問題となります。安定したレイアウトにより、すべてのユーザーがウェブサイトを効果的にナビゲートし操作できるようになります。
• SEO と検索ランキング： Core Web Vitals は Google における小さいながらも重要なランキング要因です。Google をはじめとする検索エンジンは、優れた user experience を提供するウェブサイトを優先します。CLS は、Google がウェブサイトのランキングを判断する際に考慮する Core Web Vitals 指標のひとつです。CLS の最適化により、検索結果において競争上の優位性を得ることができます。

CLS はどのように測定されるのか？

ページの CLS は Layout Instability API で測定できます。以下はこの API の簡単な使用例です：

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

CLS の計算方法

CLS はシンプルかつエレガントな計算式で算出されます：

CLS = sum(impact-fraction * distance-fraction)

impact fraction は、ページの表示コンテンツのどの程度の範囲がシフトしたかを測定します。distance fraction は、コンテンツがどの程度の距離移動したかを測定します。例えば、ページの 50%（範囲）がビューポートの 25%（距離）シフトした場合、CLS スコア = 0.50 × 0.25 = 0.125 となります。

予期されるレイアウトシフトと予期しないレイアウトシフト

すべてのレイアウトシフトが悪いわけではなく、予期していないものだけが問題です。例えば「もっと読み込む」リンクをクリックした場合、より多くのアイテムがページに表示され、コンテンツがシフトすることは予期されるでしょう。

そのため、予期しないレイアウトシフトのみが CLS に寄与します。例えば、ユーザーがボタンをクリックして、それに応じて新しいコンテンツがページに追加される場合（メニューのドロップダウンなど）、そのレイアウトシフトは CLS から除外されます。正確に言えば、ユーザー入力から 500ミリ秒以内に発生したレイアウトシフトは計算から除外されます。

レイアウトシフトセッション

CLS が最初に導入された際、一部のサイトは不当に悪い CLS スコアを付けられていました。例えば、無限スクロールを実装しているページでは、スクロールするたびに新しく追加されたコンテンツの影響が CLS の合計スコアに加算されていました。そのため、CLS は現在セッション単位で計算されます。各セッションの最大持続時間は5秒で、レイアウトシフト間のギャップは1秒です。最も大きな CLS スコアを持つセッションが最終的な CLS スコアとなります。

例えば、最初のセッションで CLS スコアが 0.095、次のセッションで CLS が 0.15、最後のセッションで CLS スコアが 0 の場合、最終的な CLS スコアは3つの中で最も高い 0.15 となります。

CLS と Core Web Vitals

Cumulative Layout Shift (CLS) は、視覚的安定性を測定する重要なユーザー中心の指標です。Cumulative Layout Shift (CLS) は、Largest Contentful Paint (LCP) および Interaction to Next Paint (INP) とともに Core Web Vitals を構成しています。これら3つの指標で、読み込みパフォーマンス、インタラクティブ性、視覚的安定性を測定します。

CLS の問題を測定する方法

1. Lighthouse を使用して Cumulative Layout Shift を発見する

レイアウトシフトを発見する最も簡単な方法は、Chrome ブラウザで Lighthouse を使用することです。ページ上の任意の場所を右クリックするだけで Lighthouse 監査を実行できます。「要素を検証」を選択し、開いたコンソールの Lighthouse タブを選択して監査を実行します。

監査結果に Cumulative Layout Shift (CLS) スコアが表示されます。「診断」までスクロールし、Cumulative Layout Shift の情報を展開すると、レイアウトシフトの原因となっているノードを確認できます。

正直なところ、私自身はこの方法をあまり使いません。レイアウトシフトの正確な距離に関する詳細が不足しているため、結果の解釈が難しくなります。

2. CLS Visualizer を使用して Cumulative Layout Shift を発見する

CLS Visualizer は私が作成した Chrome 拡張機能です。ボタンをワンクリックするだけで、ページ上のすべてのレイアウトシフトが視覚化されます。ページのレイアウトシフトを特定しようとする際に、私が最初に使うソリューションです。簡単で、Cumulative Layout Shift の優れた視覚的概要を提供してくれます。

3. Chrome のパフォーマンスタブを使用して CLS を発見する

レイアウトシフトをデバッグする最良の方法は、Chrome のパフォーマンスタブを使用することです。パフォーマンスタブを開くには、Chrome で任意のページに移動し、以下のショートカットキーの組み合わせを使用します：

• Ctrl+Shift+I を押す（開発者ツールを開く）
• Ctrl+Shift+E を押す（プロファイリングを開始してページをリロード）

次に、上部のタイムライン上にマウスを合わせてフレームごとにタイムラインを検査し、レイアウトシフトを探します（レイアウトシフトはパフォーマンスタブの Experience セクションでも赤色で表示されます）。

4. CoreDash のような RUM ツールを使用する

RUM とは Real User Monitoring の略で、RUM データは Core Web Vitals に関するリアルタイムの貴重なインサイトを提供できます。CoreDash のような RUM ツールは、Cumulative Layout Shift をブラウザ、要素、ナビゲーションタイプ、特定の URL やページタイプなどのセグメントに分解できます。これにより、パフォーマンスの低いページや問題のある要素を特定して修正するのに役立ちます。

Cumulative Layout Shift の一般的な原因とその改善方法

すべてのレイアウトシフトの根本原因は基本的に同じです。ある時点で、別の要素の上に配置された要素が以前より大きいまたは小さいスペースを占めるようになります。これは通常、以下の原因の1つ以上によるものです：

• 明示的なサイズ指定のない画像、iframe、動画
• ビューポートに遅れて読み込まれる広告
• 動的に挿入されるコンテンツ
• レイアウトをトリガーするプロパティを使用した CSS アニメーション
• 遅いユーザーインタラクション
• 不一致な fallback を持つウェブフォント

画像、動画、iframe による CLS

画像、動画、iframe は Cumulative Layout Shift の主な原因であり、CLS 問題の大部分を占めています。この特定の原因に関する詳細なガイドは、自動サイズ調整画像によるレイアウトシフトの修正方法をご覧ください。

画像、動画、iframe によるレイアウトシフトは、常にサイズ指定の欠如が原因です。最も一般的なのは、要素の高さと幅が HTML で定義されていないケースです。一般的なベストプラクティスは、HTML で画像の固有の幅を設定し、スタイリングを使って親コンテナに合わせて自動スケーリングすることです。

明示的な width と height 属性を設定する

画像と iframe からの CLS を防ぐ最もシンプルで効果的な方法は、HTML に直接 width と height 属性を含めることです。最新のブラウザはこれらの属性を使用してリソースが読み込まれる前にアスペクト比を計算し、正しいスペースを確保します。

<!-- Images: always include width and height -->
<img src="hero.jpg"  alt="Hero image">

<!-- Iframes: same principle -->
<iframe src="https://example.com/embed"
    
    title="Embedded content">
</iframe>

<!-- Videos: always include dimensions -->
<video  controls>
    <source src="video.mp4" type="video/mp4">
</video>

<style>
img, iframe, video {
    max-width: 100%;
    height: auto;
}
</style>

CSS の aspect-ratio プロパティを使用する

レスポンシブレイアウトや正確なピクセルサイズが利用できない場合、aspect-ratio CSS プロパティはスペースを確保する代替手段を提供します。これは、動的コンテンツや埋め込みメディアを含むコンテナに特に有用です。

<style>
/* Reserve space for a 16:9 video container */
.video-wrapper {
    
    width: 100%;
    background: #f0f0f0;
}

/* Reserve space for a square image */
.avatar {
    
    width: 80px;
    object-fit: cover;
}

/* Responsive iframe container */
.embed-container {
    
    width: 100%;
}
.embed-container iframe {
    width: 100%;
    height: 100%;
}
</style>

ウェブフォントによる CLS

Cumulative Layout Shift はウェブフォントによって引き起こされることがあります。ウェブフォントとは、ローカルのパソコンやスマートフォンにインストールされていない、インターネットからダウンロードされるフォントです。ウェブフォントがまだダウンロードされていない間、ページは通常 fallback フォントでレンダリングされます。この fallback フォントのサイズは最終的なフォントと異なる場合があります。この例では、fallback フォントが最終的なウェブフォントよりわずかに小さくなっています。詳細については、ウェブフォント読み込み中にテキストを表示し続ける方法をご覧ください。

ウェブフォントによるレイアウトシフトを修正する方法はいくつかあります。2つのテクニックに基づいています：

1. fallback フォントをウェブフォントにより近づける。最も効果的な方法は、@font-face ディスクリプターをオーバーライドすることです。

2. ウェブフォントの読み込みを高速化する。ブラウザがレンダリングを開始する前にフォントを利用可能にします。一般的な方法は、ウェブフォントをセルフホスティングし、重要なウェブフォントをプリロードすることです。

メトリックオーバーライドによるフォント fallback マッチング

ウェブフォントによる CLS を解消する最も効果的なテクニックは、ウェブフォントのサイズに近い fallback フォント定義を作成することです。size-adjust、ascent-override、descent-override、line-gap-override ディスクリプターを使用することで、fallback フォントがほぼ同一のスペースを占めるようにできます。font-display: swap と組み合わせることで、ウェブフォントが読み込まれた際のレイアウトシフトを最小限に抑えながら、テキストを即座に表示できます。

<style>
/* Define a matched fallback font */
@font-face {
    font-family: 'My Font Fallback';
    src: local('Arial');
    
    
    
    
}

/* Use the web font with the matched fallback */
@font-face {
    font-family: 'My Font';
    src: url('/fonts/myfont.woff2') format('woff2');
    
}

body {
    font-family: 'My Font', 'My Font Fallback', sans-serif;
}
</style>

<!-- Preload the critical web font for faster loading -->
<link rel="preload" href="/fonts/myfont.woff2"
    as="font" type="font/woff2" crossorigin>

Fallback Font Generator のようなツールを使えば、特定のフォントペアリングに対する正しいオーバーライド値を自動的に計算できます。Google Fonts については、フォントをセルフホスティングすることで、font-face 宣言とプリロード戦略を完全にコントロールできます。

CSS アニメーションによる CLS

CSS アニメーションとトランジションは、周囲の要素のレイアウトに影響するプロパティをアニメーションさせると、予期しないレイアウトシフトを引き起こす可能性があります。top、left、width、height、margin、padding などのプロパティは、ブラウザにページ全体のレイアウトの再計算を引き起こし、CLS の原因となります。詳細なウォークスルーについては、CSS トランジションによるレイアウトシフトの修正方法をご覧ください。

解決策は、アニメーションに transform や opacity のようなコンポジットされた CSS プロパティを使用することです。これらのプロパティは GPU コンポジターで処理され、レイアウトの再計算をトリガーしないため、CLS はゼロになります。

<style>
/* BAD: Animating top/left causes layout shifts */
.slide-in-bad {
    position: relative;
    animation: slide-bad 0.3s ease-out;
}
@keyframes slide-bad {
    from {  }
    to   {  }
}

/* GOOD: Animating transform does NOT cause layout shifts */
.slide-in-good {
    animation: slide-good 0.3s ease-out;
}
@keyframes slide-good {
    from {  }
    to   {  }
}
</style>

HTTP Archive Web Almanac によると、モバイルページの 39%、デスクトップページの 42% が CLS に寄与する非コンポジットアニメーションを使用しています。アニメーションが transform と opacity のみを使用し、レイアウトをトリガーするプロパティを使用していないことを常に確認してください。

CSS containment を使用してレイアウトシフトを分離する

CSS の contain プロパティは、要素のコンテンツがページの残りの部分から独立していることをブラウザに伝えます。これにより、レイアウトの再計算の範囲が制限され、レイアウトシフトが周囲の要素に伝播するのを防ぐことができます。

<style>
/* Isolate ad containers from the rest of the page */
.ad-slot {
    
    min-height: 250px;
}

/* For off-screen content, use content-visibility */
.below-fold-section {
    
    
}
</style>

contain: layout 宣言により、要素内のサイズ変更が外部の要素のレイアウト再計算をトリガーしないことが保証されます。content-visibility: auto プロパティはさらに進んで、画面外のコンテンツのレンダリングを完全にスキップできるようにし、contain-intrinsic-size がコンテンツがスクロールして表示される際のレイアウトシフトを防ぐための推定サイズを提供します。

遅いユーザーインタラクションによる CLS の問題

以下の例では、「もっと読み込む」ボタンが明らかにレイアウトシフトを引き起こしています。しかし、このレイアウトシフトは CLS 指標には加算されません。これは、このレイアウトシフトが意図的なものだからです。

ブラウザは、現在表示されている要素に「hadRecentInput」という属性があることでこれを認識します。これが true に設定されており、かつレイアウトシフトが入力イベント（ボタンクリック）から 500ミリ秒以内に発生した場合、そのレイアウトシフトはブラウザによって報告されません。

ユーザーインタラクションが 500ミリ秒以内に完了するようにしてください。インタラクションにそれ以上の時間がかかると、結果として生じるレイアウトシフトは CLS スコアにカウントされます。これは、新しいコンテンツを挿入する AJAX リクエストに特に関連します。インタラクティブな要素の最適化に関するヒントは、完璧な Core Web Vitals を持つチャットウィジェットの構築方法をご覧ください。

AJAX と動的に挿入されるコンテンツによる CLS の問題

AJAX を使用すると、バックグラウンドでウェブサーバーとデータを交換することにより、ウェブページを非同期に更新できます。ウェブページに新しいコンテンツを挿入すると、大きなレイアウトシフトが発生する可能性があります。そのため、新しいコンテンツ用のスペースを事前に確保しておくことが賢明です。新しいコンテンツの高さを事前に正確には把握できませんが、経験に基づいた推測をすることはできます。

例えば、平均的な AJAX コンテンツが画面の 50% を占める場合、その 50% を確保しておくのが賢明です。新しいコンテンツが最終的に画面の 40% や 60% を占めた場合でも、CLS（50% - 40% = 10% の distance fraction）は 50% の distance fraction よりもはるかに小さくなります。

以下はその実装例です：

<style>
   #ajax { height: 400px; }
   #ajax.loaded { height: auto; }
</style>
<script>
   fetch('/ajax-content')
   .then(response => response.json())
   .then(result => {
      let el = document.getElementById('ajax');
      el.innerHTML = result.html;
      el.classList.add('loaded');
   })
</script>

読み込み後の CLS：動的コンテンツと遅延読み込み要素

レイアウトシフトは初回ページ読み込み時だけに発生するわけではありません。読み込み後の CLS は、ページがすでにレンダリングされた後に表示されたり、サイズが変更されたりするコンテンツによって引き起こされます。一般的な原因には以下があります：

• 遅延読み込みされる広告： 広告ネットワークは、ページが読み込まれてから数秒後にコンテンツを挿入することがよくあります。広告スロットにスペースが確保されていない場合、広告が周囲のすべてのコンテンツを押し下げます。
• Cookie 同意バナー： ページコンテンツをオーバーレイするのではなく押し下げるバナーは、大きな CLS を引き起こします。オーバーレイパターン（position: fixed）を使用するか、ページの上部にスペースを確保してください。
• ファーストビュー上部の遅延読み込みコンテンツ： Intersection Observer を介して読み込まれる、最初は非表示だったコンテンツが、スペースの確保なしにビューポートに表示される場合。
• A/B テストスクリプト： 初回レンダリング後に DOM を変更するテストツールは、予期しないシフトを引き起こす可能性があります。A/B テストの変更はサーバーサイドで、または初期 HTML 内で可能な限り実行してください。
• 無限スクロールの実装： リストの末尾に追加される新しいコンテンツは、既存の要素のレイアウトを変更する場合、シフトを引き起こす可能性があります。新しいコンテンツは、現在のスクロール位置より下にのみ追加されるようにしてください。

セッションウィンドウモデル（上記で説明）により、読み込み後のシフトも最悪のセッション内に該当する場合は CLS にカウントされます。CoreDash の CLS アトリビューションデータを監視して、読み込み後にどの要素がシフトしているかを特定してください。

広告による CLS の問題を修正する

広告はページ上でかなり遅れて読み込まれることがよくあります。そのため、広告による Cumulative Layout Shift は特に煩わしいものです。複数の広告が表示領域内で読み込まれると、ページがまったく静止しません。これを修正するには、広告用のスペースを確保してください。特に表示領域内の広告について確保が重要です。

<style>
/* Reserve space for rectangle mobile ad */
.ad {
    min-height: 250px;
    background: #dedede;
    
}
/* Reserve space for banner desktop ad */
@media only screen and (min-width: 600px) {
    .ad { min-height: 90px; }
}
</style>

ケーススタディ：楽天24 と CLS のビジネスへの影響

楽天24は、日本の大手 EC プラットフォームであり、Cumulative Layout Shift がビジネス指標に与える影響について詳細な調査を実施しました。商品ページとカテゴリページ全体で CLS を削減することで、楽天24は顕著な成果を達成しました：

• 訪問者あたりの収益が 53.37% 増加：CLS が低いユーザーと CLS が高いユーザーの比較。
• コンバージョン率が 33.13% 増加：同じ CLS 改善コホートにおいて。
• 直帰率が 15.20% 減少：安定したページ体験を持つ訪問者において。

これらの数字は、CLS が単なる技術的指標ではないことを示しています。視覚的な不安定さは、ブラウジングや購入過程でユーザーをフラストレーションさせることで、ビジネスの収益に直接的な損失をもたらします。要素が予期せず移動すると、ユーザーは信頼を失い、誤クリックし、セッションを放棄します。楽天24の調査は、CLS の最適化への投資が測定可能な投資収益率をもたらすことを裏付けています。特に、すべてのインタラクションが重要な EC サイトにおいて顕著です。

実世界の CLS データが示すもの

CoreDash のデータによると、CLS は最もパフォーマンスが優れた Core Web Vitals であり、corewebvitals.io のページ読み込みの 92.8% が「良好」スコアを達成し、モバイルとデスクトップ間でデバイスギャップはほとんどありません。デスクトップ（92.8% が良好）とモバイル（92.7% が良好）の両方がほぼ完璧な CLS スコアを達成しており、両デバイスタイプで p75 は 0 です。

これは、モバイルのパフォーマンスがデスクトップよりも大幅に劣る LCP や INP のような指標とは対照的です。CLS は、他のすべての Core Web Vitals とは逆に、より広いウェブ全体でモバイルの方がデスクトップよりも優れているという独自の特徴があります。

HTTP Archive Web Almanac 2024 によると、グローバルな状況はやや楽観的ではありません：

• ウェブサイトの 72% が全体的に良好な CLS スコアを達成しており、11% が不良な CLS です。
• モバイルページの 66% にサイズ未指定の画像が少なくとも1つあります（2022年の 72% から減少していますが、依然として CLS の主要な原因です）。
• モバイルページの 39% に CLS に寄与する非コンポジットアニメーションがあります。
• ページのわずか 11% のみがウェブフォントをプリロードしており、大多数のサイトがフォントスワップによるレイアウトシフトの影響を受けやすい状態です。

CLS はグローバルで年々着実に改善を示していますが、データからはサイズ未指定の画像と非コンポジットアニメーションが依然として最も一般的な2つの原因であることが明らかになっています。この2つの問題に対処するだけで、ウェブの大部分のレイアウトシフトを解消できるでしょう。

CLS に関するよくある質問

関連ガイドと詳細解説

CLS 最適化の具体的なテクニックについては、以下の詳細ガイドをご覧ください：

• CSS トランジションによるレイアウトシフトの修正：レイアウトをトリガーする CSS アニメーションを特定し、コンポジットされた代替手段に置き換える方法を学びます。
• 自動サイズ調整画像によるレイアウトシフトの修正：画像とレスポンシブコンテナに適切なサイズ指定を追加するための完全なウォークスルーです。
• Google Fonts のセルフホスティング：適切な font-display とプリロード戦略でフォントをセルフホスティングすることで、フォント読み込み時の CLS を削減します。
• ウェブフォント読み込み中にテキストを表示し続ける：font-display とフォントメトリックオーバーライドを設定して、フォントスワップによるレイアウトシフトを解消します。
• 完璧な Core Web Vitals を持つチャットウィジェットの構築：CLS、INP、LCP の悪化を引き起こさずにサードパーティウィジェットを実装するケーススタディです。

すべての Core Web Vitals 指標と最適化戦略の完全な概要については、Core Web Vitals 概要をご覧いただくか、Core Web Vitals 究極チェックリストを使用してサイトを監査してください。