BLOG MENU

CLSスコアがスライダーで低下！CLSが下がる原因と改善方法

Webページにライブラリでスライダーを実装するとCLSスコアが悪化します。ライブラリを使用したときのスコア悪化の度合いは、使用するライブラリや、ページ内に実装する箇所によってもケースバイケース。ライブラリを使用すると、多かれ少なかれCLSが悪化するのは間違いなく、Google推奨のCLSスコア（0.1以下）を達成するというのは現実的に難しいと言えます。

これは、Core Web Vitalsがここ最近出てきている考え方や指標で、きちんと対応しているスライダーのライブラリがまだ無い（おそらく）ので、当然といえば当然です。

今回、クーシーの制作実績TOPページにおいて「スライダーのCLS改善」という課題に取り組んでみました。
結論からいうと、ライブラリによるスライダーを諦めました。代わりに自作のスライダーを実装し、CLSスコアを0.348から0.064（PCスコア）まで改善できました。

スライダーのCLS改善に対してどのようにアプローチしたか、自作したスライダーの仕様について簡単にご紹介します。

CLSスコアが悪い原因は何か？

クーシーの制作実績TOPページではキ－ビジュアルでSwiperを使用していました。
ファーストビューに対して、ライブラリによるスライダー利用は、CLSにとって明らかに相性の悪い組み合わせです。CLSスコアが悪い原因は十中八九ライブラリのスライダーだろうと思いつつも、念のため、検証はスライダーを確認することからスタートしました。
検証方法はシンプルにSwiperを切るという変更をしました。

Swiperを切る

変更前後	CLSスコア
変更前	0.348
変更後	0.016

やはりSwiperが原因という事で間違いなかったです。

では、なぜSwiperを実装するとCLSスコアが悪化するのか？
スライダーがCLSスコアを悪化させる要因は下記の2点。

【CLSスコアが悪化する要因】

画像読み込みのラグでスライダーのアイテムの高さが変わる（その結果スライダーの高さも変わる）
ライブラリの発火後にレイアウトが作られてスライダーの高さが変わる

といった事が考えられます。
この要因さえ解消できればCLSを改善できる可能性があります。

ということで、ライブラリを使用してもCLSスコアを改善できるのか検証してみました。

ライブラリのままでどこまで改善できるか

Swiperを使ったままでどこまでCLSスコアを改善できるか試しました。ライブラリを使用したままCLSを改善できるのであれば、それに越した事はありません。

改善の施策は下記2点になります。

画像分の高さを外側の要素であらかじめ保持させる
ライブラリを切っても見た目はそのままの状態を作る

1. 画像分の高さを外側の要素であらかじめ保持させる

下記を修正することで、画像分の高さをあらかじめ保持させるので画像読み込み前後によるCLSスコアが改善することを期待しました。

【修正点】

画像の外側の要素に対してcssのposition: relative;を指定。
before属性に対してdisplay: block; padding-top: 38%（←画像の高さ÷画像の幅）;を指定。
画像自体にはposition: absolute; top: 0; left: 0; width: 100%; height: auto;を指定。

2. ライブラリを切っても見た目はそのままの状態を作る

ライブラリの発火後にスライダーの型が整形される場合、発火前後でスライダーのアイテムにレイアウト変更が発生する（アイテムが縦並びから横並びに変わる等）、こともあります。スライダーの見た目部分はあらかじめCSSで作り、ライブラリの発火に依存しないようにしました。

ライブラリ発火前後のレイアウトの差異を減らすことで、CLSスコアが改善することを期待しました。

改善施策作業前後のスコア

作業前後	CLSスコア
作業前	0.348
作業後	0.342

結果は残念ながら、極小の改善（あるいはPageSpeed Insightsのタイミングによる誤差）で、期待していた結果は得られませんでした。

この時点で、Swiperは基本的なCLS対応をしたとしてもスコアの改善ができない事が分かりました。おそらくライブラリの発火後に何かしらのレイアウト変更が発生していて、しかもそれが不可避であるためこのスコアになる…ということが推測されます。

ライブラリを諦めてスライダーを自作する

次の手として、Swiper以外のライブラリを探す・試すということも考えましたが、

画像分の高さをあらかじめ保持させる
発火前後で予期せぬ高さ（縦）のレイアウト変更を発生しない

という明確なゴールがありましたので、「自分で作った方が早いだろう」ということで、スライダーを自作するに至りました。

以下は今回自作したスライダーの簡単な仕様解説になります。
※スライダーを作る方法は、他にも様々あると思いますのでご参考程度に。

今回自作したCLS対応スライダー

コーディング仕様

画像分の高さをあらかじめ保持する

Swiperの改善施策と同様で、

画像の外側の要素に対してposition: relative;を指定。
before属性に対してdisplay: block; padding-top: 38%（←画像の高さ÷画像の幅）;を指定。
画像自体にはposition: absolute; top: 0; left: 0; width: 100%; height: auto;を指定。

画像を消してもスライダーの高さが変わらないことを確認しながらコーディングしました。

スライダー自体の高さもあらかじめ保持する

スライダーのアイテムもposition: absolute;で配置したかったので、

スライダー自体に対してposition: relative;を指定。
before属性に対してdisplay: block; padding-top: 38%（←スライダーのアイテムの高さ＝画像の高さ÷画像の幅）;を指定。
スライダーのアイテムにはposition: absolute;を指定。

こちらも画像と同じ要領で、スライダーのアイテムが無かったとしてもスライダー自体の高さは変わらないことを確認しながらコーディングしました。

JSを切っても見た目はそのままの状態

JS発火前後のレイアウト変更は極力なくしたかったので、JSを切っても見た目はそのままの動かないスライダーがある状態にコーディングしました。

JS仕様

コーディング作業で、画像読み込み前・JS発火前でも高さやレイアウトが確実に保持されたスライダー（の見た目だけ）が用意できました。
あとはそれにJSを使って動きを付けるだけ。

ということで、とにかくスライド（横）の動きだけをつけるJSにしました。

スライダーのアイテムをtransform: translateX;を使って横並びに配置する。

スライダー自体もtransform: translateX;で「次へ」「前へ」の動きをする。

自作スライダーを実装してみた

ここまでの作業で理論上は高さ（縦）のレイアウト変更が全く生じないスライダーができました。

では、実装してみて結果がどうなったか。
以下、自作スライダー実装後のCLSスコアになります。

自作スライダー実装前後のスコア

実装前後	CLSスコア
実装前	0.348
実装後	0.064

結果は大成功で、大幅にCLSスコアを改善することができました。

さいごに

自作スライダーを実装したことで、大幅にCLSスコアを改善する事ができました。当然のことながら、自作スライダーはライブラリ使用と比べて作業コストは遥かに大きくなります。ただスライダーを実装するだけを目的とするならばライブラリで実装する方が早く確実です。

しかし、CLSの面でこれだけの効果が期待できるのであればスライダーを自作するのも決して無駄ではない、むしろコスパが高い作業といえるのではないでしょうか。
スライダー関連のCLSでお困りの場合は、いっそのことライブラリを諦めて自作してみるのも手かもしれませんね。

この記事を書いた人

クーシーブログ編集部

1999年に設立したweb制作会社。「ラスクル」「SUUMO」「スタディサプリ」など様々なサービスの立ち上げを支援。10,000ページ以上の大規模サイトの制作・運用や、年間約600件以上のプロジェクトに従事。クーシーブログ編集部では、数々のプロジェクトを成功に導いたメンバーが、Web制作・Webサービスに関するノウハウやハウツーを発信中。