React 向け Swiper 代替：本当に避けたいものは何かで選ぶ
誰も Swiper が悪いから離れるわけではありません — Swiper は現存する最も完成度の高いスライダーです。人々が離れるのは重さ（モジュール込みでない状態でも ≈40 kB）のため、その DOM と CSS を引き継ぐことになるため、あるいは自分たちの「スライダー」が実はスライドではなかったためです。それぞれの不満には、それぞれ最適な答えがあります。
| Swiper | Embla | keen-slider | react-horizontal-scrolling-menu | |
|---|---|---|---|---|
| バンドルサイズ（コア、min+gzip） | ≈40 kB | ≈8 kB | ≈7 kB | ≈5.7 kB |
| モデル | スライド、フル装備 | スライド、ヘッドレス | スライド、最小限のエンジン | ネイティブスクロール行の中のアイテム |
| エフェクトとモジュール | 最も豊富 | プラグイン／自作 | 一部組み込み | なし — 代わりにレシピを用意 |
| ジェスチャー層を独占するか | はい（transform） | はい（transform） | はい（transform） | いいえ — ブラウザがスクロール |
| アイテムごとの可視性 | スライドインデックスのイベント | スライドインデックスのイベント | スライドインデックスのイベント | 組み込み（useIsVisible） |
| 乗り換えに向いているとき | — | どうせ全部自分でスタイリングする | 最小限のスライダー、React に縛られたくない | 「スライド」がクリック可能なアイテムである |
サイズはおおよそのコアサイズです — Swiper はインポートしたモジュールに応じて増加します。つまり削ぎ落とした Swiper のビルドは評判より小さいということでもあります。
キロバイトから逃れる：Embla か keen-slider
プロダクトが本物のカルーセル — スナップし、一度に 1 ページ分のスライドを見せる — であれば、軽量エンジンはほぼそのまま置き換えられます：
- Embla（≈8 kB）：ヘッドレスで、物理演算が優れており、ファーストクラスの React フックを持ち、shadcn/ui のカルーセルの内部エンジンでもあります。マークアップと CSS はすべて自分で用意します — それがポイントです。
- keen-slider（≈7 kB）：フレームワークに依存しない最小限のエンジンで、同じスライダーを React と非 React の両方の画面に出す必要がある場合に向いています。
どちらも transform ベースのスライドモデルを維持しているので、フェードやカバーフローのようなエフェクトは自作のままです — それらに頼っているなら、削ぎ落とした Swiper のビルドの方が、それらを再実装するより正直なところ良い答えです。
スライドモデルから逃れる：メニュー形のケース
もう一つの出口は、Swiper のスライドのセマンティクスがそもそも構造を支えていなかったビルド向けです：カテゴリー行、ロゴウォール、タブの帯、チップバー、商品レール。兆候は slidesPerView: 'auto' に freeMode: true を組み合わせたような設定です — その組み合わせは、Swiper にネイティブスクロールのふりをさせているということです。
react-horizontal-scrolling-menu（≈5.7 kB）は、そのネイティブスクロールに加えて、ブラウザが提供しない部分を備えています：アイテムごとの可視性、scroll-to-item、エッジ対応の矢印、そして クリックを壊さないドラッグ。エフェクトなし、スナップなし、ジェスチャーエミュレーションなし — Netflix 風の行、タブ、チップバー の各ページ、または 完全な比較表 をご覧ください。
両方向への公平な注意
重さを減らすために Swiper から移行し、その後オートプレイ、ページネーション、a11y アナウンス、エフェクトを手作りすることになれば、40 kB の問題が人月単位の問題に変わってしまいます。自分の使い方が本当にその一部分でしかないなら軽量エンジンに乗り換え、スライドのセマンティクスがそもそも偽物だった場合にのみスクロールメニューに乗り換えましょう。Swiper の奥深さを使っているなら、Swiper を使い続けてください。