「トップのスライドショーが、スマホだとカクついたり、たまに画像が重なって表示されたりするんです。作ってもらった当時は動いていたのに。あと、ページの表示も遅い気がして」——先日、コーポレートサイトの改善を相談されたとき、担当者からこう言われました。開発者ツールで見てみると、トップの小さなスライダーひとつのために、重めのJavaScriptライブラリが読み込まれていました。
トップページのスライダー（カルーセル）は、多くのサイトが抱える「地味だが直しにくい」箇所です。重い、崩れる、遅い。しかも作り直そうにも、既存のライブラリに絡んでいて手を入れづらい。ところが2026年、状況が変わりました。CSSだけでカルーセルが組めるようになり、JavaScriptライブラリに頼らない選択肢が現実になったのです。本記事では、従来のスライダーがなぜ壊れやすいのか、CSSネイティブで何が変わるのか、受託で全面採用してよいのかを、ブラウザ対応の現実まで含めて整理します。
なぜ従来のスライダーは「重くて壊れやすい」のか
まず、症状の原因を押さえます。従来のカルーセルは、その大半をJavaScriptライブラリに依存してきました。ここに三つの弱点があります。
一つは重さです。スライドを1枚めくるだけの機能に、数十キロバイト規模のライブラリを読み込むことが珍しくありません。トップページの目立つ位置にあるため、これがページの初期表示を引っ張り、Core Web Vitalsの記事で扱っているような表示速度の指標を悪化させます。
二つ目は壊れやすさです。ライブラリはバージョンアップし、依存する他の部品とぶつかることがあります。冒頭の「作った当時は動いていたのに崩れた」は、たいていこの相性問題です。引き継いだサイトほど、誰も中身を把握しておらず、触るのが怖い状態になっています。
三つ目はアクセシビリティの抜けです。自前実装のスライダーは、キーボード操作や読み上げ対応が中途半端になりがちで、後から直すのに手間がかかります。
CSSだけでカルーセルが作れるようになった
ここで登場するのが、CSSの新しい擬似要素です。CSS Overflow Level 5という仕様で ::scroll-button() と ::scroll-marker() が追加され、前後の送りボタンと、下部の丸いページ指示（ドット）を、JavaScriptなしで作れるようになりました。
仕組みはシンプルです。横スクロールできる領域にスライドを並べ、スクロールスナップで1枚ずつ吸着させる。そこに ::scroll-button() で「前へ・次へ」を、::scroll-marker() でドットを生やす。ドットをクリックすれば該当スライドへ、ボタンを押せば前後へ——この挙動を、ブラウザが標準機能として面倒を見てくれます。
.carousel {
scroll-snap-type: x mandatory;
overflow-x: auto;
scroll-marker-group: after; /* ドット群を下に配置 */
}
.carousel > .slide {
scroll-snap-align: center;
}
/* 各スライドに対応するドットを生成 */
.carousel > .slide::scroll-marker {
content: "";
}
/* 前後の送りボタンを生成 */
.carousel::scroll-button(left) { content: "‹"; }
.carousel::scroll-button(right) { content: "›"; }外部ライブラリはゼロ。ドットの現在位置の強調（:target-current）やキーボード操作も、ブラウザ側が引き受けます。これは、CSSが年々「これまでJSでやっていたUIを標準機能として取り込む」流れの一部で、その全体像はモダンCSSネイティブ機能の記事でも触れています。
受託でいま全面採用してよいか — ブラウザ対応の現実
魅力的な技術ですが、受託で「明日から全サイトこれに」と飛びつくのは早計です。ここが判断のいちばん大事なところです。
::scroll-button() と ::scroll-marker() は、Chrome 135（2025年春）で対応が入り、Chrome系ブラウザでは広く動きます。一方、2026年半ば時点でもFirefoxの対応は部分的で、すべてのブラウザで同じように動くわけではありません。つまり、来訪者の使うブラウザによっては、送りボタンやドットが出ない可能性が残ります。
ここで効くのがプログレッシブ・エンハンスメントという考え方です。土台は「ただの横スクロール領域」として作っておけば、新機能に対応していないブラウザでも、指やトラックパッドでスワイプして全スライドを見られます。対応ブラウザでは、そこにボタンとドットが上乗せされる。機能が無くても壊れず、あれば快適になる——この作りにしておけば、対応状況を気にせず今から入れられます。
| 従来のJSライブラリ | CSSネイティブ + フォールバック | |
|---|---|---|
| 追加の読み込み | ライブラリ数十KB | ほぼゼロ（CSSのみ） |
| 更新で壊れるか | 依存衝突で崩れやすい | 標準機能なので壊れにくい |
| 未対応ブラウザ | ライブラリ次第 | 横スクロールとして機能する |
事例: 重いスライダーを外して、表示速度と保守性を取り戻した会社
具体例を挙げます。製造業のコーポレートサイト（社名は伏せます）で、「トップのスライダーがスマホで重く、たまに崩れる。作った会社とも今は取引がなく、誰も直せない」という相談を受けました。調べると、そのスライダーのためだけに重いライブラリと、それが依存する古い部品が積まれており、これがトップの表示を目に見えて遅くしていました。
そこで、スライダー部分をCSSネイティブのカルーセルに置き換えました。土台を素の横スクロールとして組み、対応ブラウザでは送りボタンとドットが乗る作りにして、古いライブラリ一式を撤去しました。結果、トップから重いスクリプトが消えて初期表示が軽くなり、更新で崩れる不安もなくなりました。派手な機能追加はしていません。効いたのは、「JSでやる必要のなかったUIを、壊れにくい標準機能に戻したこと」でした。動きの表現を足したい箇所は、同じくJS不要のスクロール駆動アニメーションの記事の手法と組み合わせています。
まずは「一番重い・一番壊れているカルーセル」から
CSSネイティブカルーセルは、すべてのスライダーを一斉に置き換えるための銀の弾丸ではありません。とはいえ、トップページのように目立ち、表示速度に効き、しかもライブラリで壊れがちな一箇所を置き換える効果は大きい。まずはサイトの中で一番重い、あるいは一番崩れているカルーセルを一つ選び、フォールバック込みで置き換えてみるのが現実的な入り口です。
トップのスライダーが重い・崩れる、作った会社と連絡が取れず直せない、表示速度を上げたい——そうしたお悩みがあれば、グリームハブのHP制作・リニューアル相談からお気軽にご相談ください。既存スライダーの棚卸しから、CSSネイティブへの置き換え、未対応ブラウザまで含めた壊れない作りの設計まで、過剰な作り込みを避ける形でご一緒します。
