今日は実務で調査依頼のあった「CLS」について解説したいと思います。
CLS（累積レイアウト変更）とは
サイトの表示速度を計測するGoogleの指標「PageSpeed Insights」に新たに追加された【WebページUX指標「コアウェブバイタル」】のひとつ。
一言でいうと、「表示のズレ」
ページをロードしたときに、コンテンツがカタカタ・・・と動いてコンテンツがズレる状態のページ。
ページの表示開始から終了までの間に、どれくらい「カタカタしたか」の比率を数値化したもの。
最善が0。
Google的には、0.1未満にすることが推奨されています。
CLS（累積レイアウト変更）が発生しうる状況
- 画像がロードされる間、高さが0の状態になっている（＝img要素にheight属性を指定していない）とき
- Javascriptなどでコンテンツに変化があった場合
CLS（累積レイアウト変更）の改善方法
Javascriptなどでコンテンツに変化があった場合
実在のサイトで実証したところ、Javascriptプラグインのスライダーだったり、Ajaxなどの非同期処理でコンテンツを生成したりした場合、何も対処をしていないと、CLSが悪化することが判明しています。
対処方法としては、表示前の状態から予めCSSで高さやレイアウトを維持させる、ことが最も簡単です。
※注意点
カタカタする要素の親の高さをheight（min-height、max-height）で指定して変化させなかったとしても、子孫要素がカタカタしていたらそれもCLSを悪化させることが実証結果から判明しています。
JSや非同期処理があってもなくても、静的な状態ですべての要素の高さが維持され、カタつかないようにすることが重要です。
またスライダープラグイン「Slick」などは、JSロード後にスライダーを動かすために要素を複雑に生成するので、JSのロード前と後の両方でレイアウトが変化しないようにCSSを記述する必要があります。
img要素にheight属性が指定されていない
指定しましょう。
ただ、特にRWD（レスポンシブウェブデザインの場合は、height属性を指定するのも一つの方法ですが、height属性はpxか%でしか指定できず柔軟性に欠けるので、個人的には、内包する親要素の高さを確保したほうがいよいかもしれないと思っています。
あとRWD（レスポンシブウェブデザイン）の場合、どのサイズのときの値を記述すればいいか迷いそうだし。
いろいろ考えた結果、バナーのように画像単体を配置する場合は、以下のようなコードで対応することにしました。
.banner_parent {
&::before {
content: " ";
display: inline-block;
float: left;
padding-top: (180 / 750 * 100%);
}
&::after {
clear: both;
}
}
↑Sassです。
疑似要素「::before」で画像縦横比に合わせた高さを確保。
imgを回り込みで正しく配置。
疑似要素「::after」で回り込み解除。
検証時のテクニック
GooglChrome拡張機能を活用
「PageSpeed Insights」は本番環境（認証のない状態）でしか確認できないので、ローカル開発環境や認証下の開発環境などを使われている場合は、GooglChromeの「Web Vitals」というプラグイン（拡張機能）が便利です。
https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma
ただし、このプラグインは現在の表示位置以前のコンテンツに対する計測を行うもののようなので、ページ全体の確認のためには、ページを最下部までスクロールする必要があるみたいです。
表示速度を意図的に落として発生を確認しやすくする
PC版GoogleChromeの場合、ディベロッパーを使って意図的に通信速度を落とせば体感しやすくなります。
「PageSpeed Insights」の見方
「フィールドデータ」と「ラボデータ」というものがありますが、「フィールドデータ」は過去データの集計値なので、リアルタイムの結果ではありません。
なので、改善施策を行ってすぐに再計測しても、ここの数値は変化しません。
リアルタイムのデータは「ラボデータ」のほうです。
改善後の再計測時は「ラボデータ」を確認しましょう。
・・・わたし、ずーっと「フィールドデータ」のほうをみていて、何やっても変化しなくて数日間も悩んでしまいました・・・ご注意を。
＝うしお＝
