画像スライダーは、ECサイトやランディングページなどで商品の魅力やサービスの特徴を伝えるために活用されています。

一方で、複数の画像を読み込むことで、ページの表示速度に影響を与える場合があります。

表示速度が低下すると、ユーザーの離脱やコンバージョン率の低下につながる可能性もあります。

本記事では、画像スライダーの読み込みを最適化する方法を解説します。

さらに、独自検証を通じて、画像の遅延読み込みや圧縮などの施策が表示速度にどのような影響を与えるのか、実測データをもとに検証します。

画像スライダーがサイトの表示速度に与える影響

画像スライダーの仕組みと利用される場面

画像スライダーは、複数の画像を1つの表示領域に配置し、スライド形式で切り替えて表示する仕組みです。

商品の画像やバナーを順番に表示できるため、限られたスペースで複数の情報を伝えたい場合に適しています。

例えば、ECサイトでは商品の特徴や使用イメージを紹介するために利用され、ランディングページではサービスの強みやキャンペーン情報を訴求するために活用されています。

ただし、スライダーを実装する際には、画像の読み込みに加えて、スライドを切り替えるためのJavaScriptやCSSなども必要になる場合があります。

そのため、画像の枚数や容量、実装方法によっては、ページの読み込みにかかる負荷が大きくなります。

複数の画像を読み込むことで発生する問題

画像スライダーに使用する画像の枚数が多いと、ブラウザが複数の画像ファイルをダウンロードする必要があります。

特に、すべての画像をページの初期表示時に読み込む実装では、画像の転送量が増加し、ネットワーク環境によっては読み込みに時間がかかる場合があります。

また、画像のファイルサイズが大きい場合、ダウンロードに時間がかかるだけでなく、画像のデコードや表示処理にも負荷がかかる可能性があります。

こうした問題は、通信速度が遅いスマートフォンやモバイル回線を利用しているユーザーにとって、ページの表示が遅いと感じる原因になります。

画像の枚数を減らすことが難しい場合でも、画像の圧縮や遅延読み込みなどによって、初期表示時の負荷を抑えられる可能性があります。

画像の読み込みによる通信量や表示遅延の問題

画像スライダーの表示速度を考えるうえでは、画像の読み込みに伴う通信量も重要なポイントです。

高解像度の画像を複数使用している場合、初期表示時にダウンロードするデータ量が増え、画像が表示されるまでの時間が長くなる可能性があります。

また、PC向けの大きな画像をスマートフォンでもそのまま配信している場合、実際の表示サイズに対して必要以上に大きなデータをダウンロードしてしまうことがあります。

こうした問題を改善するには、画像の圧縮やWebP・AVIFなどの次世代画像フォーマットの活用、画面サイズに応じた画像の出し分け、2枚目以降の画像の遅延読み込みなどが有効です。

画像スライダーは、画像を表示する順序やファイルサイズ、配信方法を見直すことで、初期表示時の通信量を削減し、表示速度の改善につなげられる可能性があります。

ここからは、画像スライダーの表示速度を改善するための具体的な方法を紹介します。

【独自検証】画像スライダーの読み込みの表示速度を比較

実際に検証してみた結果を動画で撮影しています。

まずはこちらをご覧ください。

左側が修正前（ビフォー）ページで、右側が改善後（アフター）のページとなります。

検証方法は、下記で解説していきます。

画像スライダーの読み込み最適化の検証条件

上記のようなページにビフォーアフター比較できる画像スライダーを設置し比較検証を行いました。

また、実施した改善内容は下記に解説していきます。

今回やった画像スライダーの読み込み最適化の改善方法

今回の独自検証を行うにあたり、実際に実践した改善方法を下記にご紹介します。

初期表示画像は優先・2枚目以降は遅延読み込み

1つ目の方法として、初期表示に必要な画像を優先的に読み込むようにし、2枚目以降の画像を遅延読み込みさせます。

すべての画像を一度に読み込むと、初期表示時の通信量が増え、表示速度への影響を防げます。特にファーストビューのメイン画像の場合はLCP（Largest Contentful Paint）にも影響します。

具体的には、初期表示の画像にはfetchpriority="high"を指定し、2枚目以降の画像で表示を遅らせてもいい画像にはloading="lazy"を設定します。

変更前ソース

<div class="slider">
  <img src="product01.jpg" alt="スライド1">
  <img src="product02.jpg" alt="スライド2">
  <img src="product03.jpg" alt="スライド3">
  <img src="product04.jpg" alt="スライド4">
  <img src="product05.jpg" alt="スライド5">
  <img src="product06.jpg" alt="スライド6">
</div>

変更後ソース

<div class="slider">
  <!-- 初期表示画像：優先的に読み込む -->
  <img src="product01.jpg" alt="スライド1" fetchpriority="high">

  <!-- 2枚目以降：遅延読み込み -->
  <img src="product02.jpg" alt="スライド2" loading="lazy">
  <img src="product03.jpg" alt="スライド3" loading="lazy">
  <img src="product04.jpg" alt="スライド4" loading="lazy">
  <img src="product05.jpg" alt="スライド5" loading="lazy">
  <img src="product06.jpg" alt="スライド6" loading="lazy">
</div>

画像の遅延読み込みだけを行った検証も実施していますので、参考にご覧下さい。

【実践解説】画像の遅延読み込みの設定方法と表示速度の改善効果を実測比較

画像圧縮と次世代フォーマットでファイルサイズを削減する

ここでは元の画像を圧縮する作業と、次世代フォーマットに変換させる作業を実施しています。

この作業により、画像容量が削減されるため画像の読み込みが速くなります。画像の読み込みが速くなることでページ全体の読み込みも改善される仕組みです。

圧縮ツールや拡張子変換のツールでも変換できますが、LandingHubを導入頂ければ自動的に圧縮と次世代フォーマットに変更されるので作業工数が軽減されおすすめです。

拡張子が変更された画像は下記のように変更しておきましょう。

変更前

<div class="slider">
  <img src="product07.jpg" loading="lazy">
  <img src="product08.jpg" loading="lazy">
  <img src="product09.jpg" loading="lazy">
</div>

変更後

<div class="slider">
  <img src="product07.webp" loading="lazy">
  <img src="product08.webp" loading="lazy">
  <img src="product09.webp" loading="lazy">
</div>

下記の記事で画像圧縮、次世代フォーマットに変更した場合の違いを検証しています。

【独自検証】画像圧縮でどこまで表示速度は改善される？実際に検証してみた

【独自検証】webpの対応で表示速度はどのくらいかわる？

レスポンシブ画像に対応させる

レスポンシブ画像の対応も実施することでスマホ表示の際の画像容量も削減できます。

こうすることで、スマホ表示の際の画像読み込み容量が削減され、ページ全体の表示速度も改善ができます。

具体的な方法として、HTMLのsrcset属性とsizes属性を使用して、複数のサイズの画像を用意し、ブラウザに適切な画像を選択させることができます。

ソースはこのように修正します。

変更前

  <img src="product09.webp" loading="lazy">

変更後

<img
  src="product09.webp"
  srcset="
    product09-400.webp 400w,
    product09-800.webp 800w,
    product09-1200.webp 1200w
  "
  sizes="(max-width: 600px) 100vw, 800px"
>

このソースでは、幅400px・800px・1200pxの画像を用意し、srcsetで候補を指定しています。

※画像はそれぞれのサイズを準備しておかないといけません。

sizesは、画面幅600px以下では画像を画面幅いっぱいに、それより大きい画面では表示幅を800pxとしてブラウザに伝えます。

レスポンシブ画像だけでどこまで改善できるかも検証を行っています。

【独自検証】レスポンシブ画像で表示速度は改善する？具体的な改善方法は？

スライダーの実装方法やJavaScriptを見直す

画像スライダーには、画像の切り替えや自動再生、ページネーションなどを実現するために、JavaScriptライブラリが使用されることがあります。

しかし、実際には使っていない機能まで読み込んでいる場合、必要以上にJavaScriptのファイルサイズや実行負荷が増えてしまいます。

ここでは、使用していない機能を削除できないか確認します。

具体的には下記のポイントを確認してみましょう。

• 自動再生を停止してよければ停止する
• アニメーションが複雑な場合は見直す
• 不要なJavaScriptライブラリは削減する
• スライダーの初期化処理を見直す

これらの機能が特に重要でなければ削除や停止ができるかを検討しましょう。

削除することでJavaScriptのファイルサイズや実行負荷が軽減されます。

1つ1つ解説していきます。

自動再生を停止させる

自走再生を停止させる場合、autoplayの設定を削除もしくは停止させるように記述します。

今回の場合、変更前のソースは下記のようになっています。

    document.querySelectorAll(".heavy-slider").forEach((element) => {
      new Swiper(element, {
        loop: true,
        speed: 1400,
        autoplay: { delay: 900, disableOnInteraction: false },
        effect: "fade",
        navigation: { nextEl: ".before-next", prevEl: ".before-prev" }
      });

修正前は loop: trueとautoplay を設定し、スライドを自動で切り替えていました。

変更後は下記のように記述します。

document.querySelectorAll(".heavy-slider").forEach((element) => {
  new Swiper(element, {
    loop: false,
    speed: 1400,
    effect: "fade",
    navigation: {
      nextEl: ".before-next",
      prevEl: ".before-prev"
    }
  });

loop: falseに変更しautoplayの部分を丸っと削除し、修正後はこの設定を削除し、ユーザーが操作したときにスライドが切り替わる構成にしています。

複雑なアニメーションを見直す

スライドの切り替え時に、位置・透明度・ぼかしなど複数のアニメーションを同時に実行している場合は、不要な演出を減らしてシンプルにします。

修正前

.swiper-slide {
  opacity: .35;
  filter: blur(5px) saturate(.6) contrast(1.08);
  transform: scale(.96) translateY(8px) rotate(.15deg);
  transition:
    opacity 1.2s ease,
    filter 1.2s ease,
    transform 1.2s cubic-bezier(.2,.8,.2,1);
}

修正前は、透明度の変化（opacity）を設定、ぼかし（filter: blur(5px)）、彩度の変化（saturate(.6) ）、コントラストの変化（contrast(1.08)）、拡大・縮小（transform: scale(.96)）、上下移動（translateY(8px)）、回転（rotate(.15deg)）、各効果のアニメーション時間（ transition）など様々なアニメーションを設定してある仕様となっています。

修正後

.swiper-slide {
  opacity: 1;
  filter: none;
  transform: none;
  transition: opacity .2s ease;
}

修正後は上記のように、必要のないアニメーションを減らしシンプルな表示にしています。

アニメーションの種類や処理を減らすことで、描画負荷を軽減できる可能性があります。

不要なJavaScriptライブラリは削減する

スライダーで使用していないライブラリを読み込んでいる場合は、その読み込みを削除します。

不要なJavaScriptのダウンロードや解析を減らすことにつながります。

修正前

<script src="https://cdn.jsdelivr.net/npm/swiper@11/swiper-bundle.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/slick-carousel@1.8.1/slick/slick.min.js"></script>

ページではSwiperだけでスライダーを実装しているにもかかわらず、修正前は、SwiperとSlickという2つのスライダーライブラリを読み込んでいます。

そのため、余計なJavaScriptのダウンロードや解析が発生します。

修正後

<script src="https://cdn.jsdelivr.net/npm/swiper@11/swiper-bundle.min.js"></script>

修正後は、Swiperだけを使用していることを確認したうえで、Slickの読み込みを削除しています。

使用していないライブラリを削減すると、JavaScriptの転送量や解析・実行にかかる時間を減らせる可能性があります。

なお、ライブラリを削除する際は、そのライブラリに依存する処理がほかのページや機能で使われていないかも確認しておきましょう。

スライダーの初期化処理を見直す

ページ内に複数のスライダーが設置されている場合、すべてをページ表示時に初期化すると、初期表示時のJavaScript実行負荷が大きくなる可能性があります。

そこで、画面外にあるスライダーはすぐに初期化せず、画面内に近づいたタイミングで初期化する方法があります。

修正前

document.querySelectorAll(".heavy-slider").forEach((element) => {
  new Swiper(element, {
    loop: false,
    navigation: {
      nextEl: ".before-next",
      prevEl: ".before-prev"
    }
  });
});

修正前は、querySelectorAll() でページ内のすべてのスライダーを取得し、ページ表示時にまとめて初期化していました。

修正後

const sliders = document.querySelectorAll(".heavy-slider");

const observer = new IntersectionObserver((entries, observer) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      const element = entry.target;

      new Swiper(element, {
        loop: false,
        navigation: {
          nextEl: element.parentElement.querySelector(".before-next"),
          prevEl: element.parentElement.querySelector(".before-prev")
        }
      });

      observer.unobserve(element);
    }
  });
}, {
  rootMargin: "100px"
});

sliders.forEach((element) => {
  observer.observe(element);
});

修正後は、IntersectionObserver を利用してスライダーが画面内に近づいたかどうかを監視します。

rootMargin: "100px" を指定することで、画面内に入る100px手前を目安に初期化処理を実行します。また、初期化が完了したスライダーは監視対象から外すため、同じスライダーが何度も初期化されることを防げます。

これにより、初期表示時に実行するJavaScript処理を減らせる可能性があります。

特に、ページ下部に複数のスライダーが配置されている場合に有効な方法です。

ただし、ファーストビューに配置されたスライダーまで初期化を遅らせると、操作できるようになるまでの時間が長くなったり、表示に影響したりする可能性があります。

そのため、ファーストビューのスライダーは優先的に初期化し、画面外にあるスライダーを中心に遅延初期化を適用することが重要です。

【検証結果】画像スライダーの読み込み最適化

実際の検証結果はこのようになりました。

改善効果１：ページ読み込み完了時間が短縮

まずわかりやすく変化があったのが、ページ全体の読み込み完了時間が短くなったということです。

27.55秒から1.26秒まで短縮されました。

ページ全体のデータ容量も、27.3MBから750KBまで削減されていることがわかります。

ここまで削減されている要因も下記の要素なども大きく影響しています。

読み込まれる画像の拡張子変更とスマホ用サイズの変更

レスポンシブ画像の設定を行ったことで、読み込まれる画像も変わっています。

もちろんスマホ用なのでサイズが小さいものが読み込まれています。

ビフォーでは通常の画像を読み込んでいますが、アフターではスマホ用のサイズに変更した画像を読み込むようになっています。

また、拡張子もjpegからwebpにした画像を読み込むようにしています。

この施策により、1MBや2MBほどあった画像が、18〜60KBほどまで画像容量が圧縮されていることがわかります。

こういった部分の改善の影響も大きく、かなりページの読み込み速度が改善されていることになります。

改善効果２：LCPの数値の変化

LCPの数値も大きな改善がありました。

何もしてないビフォーのページはLCPが12.79秒だったのに対し、改善後のアフターページは0.61秒と12秒近く速くなっています。

ファーストビューの重いスライド画像の影響はもちろんですが、画像スライダーのフェードや自動スライドなど重いjavascriptが動いていた影響も出ていると思います。

これらを自動スライドさせず、画像の動きを静的に変更させたことで改善がされたと考えています。

改善効果３：ページの見た目でも変化があります

数値面ももちろんですが、ページの見た目の部分も大きな変化があります。

特に見た目の部分はユーザー体験に影響が出る部分になります。

スライド動作の動きの変化

元のページは自動スライドが実行されている、かつ画像の読み込みも遅いというダブルパンチでした。

こちらの画像をみても、画像も読み込み切れていない状況なのにスライドで別の画像に切り替わっているのがわかります。

これだと何が表示されているのか見てるユーザーもわかりませんよね。

また、画像がスライドするときも、画像がぼやけるような動的な動きで切り替わるようになっていますが、これも重くなる要素になります。

改善後は無駄な動きをカットし、スライドもボタンを押したらスライドされるように変更されています。

自動で画像は切り替わりませんが、画像の表示は速く表示されるためユーザー体験も向上すると考えています。

スクロール後の画像読み込みがズムーズ

スクロール後に表示される画像にも変化が生まれています。

ビフォーのページはスクロール後にまだ画像が読み込まれているのに対し、改善後のページは画像読み込みが完了しています。

画像スライダーや画像自体の容量などの読み込み容量が改善されている影響もありますが、遅延読み込みの影響も十分にあります。

ビフォーページは、ページ全体を一気に読みにいくため表示が遅くなりますが、改善後のページはスクロールごとに必要な画像を読み込みます。

そのため、無駄な読み込みが発生せず、1つ1つの画像が速く表示されます。

画像スライダーの表示速度改善に関するよくある質問

画像スライダーを設置すると表示速度は遅くなる？

画像スライダーを設置すると、複数の画像やJavaScriptを読み込む必要があるため、表示速度が遅くなる場合があります。

特に、高解像度の画像を大量に使用したり、すべての画像をページ表示時に一括で読み込んだりすると、通信量や読み込み処理の負担が増加します。

初期表示画像の優先読み込みや2枚目以降のLazy Load、画像圧縮などで負荷を軽減できます。

画像スライダーのLazy LoadはLCP改善に効果がある？

画像スライダーのLazy Loadは、LCPの改善に効果がある場合があります。

特に、初期表示時に画面外にある2枚目以降の画像を遅延読み込みすることで、初期表示に必要な通信量を削減できます。

ただし、LCPの対象となるファーストビューの画像まで遅延読み込みすると、かえって表示が遅くなる可能性があります。

最初の画像は優先的に読み込むことが重要です。

WebPやAVIFに変換すると表示速度は改善する？

WebPやAVIFなどの次世代画像フォーマットに変換すると、画質を維持しながらファイル容量を削減でき、画像のダウンロード時間を短縮できます。

特に、高解像度の画像を複数使用するスライダーでは、通信量の削減による効果が期待できます。

ただし、変換後の容量や画質は画像によって異なるため、実際のファイルサイズを比較して判断することが大切です。

画像スライダーの最適化にはJavaScriptの知識が必要？

画像スライダーの最適化には、必ずしも高度なJavaScriptの知識が必要なわけではありません。

画像圧縮やWebP・AVIFへの変換、Lazy Loadなどは、CMSの機能やプラグイン、最適化ツールを利用して対応できる場合があります。

一方、スライダーの初期化処理やアニメーション、不要なJavaScriptの削除など、動作そのものを見直す場合は、JavaScriptの知識が必要になることがあります。

画像を最適化しても表示速度が改善しないのはなぜ？

画像を最適化しても表示速度が改善しない場合、画像以外のリソースがボトルネックになっている可能性があります。

例えば、JavaScriptの実行処理、CSSの読み込み、Webフォント、サーバーの応答時間なども表示速度に影響します。

また、LCP対象の画像が優先的に読み込まれていないケースもあります。

NetworkタブやPageSpeed Insightsで読み込み状況を確認し、画像以外の原因も調査することが重要です。