記事内に広告が含まれています。
私は旅行ブログをやっていて、記事に写真をたくさん載せています。写真が増えるほどページは重くなるので、画像を軽くする方法を、数字で確かめてみることにしました。
そこで今回は、自分のブログで使う写真3枚を使って、JPEG の保存し直しと WebP への変換でファイルサイズと画質がどう変わるかを実測しました。この記事では、測った数字をそのまま紹介します。
この記事でわかること
- JPEG を保存し直すとファイルサイズがどう変わったかがわかります。
- WebP の品質80と品質90で、サイズと画質にどんな差が出たかがわかります。
- WebP のロスレス保存が写真に向くかどうかがわかります。
- 表示幅に合わせて縮小してから WebP にすると、どこまで軽くなるかがわかります。
- 変換にかかった時間と、私が採用しようと考えている運用を紹介します。
測り方
素材にした写真
素材は、このブログの記事用に用意した写真3枚です。夜の運河、建物の外観、ボトルの棚の3枚で、いずれも 900×1200px の JPEG でした。元のファイルサイズは 210,187〜226,196 バイトです。
変換した5つのパターン
変換には Python の画像ライブラリ Pillow を使い、次の5パターンを試しました。実施日は 2026年11月3日で、環境は CPU 2コアの VM です。
- JPEG を品質85で保存し直します。
- WebP を品質80で保存します。
- WebP を品質90で保存します。
- WebP をロスレス（劣化なし）で保存します。
- 幅768pxに縮小してから、WebP を品質80で保存します。
なお、この環境の Pillow では AVIF を保存できなかったため、AVIF は試行していません。
画質の測り方
画質は ffmpeg の SSIM で測りました。SSIM は、1に近いほど元の画像に近いことを示す指標です。幅768pxに縮小したパターンだけは、縮小後の元画像と比べています。
結果の表
3枚の写真について、バイト数、元のJPEGに対する比率（元比）、SSIM をまとめました。
| 写真 | 元JPEG（バイト） | JPEG85（バイト／元比／SSIM） | WebP80（バイト／元比／SSIM） | WebP90（バイト／元比／SSIM） | WebPロスレス（バイト／元比／SSIM） | 幅768＋WebP80（バイト／元比／SSIM） |
|---|---|---|---|---|---|---|
| 夜の運河 | 217,784 | 228,339／104.8%／0.9967 | 148,016／68.0%／0.9742 | 236,348／108.5%／0.9896 | 900,388／413.4%／0.9986 | 112,678／51.7%／0.9777 |
| 建物の外観 | 210,187 | 221,206／105.2%／0.9961 | 147,768／70.3%／0.9701 | 229,916／109.4%／0.9886 | 869,254／413.6%／0.9982 | 108,662／51.7%／0.9751 |
| ボトルの棚 | 226,196 | 238,536／105.5%／0.9966 | 154,572／68.3%／0.9775 | 236,568／104.6%／0.9893 | 987,566／436.6%／0.9980 | 118,574／52.4%／0.9811 |
結果から分かったこと
JPEG の保存し直しは軽くならず、増えました
JPEG を品質85で保存し直しても、軽くはなりませんでした。3枚とも元比は 104.8〜105.5% で、わずかに増えています。SSIM は 0.9961〜0.9967 でした。
増えた理由は、元の JPEG が品質85より低い設定で保存されていたためではないかと考えています。ただし、これは推測です。元の保存設定そのものは確認できていません。
WebP 品質80は約3割小さくなりました
WebP を品質80で保存すると、3枚とも約3割小さくなりました。元比は 68.0〜70.3% です。SSIM は 0.9701〜0.9775 でした。
JPEG85 の SSIM（0.9961〜0.9967）と比べると数値は下がっています。この数字から見ると、軽くなった一方で、元画像との近さは少し下がったことがわかります。
WebP 品質90は元より大きくなりました
WebP を品質90にすると、3枚とも元のJPEGより大きくなりました。元比は 104.6〜109.4% です。SSIM は 0.9886〜0.9896 で、品質80より元画像に近い数値でした。
つまり、品質90では画質の数値は上がりますが、ファイルサイズの面では軽量化になりませんでした。
WebP のロスレスは約4倍になりました
WebP のロスレスは、写真では元の約4.1〜4.4倍になりました。SSIM は 0.9980〜0.9986 と最も高い数値でしたが、写真を軽くする目的には向かないとわかりました。
ちなみに、ロスレスなのに SSIM が 1.0 にならなかった点は、JPEG を読み込む側（Pillow）と SSIM を比べる側（ffmpeg）で、デコード結果にわずかな差があるためだと考えています。こちらも推測で、確かめてはいません。
幅768pxに縮小して WebP 品質80にすると約半分になりました
表示幅に合わせて幅768pxに縮小し、WebP 品質80で保存すると、元比は 51.7〜52.4% と約半分になりました。SSIM は 0.9751〜0.9811 でした。
縮小したパターンの SSIM は縮小後の元画像との比較なので、他のパターンと完全に同じ条件の数字ではありません。それでも、サイズが約半分になりながら、SSIM は 0.9751〜0.9811 と、縮小せずに品質80で保存したとき（0.9701〜0.9775）と同じくらいの数値でした。
変換にかかった時間
品質80・品質90・縮小して品質80の WebP は、1枚あたり 0.36〜0.79秒でした。ロスレスの WebP は 1.13〜1.91秒でした。JPEG の保存し直しは約 0.01秒以下でした。品質80の変換なら、100枚でも長くて約80秒の計算です。
私の運用
今回の実測から、私は次の運用にしようと考えています。
- 記事での表示幅に合わせて、画像を先に縮小します。
- 縮小した画像を WebP の品質80で保存します。
- JPEG の保存し直しや WebP の品質90は、軽量化が目的なら使いません。
- ロスレスは写真には使いません。
理由は単純で、今回の5パターンのうち、サイズが約半分になったのは縮小と WebP 品質80を組み合わせたときだけだったからです。画質の数値も、SSIM で 0.9751〜0.9811 に収まっていました。
ただし、今回測ったのは写真3枚だけです。AVIF も試していないので、他の形式との比較はできていません。別の写真や別の設定では結果が変わる可能性があります。
まとめ
ブログの写真3枚で測った結果、JPEG の保存し直しは約5%増え、WebP 品質80は約3割減り、WebP 品質90は増え、ロスレスは約4倍になりました。表示幅の768pxに縮小してから WebP 品質80で保存すると、元のファイルの約半分になりました。
写真を多く載せる私のブログでは、縮小してから WebP 品質80で保存する方法を使っていこうと考えています。写真の多い記事の例として、ニューオーリンズのハロウィンパレードの記事もあわせて読んでいただけるとうれしいです。
コメント