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

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

Webサイトの表示速度を改善するうえで、画像の最適化は重要な施策の一つです。

特に画像容量が大きいページでは、JPEGやPNGをWebPに変換することで通信量を削減し、読み込み時間やLCPの改善につながる可能性があります。

本記事では、同じページをJPEG・PNG、WebP、AVIFで比較し、画像容量や転送量、表示速度がどのように変化するのかを実測検証します。

WebPが表示速度の改善につながる理由

画像ファイルの容量を削減できる

WebPは、JPEGやPNGと比較して画像ファイルの容量を削減できる場合がある画像フォーマットです。

同程度の画質を維持しながらデータ量を小さくできれば、ユーザーがダウンロードするデータ量を減らせます。

特に高解像度の写真や容量の大きい画像を多く使用しているページでは、1枚あたりの削減効果がページ全体に積み重なります。

画像容量が大きいほど通信時間にも影響しやすいため、WebPへの変換は表示速度を改善するための基本的な画像最適化施策の一つです。

ページ全体の転送量を削減できる

Webサイトでは、メインビジュアルや商品画像、バナー、記事内画像など、1ページに複数の画像が使用されることがあります。

各画像をWebPに変換して容量を削減できれば、ページ全体でブラウザがダウンロードするデータ量も減らせます。

例えば1枚あたりの削減量が小さくても、画像が20枚、30枚と増えることで大きな差になる可能性があります。

通信環境が限られるモバイル回線では特に影響が出やすく、ページ全体の転送量を抑えることで読み込み完了までの時間短縮につながります。

LCP画像の読み込み時間を短縮できる可能性がある

LCP(Largest Contentful Paint)の対象となる画像は、ページの主要コンテンツとして表示される大きな画像が該当するケースが多くあります。

例えば、ファーストビューのメインビジュアルが大容量のJPEGやPNGの場合、ダウンロードに時間がかかり、LCPの遅延につながる可能性があります。

この画像をWebPに変換してファイル容量を削減できれば、通信環境やサーバーの状況によっては画像の取得完了が早まり、LCPの改善につながることがあります。

ただし、画像形式の変更だけで必ず改善するとは限らず、読み込み優先度や画像サイズも重要です。

【独自検証】WebPで表示速度はどれだけ改善する?

実際に検証を行ってみました。動画もあるのでこちらもご覧ください。

詳しい内容は下記で解説していきます。

検証環境

項目

条件

ページ構成

同一HTML・CSS

Before

JPEG・PNG

After

WebP

画像枚数

17枚

画像サイズ

高解像度画像

比較環境

同一環境

検証ページの構成

  • ファーストビューの大型画像
  • 商品画像12枚
  • 大型バナー
  • PNG画像3枚

上記のような構成で検証を実施しました。

比較① 画像ファイル容量はどれだけ減る?

画像

ビフォー

WebP

削減率

JPEG商品画像(最大)

2.7 MB

436 kB

約84%

JPEG商品画像(最小)

1.5 MB

75.8 kB

約95%

PNG商品画像

4.2 MB

358 kB

約91%

JPEG商品画像をwebpにした場合

JPEG画像は主に商品画像で12枚程度の画像を使用しました。

上記画像の赤枠の通りで、JPEG画像は最大2.7MBの容量の画像はWebPにしたことで436 kBの容量になり、約84%の容量を削減に成功しています。

画像によっては1.5MBの画像が75.8kBと約95%の容量の削減ができているケースもあります。

PNG商品画像をwebpにした場合

PNG画像も最大4.2MBとかなり大きな容量の画像ですが、WebPへの変換で358 kBの容量と約91%まで削減となりました。

WebPへの変換でかなり容量の削減ができてたことになります。

比較② ページ全体の画像容量を比較

ページ全体の読み込み容量や時間を比較してみます。

上記画像の上部がビフォーの数値で、下部がアフターの数値です。

比較してみると下記のような数値の改善となりました。

改善①:NetworkのTransferred(転送量)が激減

結果的にページ全体のTransferred(転送量)は38.6MBから7.4MBになり、約80%近くの転送量が削減された計算になります。

BEFOREの転送量

AFTERの転送量

38.6MB

7.4MB

画像が重かったり、枚数が多かったりすると、1つのページを読み込み終わるまでにかなりの転送量がかかることがわかります。

これらをWebPに変換してあげるだけでも、かなり転送量が減らせることが見てわかります。

改善②:ページの読み込み完了時間を比較

ページが読み込み完了する時間もかなりの時間削減ができました。

BEFOREの読み込み時間

AFTERの読み込み時間

38.83s

7.84s

WebPに変換前のページは38.83sでWebP変換後は7.84sとなりました。

読み込み完了まで約80%近くも時間短縮ができたことになります。

比較③ WebPでLCPはどれだけ改善する?

WebPに変換することで、LCP画像の読み込みも早くなります。

今回はファーストビューの背景画像がLCPにあたりますが、変換前が35.57sだったLCPが7.90sとなりました。

画像の容量が明らかに削減され、LCP画像の読み込み完了時間も短くなったということがわかります。

BEFOREのLCP

AFTERのLCP

35.57s

7.90s

WebP化させることでLCP数値にも大きな影響を与えることがわかりました。

WebPに変換しても表示速度が改善しないケース

もともと画像容量が小さい

もともと画像ファイルの容量が小さい場合、WebPに変換しても表示速度への影響は限定的です。

例えば、数十KB程度の画像をさらに数KB削減できたとしても、ページ全体の通信量や読み込み時間には大きな差が出ないケースがあります。

WebP化による効果は、画像容量が大きいほど得られやすいため、すべての画像を一律に変換するのではなく、まずは容量の大きいメインビジュアルや商品画像、バナーなどから優先的に最適化することが重要です。

ページ下部の画像だけを変換している

WebPに変換する画像の場所によっては、ページの初期表示速度がほとんど改善しないことがあります。

特に、ページ下部にあり、ユーザーが最初に画面を開いた時点では表示されない画像だけを軽量化しても、ファーストビューの表示やLCPには直接的な影響を与えにくいでしょう。

表示速度を改善したい場合は、まずファーストビューのメインビジュアルやLCP対象となる画像など、ページ表示の早い段階で読み込まれる画像から優先的に最適化することが重要です。

JavaScriptやCSSがボトルネックになっている

ページの表示速度が遅い原因がJavaScriptやCSSにある場合、画像をWebPに変換しても大きな改善が見られないことがあります。

例えば、大量のJavaScriptによる処理や長いLong Task、レンダリングを妨げるCSS、第三者タグなどがボトルネックになっている場合、画像の通信量だけを削減しても表示完了までの時間は短縮されにくくなります。

そのため、WebP化だけで解決しようとせず、NetworkやPerformanceなどで原因を確認し、ボトルネックに応じた改善を行うことが重要です。

画像サイズ自体が大きすぎる

画像をWebPに変換してファイル容量を削減しても、実際の表示サイズに対して画像の解像度が大きすぎる場合は、十分な最適化とはいえません。

例えば、スマートフォンで幅500px程度しか表示されない画像に、幅4000pxの画像を使用していると、WebPでも不要に大きなデータを読み込む可能性があります。

WebP化とあわせて、表示サイズに合った画像を用意し、必要に応じてsrcsetsizesを利用してデバイスごとに適切な画像を配信することが重要です。

WebPで表示速度を改善する5つの方法

1. 大容量のJPEG・PNGから優先して変換する

WebPによる表示速度改善を効率的に進めるには、すべての画像を一律に変換するのではなく、容量の大きいJPEGやPNGから優先することが重要です。

数MBあるメインビジュアルや商品画像、バナーなどを軽量化できれば、1枚の変換でもページ全体の通信量を大きく削減できる可能性があります。

まずはChrome DevToolsのNetworkタブなどで、どの画像の容量が大きいかを確認しましょう。

容量の大きい画像を特定して優先的にWebP化することで、少ない作業でも効率的に表示速度改善を進められます。

2. LCP画像を優先的に最適化する

LCPの対象となる画像は、ページの主要コンテンツとして表示されるため、読み込み速度がCore Web Vitalsにも影響します。

ファーストビューのメインビジュアルなど、大容量のLCP画像をJPEGやPNGのまま使用している場合は、WebP化によってダウンロード時間を短縮できる可能性があります。

ただし、WebPに変換するだけでは十分とは限りません。画像の読み込み優先度や表示サイズも確認し、LCP画像が不要な遅延読み込みの対象になっていないか確認することも重要です。

3. 表示サイズに合った画像サイズにする

WebPは画像容量を削減しやすいフォーマットですが、解像度が必要以上に大きければ、不要なデータをダウンロードすることになります。

例えば、実際には幅600pxで表示される画像に幅4000pxのファイルを使用すると、WebPに変換しても効率的とはいえません。

画像はWebP化するだけでなく、実際の表示サイズや高解像度ディスプレイも考慮して適切なサイズを用意することが重要です。

画像の解像度と表示サイズを最適化することで、さらなる通信量削減が期待できます。

4. srcsetでデバイスごとに画像を出し分ける

PCとスマートフォンでは画面サイズが大きく異なるため、同じ高解像度画像をすべてのデバイスに配信すると、スマートフォンでは必要以上に大きな画像をダウンロードする場合があります。

srcsetを設定すると、ブラウザが画面サイズや解像度に応じて適切な画像を選択できるようになります。

WebP化した画像を複数のサイズで用意し、srcsetsizesと組み合わせることで、PCには大きな画像、スマートフォンには小さい画像を配信できます。

5. 画面外の画像はlazy loadingを組み合わせる

WebPへの変換に加えて、ファーストビューに表示されない画像にはlazy loadingを設定することで、初期表示時の通信量をさらに削減できます。

ページ下部の商品画像や記事内画像を最初からすべて読み込むのではなく、画面に近づいたタイミングで読み込むことで、ブラウザの初期負荷を抑えられます。

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

画像の重要度に応じてWebP化とlazy loadingを使い分けることが重要です。

WebPへの変換方法

オンラインツールで変換する

WebPへの変換は、専用のオンラインツールを利用すると比較的簡単に行えます。

変換したいJPEGやPNGファイルをアップロードし、WebP形式を選択するだけで画像を変換できるサービスが多くあります。

ソフトウェアをインストールする必要がなく、数枚の画像を手軽に変換したい場合に便利です。

一方で、大量の画像を変換する場合は作業に時間がかかることがあります。

また、Webサイトの画像や社外秘のデータをアップロードする際は、利用するサービスのセキュリティや保存・削除に関する仕様を確認することも重要です。

画像編集ソフトで変換する

Adobe Photoshopなどの画像編集ソフトを利用して、JPEGやPNGをWebP形式で書き出す方法もあります。

オンラインツールと比べて、画像ごとにサイズや画質、圧縮率などを細かく調整しながら変換できる点がメリットです。

例えば、写真は画質を維持しながら圧縮率を調整し、イラストや透過画像は用途に応じて設定を変えるといった使い分けができます。

変換後は、ファイル容量だけでなく実際の表示品質も確認し、容量削減と画質のバランスを取ることが重要です。

コマンドラインで変換する

大量の画像をまとめてWebPに変換したい場合は、コマンドラインツールの利用が便利です。

例えばWebPの変換ツールを使用すると、指定したフォルダ内のJPEGやPNGを一括でWebPに変換できます。

変換時には画質や圧縮設定を指定できるため、同じ条件で複数の画像を処理しやすい点もメリットです。

Webサイトの画像を定期的に最適化する場合や、開発環境で画像変換を自動化したい場合にも活用できます。

事前に元画像をバックアップしておくと安心です。

WebPを導入するときの注意点

画像の画質を確認する

WebPに変換する際は、ファイル容量だけでなく画像の画質も確認することが重要です。

圧縮率を高く設定しすぎると、写真の細部が失われたり、輪郭周辺にノイズが発生したりする場合があります。

特に商品画像やサービスの訴求に使用するメインビジュアルでは、画質の低下がユーザー体験やコンバージョンに影響する可能性もあります。

変換後はファイルサイズだけで判断せず、元画像と比較しながら、PCやスマートフォンなど実際の表示環境で画質に問題がないか確認しましょう。

元画像を削除しない

WebPへの変換後も、元となるJPEGやPNGはすぐに削除せず、バックアップとして保存しておくことをおすすめします。

変換後に画質の問題が見つかった場合や、圧縮設定を変更して再度WebPを作成したい場合、元画像がなければ再編集が難しくなるためです。

また、将来的に別の画像フォーマットへ変換したり、印刷物や別の媒体で高解像度画像が必要になったりするケースもあります。

Webサイト用のWebPと元画像を分けて管理し、必要に応じて再変換できる状態を維持すると安心です。

すべての画像を同じ設定で変換しない

WebPへの変換設定は、すべての画像で同じにする必要はありません。写真、イラスト、ロゴ、透過画像などは、画像の特徴や用途によって適切な圧縮設定が異なります。

例えば、細かな文字や輪郭を含む画像を強く圧縮すると、見た目の劣化が目立つ場合があります。

一方で、背景写真などは多少圧縮率を高くしても違いが分かりにくいケースがあります。

画像ごとに画質とファイル容量を確認し、用途に応じて設定を調整することで、画質を維持しながら効率的に容量を削減できます。

LCP画像はlazy loadingしない

ファーストビューに表示されるメインビジュアルなど、LCPの対象となる重要な画像には、原則としてlazy loadingを設定しないようにしましょう。

遅延読み込みを指定すると、ブラウザが画像の取得を後回しにすることで、主要コンテンツの表示が遅れ、LCPが悪化する可能性があります。

WebPによって画像容量を削減する場合も、LCP画像はページの読み込み開始時に取得できる状態にしておくことが重要です。

画面外の画像にはlazy loadingを活用し、ファーストビューの重要画像とは使い分けることで、効率的な画像最適化につながります。

WebPの表示速度に関するよくある質問

Q. WebPにすると必ず表示速度は改善しますか?

必ず改善するとは限りません。WebPによって画像容量を削減できても、もともと画像が軽い場合や、JavaScript・CSS・サーバー応答がボトルネックになっている場合は、表示速度への影響が小さいことがあります。

特に効果を得やすいのは、大容量の画像やファーストビュー、LCP対象の画像です。変換後は容量だけでなく、実際の転送量やLCPなども確認しましょう。

Q. WebPとJPEGではどちらが軽いですか?

同じ画像・同程度の画質で比較した場合、WebPの方がJPEGよりファイル容量を小さくできるケースが多くあります。

ただし、削減率は画像の内容や圧縮設定によって異なります。写真によっては大きな差が出ない場合もあるため、すべての画像で同じ結果になるわけではありません。

実際に変換して容量と画質を比較し、用途に合った設定を選ぶことが重要です。

Q. WebPとAVIFではどちらがおすすめですか?

より高い圧縮効率を重視する場合はAVIF、導入のしやすさや幅広い利用を重視する場合はWebPが選択肢になります。

ただし、AVIFの方が必ず表示速度に有利とは限りません。元画像や圧縮設定、画像サイズ、変換・配信環境によって結果は異なります。

まずWebPで画像最適化を進め、さらに容量削減が必要な画像についてAVIFも比較検証する方法がおすすめです。

Q. PNGをWebPに変換しても透過は維持できますか?

はい。WebPはPNGと同様に透過情報であるアルファチャンネルに対応しているため、適切な方法で変換すれば背景の透明部分を維持できます。

そのため、透過PNGのロゴやイラストなどもWebPへ変換できます。ただし、変換方法や圧縮設定によって画質が変化する場合があります。

特に文字や細かい線を含む画像は、変換後に実際の表示品質を確認することが重要です。

Q. WebP画像はSEOに影響しますか?

WebPを使用したこと自体が検索順位を直接向上させるわけではありません。

ただし、画像容量を削減することでページの通信量や読み込み時間を改善できれば、ユーザー体験やCore Web Vitalsの改善につながる可能性があります。

また、画像検索を意識する場合は、画像形式だけでなく、適切なファイル名やalt属性、周辺コンテンツなども重要です。WebPはSEO施策の一部として考えるのが適切です。

Q. WebPにすると画質は悪くなりますか?

設定によっては画質が低下しますが、適切な圧縮設定を選べば、元画像と大きな違いを感じにくい状態で容量を削減できる場合があります。

重要なのは、容量だけを優先して圧縮率を高くしすぎないことです。商品画像やメインビジュアルなどは特に、変換後のファイルサイズと画質を比較しながら調整しましょう。

画像の種類や用途によって最適な設定を変えることも大切です。

WebP対応での表示速度まとめ

WebPは、JPEGやPNGと比較して画像ファイルの容量を削減できる可能性があり、ページ全体の通信量や画像の読み込み時間を改善する有効な方法です。

特に大容量のメインビジュアルや商品画像、LCP対象の画像を最適化することで、表示速度への効果が期待できます。

ただし、WebPに変換するだけで必ず改善するとは限りません。

画像の表示サイズや読み込み方法、JavaScript・CSSなどの影響も確認し、srcsetやlazy loadingなどの施策と組み合わせて最適化することが重要です。

記事を書いた人

井上寛生

井上寛生

LandingHub 執行役員 / 事業責任者 / 技術責任者

大学院では情報工学を専攻し、修了後に株式会社TeNへ新卒入社。当時は社内唯一のエンジニアながら、開発部門をゼロから立ち上げ、採用・育成を一手に担い、全員が未経験からスタートした精鋭エンジニアチームを組成。2021 年にはWEBサイト高速化プラットフォーム「LandingHub」を立ち上げ、プロダクトオーナー兼事業責任者として企画・開発・グロースを牽引。現在は執行役員として、会社の技術戦略と事業成長の双方をリードしている。
コラム一覧に戻る