Webサイトのパフォーマンス計測において、最も頭を悩ませる指標の一つがCLS（Cumulative Layout Shift）です。特に、非同期で読み込まれるコンテンツや無限スクロールの実装において、要素が後から表示された瞬間にレイアウトがガタつく現象は、ユーザー体験を著しく損ねます。今回は、この課題を根本から解決するCSSプロパティ「contain-intrinsic-height」について、実務的な視点で解説します。
なぜheight: autoでは不十分なのか
これまで、未読み込みの要素の高さ（プレースホルダー）を確保するために、私たちは「height: 0」や「min-height」を駆使してきました。しかし、コンテンツの中身が動的に変わる場合、あらかじめ高さを固定するのは現実的ではありません。ここで登場するのが「content-visibility: auto」と「contain-intrinsic-height」の組み合わせです。
contain-intrinsic-heightの役割と本質
「content-visibility: auto」を適用すると、画面外にある要素のレンダリングがスキップされます。これ自体は素晴らしい機能ですが、ブラウザは「その要素の高さが0である」と判断してしまい、スクロールバーが激しく上下する問題が発生します。
ここで「contain-intrinsic-height」の出番です。これは、レンダリングがスキップされている状態の要素に対して、「仮想的な高さ」をブラウザに伝達するプロパティです。これにより、ブラウザは要素が読み込まれる前から適切な高さを計算し、スクロールバーの位置を固定したままスムーズな表示を実現できます。
実務での具体的な活用パターン
実務における最適な指定方法は、単なる固定値ではなく「概算値」を渡すことです。例えば、カード型レイアウトのリストを実装する場合、以下のように記述します。
.card-item {
content-visibility: auto;
contain-intrinsic-height: 300px;
}
ここで重要なのは、実際の要素の平均的な高さに近い数値を設定することです。もしコンテンツの高さにばらつきがある場合、大きすぎる値や小さすぎる値を指定すると、かえってスクロールの挙動が不自然になります。私はよく、開発者ツールでコンテンツが完全にロードされた状態の平均高さを計測し、その数値をベースに設定値を決めています。
シニアデザイナーとしてのアドバイス
このプロパティを導入する際の注意点は、「万能薬ではない」ということです。すべてのコンポーネントに安易に適用すると、逆に計算コストが増大し、低スペック端末で逆効果になるケースもあります。
まずは、メインコンテンツのリストや、ページ下部にある重いセクションなど、「表示回数が多く、かつレイアウトへの影響が大きい箇所」に限定して導入することをお勧めします。技術はあくまでユーザーのためにあるものです。CLSを改善し、ユーザーが快適に読み進められる心地よいUIを、このプロパティで実現していきましょう。
コメント