【テクニカル・上級編】 Layout Instability API (CLS) – Webブラウザの仕組み実践ガイド

Layout Instability APIと向き合う：ブラウザの「再計算」を制御し、ユーザー体験をハックせよ

Webフロントエンドの世界に足を踏み入れたばかりの頃、我々は「綺麗なUIを作ること」に情熱を燃やす。しかし、そのコードがブラウザのレンダリングパイプラインをどう叩き、メモリをどう消費し、最終的に「レイアウトシフト」という名の悪魔となってユーザーのクリックを空振らせるか……。そこに気づいたとき、君はエンジニアとして次のステージに立っている。

今日は、Core Web Vitalsの厄介者であり、同時にブラウザエンジンの挙動を最も端的に示す指標の一つ、「CLS（Cumulative Layout Shift）」を司る Layout Instability API について、アーキテクチャの深淵から語ろうと思う。

—

ブラウザが「揺れる」とき、何が起きているのか

まず、ブラウザのレンダリングパイプラインを思い出してほしい。DOMとCSSOMが構築され、Render Treeが生成される。そこからLayout（Reflow）、Paint、Compositeへと続く旅だ。

CLSが発生する原因は、ブラウザが「要素のサイズや位置が確定したはずの場所に、後から別のコンテンツが割り込んでくる」ことを許容してしまうからだ。非同期で降ってきた広告、遅れて表示されるWebフォント、高さが未指定の画像。これらがブラウザの再計算（Recalculation）を強制し、既存のレイアウトを押し出す。

ブラウザの内部エンジンからすれば、これは非常にコストの高い演算だ。DOMツリーの一部が変更されると、その子孫ノードの幾何学的計算をやり直す必要がある。Layout Instability APIは、この「無駄な再計算」を検出し、スコアとして可視化するための窓口に過ぎない。

Layout Instability APIの核心：`PerformanceObserver`の実装

このAPIを扱うとき、単に「スコアをログに出す」だけでは素人だ。上級エンジニアであれば、このAPIを通して「どの要素が、どのタイミングで、どれだけのコストを支払ったか」をトレースし、開発プロセスのフィードバックループに組み込むべきだ。

以下は、実務レベルでレイアウトシフトの原因を特定するための、堅牢な監視スクリプトのひな形だ。

Layout Instability API を活用したシフト監視の実装
どの要素がシフトを引き起こしたかを特定し、コンソールに詳細を出力する

/
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// ユーザーによる操作（クリック等）から500ms以内なら無視する（Input Exclusion）
if (entry.hadRecentInput) continue;

console.group(‘Layout Shift Detected’);
console.log(`スコア: ${entry.value}`);
// entry.sources は「どの要素が動かされたか」を示す配列
entry.sources.forEach((source) => {
console.log(‘影響を受けたノード:’, source.node);
console.log(‘移動前:’, source.previousRect);
console.log(‘移動後:’, source.currentRect);
});
console.groupEnd();
}
});

// type: ‘layout-shift’ を監視対象に設定
// buffered: true にすることで、ページ読み込み直後のシフトも確実に拾う
observer.observe({ type: ‘layout-shift’, buffered: true });

現場で陥る「見えないバグ」の回避策

実務において、CLSをゼロにするのは至難の業だ。特にSPA環境では、仮想DOMがレンダリングを制御しているとはいえ、ブラウザのネイティブなレイアウトエンジンと同期が取れていない瞬間がある。

私が現場で推奨している、CLSを物理的に封じ込めるための鉄則を共有しよう。

1. アスペクト比の事前固定（`aspect-ratio`）:
現代のブラウザは非常に賢い。画像の読み込みを待たずに`width`と`height`から領域を確保できる。`aspect-ratio`プロパティをCSSに記述するだけで、ブラウザは画像が降ってくる前から「そこにあるべき空間」を計算できる。これにより、Paint前のレイアウト計算を確定させられる。
2. Webフォントの「FOIT/FOUT」制御:
`font-display: swap;`は強力だが、フォントの切り替わり時にテキストの幅が変わるとレイアウトが崩れる。`size-adjust`プロパティを使って、システムフォントとWebフォントの視覚的なサイズを可能な限り合わせるのがプロのやり方だ。
3. 非同期コンテンツの「入れ物」を確保する:
広告や動的なウィジェットを読み込む際は、親コンテナに必ず`min-height`を設定せよ。もし高さが不明なら、スケルトンスクリーンを静的に配置し、レイアウト計算の「変動フラグ」を立てないようにする。

最後に：アーキテクトとしての視点

Layout Instability APIを監視することは、単にGoogleのスコアを改善するためではない。それは、「ブラウザのレンダリングパイプラインを、いかに止めることなく流し続けるか」という、極めて高度なエンジニアリングの追求だ。

ブラウザのレンダリングエンジンは、君たちが書いたコードを忠実に実行するが、同時に残酷なほど正確に「無駄」を晒し出す。CLSが高いということは、ユーザーの体験を損ねているだけでなく、ブラウザのCPUリソースを無駄に消費させているというサインでもある。

コードを記述する際、常に「このDOM操作は、ブラウザのどの計算をトリガーするか？」を想像してほしい。その想像力こそが、堅牢で高速なWebアプリケーションを作る唯一の道だ。

さあ、次は君のアプリケーションのDevToolsを開き、このAPIでどんな「揺れ」が隠れているか、その目で確かめてみるといい。