CLSとは？合計ではなく最悪の5秒間、直す前に見る3か所

CLSとは、表示中に要素がずれた量を測る指標

CLSは Cumulative Layout Shift の略です。読み込みの途中で画像や広告が入り、読んでいた文章が下に押し出される、あの現象を数値にしたものです。

Core Web Vitalsの3指標のひとつで、他の2つと違って単位を持ちません。秒でもミリ秒でもない、割合の掛け算で出る数値です。

移動した面積と距離の掛け算で決まる

画面のうち何割の面積が動いたかと、それがどれだけ移動したかを掛け合わせます。

画面の半分を占める要素が、画面の高さの14%ぶん下がったなら、0.5×0.14で0.07です。このため、小さな要素が少し動いても数値はほとんど動きません。逆に、大きな要素が大きく動くと一気に跳ね上がります。

0.1以下が良好、0.25超は改善が必要

基準は0.1以下が良好、0.25を超えると改善が必要です。その間は「改善の余地あり」です。この3段階は、他のCore Web Vitalsの指標と同じ区分の仕方です。

この判定は、直近28日間に実際にページを開いた利用者のうち、75%がその値に収まっているかで決まります。自分の環境で0だったとしても、利用者の側で悪い値が出ていることがあります。

• 参考：Cumulative Layout Shift (CLS)
• 関連記事：Core Web Vitalsとは？3指標の意味と、直さなくていい場合の見分け方

CLSは「累積」だが、合計ではない

名前に「累積」と入っているため、ページ内のずれをすべて足した値だと説明されることがあります。ただ、これは2021年6月より前の定義です。

セッションウィンドウという区切り方

現在は、ずれをまとまりごとに区切って数えます。このまとまりをセッションウィンドウと呼びます。

ずれとずれの間隔が1秒未満なら同じまとまり、1秒以上あくと別のまとまりです。ひとつのまとまりは最長5秒までで、それを超えると打ち切られます。

最も大きいまとまりだけが採用される

ページ内に3つのまとまりができたとして、CLSの値になるのは合計ではありません。3つのうち、中の合計が最も大きいまとまり1つだけです。

つまり直すべきは、最も揺れている数秒間です。ページ全体をまんべんなく点検する必要はありません。

長く開いても不利にならない

この変更は、長時間開かれるページのために入りました。合計方式だと、無限スクロールのページやアプリのような画面は、開いているだけで数値が積み上がってしまいます。

まとまりで区切ることで、滞在時間の長さに左右されなくなりました。記事を最後まで読まれても、それ自体で不利になることはありません。

逆に言えば、まとまりが1つでも大きければ、そこだけで数値が決まります。ページの大半が安定していても、読み込み直後の2秒間で大きく動けば、その値が採用されます。平均ではなく、最悪の数秒間を見られていると考えてください。

• 参考：Optimize Cumulative Layout Shift

CLSは読み込みが終わってからも測られる

もうひとつ誤解されやすいのが、測る範囲です。結論から言うと、CLSは読み込み中だけの指標ではありません。ページを閉じるまでずっと測られます。

スクロール中のずれも入る

下までスクロールしたところで、遅れて読み込まれた要素が入り、読んでいた位置が動く。これもCLSに計上されます。

遅延読み込みを設定した画像に寸法がないと、この形のずれが起きます。検証時は上部だけを見がちなので、画面の下のほうほど見落としやすい箇所です。

利用者の操作から500ms以内は除外される

ボタンを押してメニューが開く、といった動きは対象外です。利用者の操作から500ミリ秒以内に起きたずれは、予期されたものとして除かれます。

アコーディオンの開閉やタブの切り替えを疑う必要はありません。問題になるのは、利用者が何もしていないのに動く場合です。

逆に言えば、利用者が押した結果として下の内容が動くのは正常な挙動です。この区別があるおかげで、質問をタップして回答が開く構成にしてもCLSは悪化しません。当サイトのよくあるご質問も、この形で作っています。

実測値と参考値が食い違う理由

PageSpeed Insightsで、実測値が悪いのに参考値が0という状態がよく起きます。

参考値は読み込みの数秒間しか見ていません。一方の実測値は、利用者がスクロールしたり操作したりした時間を含みます。この差が、両者の食い違いの正体です。判断に使うのは実測値です。

確認する場所は2つあります。PageSpeed Insightsの上部にある「実際のユーザーの環境で評価する」の欄と、Search Consoleの「ウェブに関する主な指標」です。後者はサイト全体の傾向を見るのに向いています。

どちらにも数値が出ていない場合、集計に必要な件数が集まっていません。アクセスの少ないサイトではよくあることです。その段階では参考値を目安に、明らかにずれている箇所を直しておきます。

CLSの原因を絞り込む3か所

Googleが挙げている主な原因は、大きく3つに分かれます。上から順に見ていけば、多くはこの中で見つかります。

寸法のない画像と埋め込み

最も多い原因です。画像に幅と高さが書かれていないと、ブラウザは読み込むまで場所を空けられません。読み込んだ瞬間に、その分だけ下の要素が押し下げられます。

広告枠、地図、動画、SNSの埋め込みも同じです。後から入るものには、先に場所を確保しておきます。

画像なら、幅と高さを属性として書きます。実際に表示する大きさと違っていても構いません。ブラウザは比率だけを使って場所を確保するためです。横1200・縦630の画像なら、その数値をそのまま書きます。

広告枠や埋め込みのように大きさが決まらないものは、外側の箱に最小の高さを指定しておきます。読み込まれるまでその高さが保たれるため、下の要素は動きません。

画像なら、幅と高さを属性として書きます。実際に表示する大きさと違っていても構いません。ブラウザは比率だけを使って場所を確保するためです。横1200・縦630の画像なら、その数値をそのまま書きます。

広告枠や埋め込みのように大きさが決まらないものは、外側の箱に最小の高さを指定しておきます。読み込まれるまでその高さが保たれるため、下の要素は動きません。

後から差し込まれる要素

JavaScriptで後から追加される要素も、同じ理屈でずれを起こします。お知らせのバー、同意を求める帯、キャンペーンの告知などです。

既存の内容の上に差し込むと、その下すべてが動きます。画面の上に重ねて表示すれば、下の要素は動きません。

お知らせの帯を出す場合、内容の一番上に差し込むと、その下すべてが動きます。画面の端に固定して重ねる形にすれば、押し下げは起きません。デザインの都合で差し込む必要があるなら、その高さぶんを最初から空けておきます。

Webフォントの切り替わり

Webフォントの読み込みが終わった瞬間に、代替フォントから切り替わって文字の幅が変わります。行の折り返し位置が変われば、その下も動きます。

代替フォントの字幅を本来のフォントに近づけておくと、切り替わりの影響が小さくなります。当サイトは見出しに明朝、本文にゴシックを指定し、いずれも端末に入っている書体を先に当てています。

もう1つの方法は、Webフォントを使わないことです。端末に入っている書体を指定すれば、切り替わり自体が起きません。当サイトの本文もこの方式で、見出しにだけWebフォントを使っています。

どこがずれているかを見つける

原因の候補が分かっても、実際にどの要素がずれているかは別です。開発者ツールで特定できます。

F12で開発者ツールを開き、パフォーマンスのタブを選びます。記録を開始してからページを読み込み、数秒後に停止します。記録の中に「レイアウトシフト」という項目が並ぶので、選ぶと、動いた要素が画面上で示されます。

ここで分かるのは、原因ではなく結果です。動いた要素の1つ上に何があるかを見ます。押し下げているのは、たいていその要素です。

• 関連記事：レスポンシブ対応とは？3つの構成の違いと、テスト廃止後の確認方法

WordPressでCLSに効く対処

WordPressの場合、直すべき箇所とそうでない箇所がはっきり分かれます。結論を先に書くと、本文の画像に手を入れる必要はほとんどありません。

本文の画像は自動で寸法が入る

メディアライブラリから挿入した画像には、WordPressが幅と高さを自動で書き込みます。バージョン5.5以降の標準の動作です。

本文の画像でずれが起きているなら、寸法が消される設定になっている可能性があります。画像を最適化するプラグインが取り除いていることがあります。

確認は簡単です。記事のページを開き、右クリックからページのソースを表示します。画像のタグを探し、widthとheightが書かれているかを見ます。書かれていなければ、原因はそこです。

テーマ側の画像は自分で入れる

テーマのファイルに直接書いた画像は、自動では入りません。ヘッダーのロゴ、トップページの装飾画像、アイコン類が該当します。

当サイトも、テーマ内の画像にはすべて手作業で幅と高さを書いています。プラグインを使っていないため、この作業を代わりにやってくれる仕組みがないためです。

プラグインが増えるほど原因が増える

後から要素を差し込むプラグインは、それだけでずれの原因になります。同意バー、ポップアップ、関連記事の自動挿入などです。

入れる前に、その要素が既存の内容を押し下げないかを確認します。画面に重ねる方式なら、押し下げは起きません。

確認の方法は、そのプラグインを有効にする前と後で、同じページを開発者ツールで測ることです。有効にした途端に数値が跳ね上がるなら、そのプラグインが原因です。判断がついてから本番に入れます。

直したあとに確認すること

直したつもりでも、実測値に反映されるまでには時間がかかります。実際の利用者から集めたデータは28日間の集計なので、修正の効果が数値に出るまで最短でも数週間です。

その間の確認は、参考値と開発者ツールで行います。修正前に記録したレイアウトシフトの項目が、修正後に消えていれば手当ては効いています。数値の反映を待つ必要はなく、記録から消えていれば次に進んで構いません。

• 関連記事：WordPressで作るメリット｜プラグインを入れないという選択肢

まとめ

CLSは合計値ではありません。最も揺れている数秒間だけを見ています。だから直す範囲は、ページ全体ではなく数か所に絞れます。

そして読み込み後も測られるため、開発環境で0でも安心はできません。判断に使うのは実測値です。

まずPageSpeed Insightsで実測値のCLSを開き、0.1を超えていたら、寸法のない画像から順に見るところから始まります。0.1以下なら、その日は記事を書く時間に回してください。