計算ツール
画像圧縮WebPAVIFJPEGCore Web VitalsWeb最適化

画像圧縮率シミュレーター|JPEG/PNG/WebP/AVIF容量推定・Core Web Vitals対策

解像度(幅×高)と保存形式から画像容量とPNG比削減率を即算出。Core Web Vitals(LCP・INP・CLS)Google PageSpeed Insightsのスコア改善、CDN転送量削減モバイル通信量圧縮を目的とした画像最適化施策を、ISO 10918-1 JPEGW3C WebP仕様ISO/IEC 23000-22 AVIF等の国際標準に基づいて評価。ECサイトの商品画像、Webメディアのサムネイル、SNS投稿、印刷入稿ラスタ画像まで、Web制作・EC運営・SNS運用の現場で使える実務ツールです。

最終更新:2026-07-29/監修:計算ツールズ編集部

画像圧縮率シミュレーターツール

画像容量算定式と圧縮原理

非圧縮(RAW/BMP/PNG)の理論容量

サイズ(bytes) = 幅(px) × 高(px) × チャネル数 × ビット深度/8

フルHD(1920×1080)の32bit RGBA画像なら、1920×1080×4=約8.3MB。8bit RGB(3チャネル)なら約6.2MB。この生データを可逆・非可逆で圧縮するのが各フォーマットです。

PNG(Portable Network Graphics)— 可逆圧縮

Deflate(LZ77+Huffman)で情報を欠損させずに圧縮。写真では30〜50%程度しか小さくならないが、イラスト・図表・ロゴでは80%以上削減可能。アルファチャネル(透過)対応で、UIパーツやロゴの標準形式です。

JPEG(Joint Photographic Experts Group)— 非可逆圧縮

DCT(離散コサイン変換)+ 量子化 + Huffman符号化で人間の視覚特性(高周波成分に鈍感)を利用して大幅圧縮。品質パラメータQ=80が業界標準(画質と容量のバランス最良)、Q=60でWebサムネ、Q=90以上は印刷用途。透過不可・写真専用。

WebP — Googleの次世代フォーマット

VP8/VP9動画コーデックの静止画版。JPEG比25〜35%、PNG比80〜90%容量削減。可逆・非可逆両対応、透過対応、アニメーション対応(GIF代替)。2010年公開、2023年時点で全主要ブラウザ対応済み。

AVIF — 最新の高効率フォーマット

AV1動画コーデックの静止画版(ISO/IEC 23000-22, MIAF)。JPEG比50%、WebP比20%容量削減。HDR・10bit色深度対応。2020年公開、Chrome/Edge/Firefox/Safari 16.1以降対応。エンコード時間はJPEGの10〜20倍だが、CDN配信・キャッシュとの相性は良好。

数値感覚(1920×1080フルHD写真の場合)

PNG: 約2.5MB / JPEG Q80: 約400KB / WebP: 約250KB / AVIF: 約150KB。PNGからWebPに変換するだけで90%削減、AVIFなら94%削減。モバイル4G通信(10Mbps)でPNG 2秒 → AVIF 0.12秒の劇的高速化が可能です。

主要画像形式の比較

形式圧縮方式透過アニメブラウザ対応用途
PNG可逆(Deflate)◎ 8bit α×全対応ロゴ・UI・図表・スクリーンショット
PNG-8可逆(256色パレット)○ 1bit α×全対応アイコン・シンプル図
JPEG非可逆(DCT)××全対応写真・グラデーション画像
JPEG XL可逆・非可逆両対応Chrome試験実装写真高効率保存
GIF可逆(LZW・256色)△ 1bit α全対応アニメーション・低解像度
WebP両対応(VP8/VP9)全対応(2020以降)Web汎用最適化
AVIF両対応(AV1)Chrome/Edge/Firefox/Safari16+次世代Web・HDR
SVGベクター(XML)◎(SMIL)全対応アイコン・ロゴ・図
TIFF可逆(LZW/ZIP)×非対応(DL)印刷・アーカイブ
HEIC/HEIF非可逆(HEVC)Safari限定iPhoneカメラ標準

2026年のWeb標準推奨: 写真は<picture>要素で AVIF → WebP → JPEG のフォールバック、ロゴ・アイコンはSVG、UIスクショはPNG。GIFはWebPアニメーションに置換が推奨されます。

Core Web Vitals(LCP)と画像

LCP(Largest Contentful Paint)とは

ページ内で最も大きな要素(多くはヒーロー画像・メインビジュアル)が表示されるまでの時間。Good=2.5秒以下、Needs improvement=2.5〜4秒、Poor=4秒超。Google検索ランキング要因(Page Experience Update)の一つで、SEO順位に直結します。

画像がLCPに与える影響

ヒーロー画像の容量が大きいと、モバイル回線でダウンロードに数秒かかり、LCPが4秒超で「Poor」判定に。WebP/AVIF採用で容量を1/5にすれば、LCPは秒単位で改善します。

画像最適化のLCP改善効果(実測)

施策LCP改善効果実施難易度
PNG→WebPへの変換-1.5〜-2.5秒易(一括変換ツール)
PNG→AVIFへの変換-1.8〜-3.0秒中(CDN対応必要)
<img loading="lazy">付与-0.5〜-1.0秒易(1行追加)
<picture>要素で複数解像度提供-0.8〜-1.5秒中(マークアップ変更)
fetchpriority="high" ヒーロー画像-0.5〜-1.2秒易(属性追加)
CDN経由配信(Cloudflare Images等)-1.0〜-2.0秒中(設定変更)

PageSpeed Insightsの推奨事項

「次世代フォーマットでの画像の配信」「効率的な画像フォーマット」「画像の遅延読み込み」「適切なサイズの画像」の4項目が画像関連。全て対応するとモバイルスコア30→90+の劇的改善が可能で、SEO順位・広告品質スコア(ランディングページ体験)に大きく影響します。

業界別 現場での応用

ECサイト運営

商品画像は1SKUあたり5〜20枚が標準で、サイト全体で数万〜数百万枚に及びます。PNG→WebP一括変換でストレージ90%削減・CDN転送コスト80%削減、モバイル商品ページ表示速度を3倍高速化。Shopify・BASE・Amazon等主要プラットフォームは自動WebP変換対応済み。

Webメディア・ブログ運営

記事内画像・アイキャッチ画像の最適化はSEOに直結。特にCore Web Vitals合格ラインをクリアすることでGoogle検索順位が改善。WordPressならEWWW Image OptimizerImagifyプラグイン、Next.js/Nuxtは<Image>コンポーネントで自動最適化。

SNS運用・広告クリエイティブ

Instagram・X(旧Twitter)・TikTokの投稿画像は自動圧縮されるため、事前に容量調整。広告バナー(Google Ads・Meta Ads)は150KB以下推奨で表示速度が上がり、ROAS向上に寄与。動画サムネイル画像もWebP化でCTR改善報告あり。

企業サイト・ランディングページ

ヒーロー画像・スライダー画像の容量削減がCVRに直結。LP読了率・離脱率・フォーム到達率が数%〜10%改善する事例多数。Cloudflare Images・imgix等の画像CDNを利用すると、URLパラメータで動的リサイズ・形式変換が可能。

アプリ・SaaS開発

モバイルアプリの内部画像リソースはWebP採用でapk/ipa容量30〜50%削減。App Store・Google Playの200MB上限・モバイル通信ダウンロード制限(150MB)を回避しやすくなり、初回インストール率向上。

DTP・印刷入稿

印刷は非可逆圧縮NG。PNG・TIFF・PSDで350dpi以上を保持。Adobe Illustrator・InDesignからPDF/X-1a・PDF/X-4形式で入稿。Web用と印刷用で別ワークフロー管理が必須で、Adobe Bridge・Lightroomでの一括書き出しが標準運用。

画像最適化のベストプラクティス

1. 適切な解像度の選定

表示サイズの2倍(Retina対応)が上限。1080px幅を超える画像は99%のケースで過剰。ヒーロー画像1920px、商品写真1200px、サムネイル400pxが標準。

2. 形式の使い分け

写真=AVIF/WebP/JPEG、ロゴ・アイコン=SVG、UI・スクショ=PNG、単純図=PNG-8。<picture>要素で複数形式のフォールバック提供が推奨。

3. 品質設定の最適化

JPEG=Q75〜Q85、WebP=Q75〜Q85、AVIF=Q50〜Q65が実用範囲。Q95以上は容量増だけで視覚差なし。Squoosh・ImageOptim等のGUIツールで視覚比較しながら決定。

4. 遅延読み込み(Lazy Loading)

<img loading="lazy">属性で画面外画像の読み込み遅延。ファーストビュー画像はloading="eager" fetchpriority="high"で優先読み込み。全画像の80%以上に遅延読み込み適用が理想。

5. レスポンシブ画像(srcset)

<img srcset="img-400.webp 400w, img-800.webp 800w, img-1200.webp 1200w" sizes="(max-width:768px) 100vw, 50vw">で画面幅に応じた最適解像度配信。モバイルで小画像・PCで大画像の自動切替。

6. CDN + 自動最適化

Cloudflare Images・imgix・Cloudinary等の画像CDNは、URLパラメータで動的リサイズ・形式変換・品質調整が可能。オリジナル画像1点で全解像度・全形式を自動生成、ストレージ・運用コストを大幅削減。

7. ビルド時の自動変換

Next.js/Nuxt/Gatsby等のフレームワークは<Image>コンポーネントで自動WebP/AVIF変換・遅延読み込み・レスポンシブ対応を実装済み。手動最適化不要で開発生産性が上がります。

代表的な画像変換ツール

Squoosh(Google製Webアプリ)

ブラウザで動作するオープンソース。MozJPEG・WebP・AVIFエンコーダを比較しながら画質・容量を視覚調整。単一画像の詳細最適化に最適、URLは squoosh.app。

ImageOptim(Mac)・FileOptimizer(Windows)

複数の圧縮アルゴリズムを組み合わせ、ファイルドロップだけで一括最適化。可逆圧縮でメタデータ削除も自動化。個人ブロガー・デザイナーに定番。

Sharp(Node.js)・Pillow(Python)

プログラマ向けの高速画像処理ライブラリ。バッチ処理・自動化パイプラインに組み込み、CI/CDでビルド時変換が可能。大規模サイトの画像処理基盤。

ImageMagick / GraphicsMagick

コマンドラインの定番。magick input.png -quality 80 output.webpで一発変換。シェルスクリプトで一括処理、サーバーサイド標準ツール。

Cloudflare Images / imgix / Cloudinary

画像CDNサービス。オリジナル1枚アップロードで全解像度・全形式の動的配信が可能。月額$5〜、大規模サイトの運用コスト圧縮に効果的。

WordPressプラグイン(EWWW・Imagify・Smush)

アップロード時に自動変換・遅延読み込みも設定可能。無料枠あり、月間画像数に応じて有料プラン。管理画面からワンクリック一括変換で既存画像も対応。

フォーマット別の実装ノウハウ

picture要素の実装例

Webブラウザは<picture>要素内の<source>を上から評価し、対応可能な最初の形式を採用します。標準的な実装は以下の通り。

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="ヒーロー画像"
       width="1920" height="1080"
       loading="eager" fetchpriority="high">
</picture>

WordPressテーマでの自動化

WordPress 5.8以降でwp_filter_content_tags()によりloading="lazy"は自動付与<picture>要素はプラグイン(Jetpack Boost・Optimole・ShortPixel等)で自動生成。テーマ側でheroやサムネのマークアップを最適化すると効果最大。

Next.js/Nuxtの<Image>コンポーネント

フレームワーク組み込みのImage/nuxt-imgコンポーネントは、ビルド時にWebP/AVIF自動生成+srcset+lazy loading+placeholder blurまで一括対応。開発生産性が高く、モダンWeb開発の標準化アプローチ。

CDN側の変換パラメータ

Cloudflare Images・imgix・CloudinaryはURLパラメータで動的変換?width=800&format=webp&quality=80のように指定するだけで、オリジナル1枚から全解像度・全形式を配信可能。従来のビルド時変換より運用が柔軟です。

よくある間違い・注意点

  • PNGを写真に常用 — 写真はJPEG/WebP/AVIFの1/10容量。ロゴ・図表以外でPNGを使うのは容量無駄。Web最適化最優先の見直しポイント。
  • 過度な圧縮でブロックノイズ — JPEG Q50以下は視覚劣化明らか。商品写真・ヒーロー画像はQ75以上を確保、視覚品質と容量のバランスをSquooshで検証。
  • WebP変換だけでAVIF未対応 — 2026年時点でAVIFはJPEG比50%減の最強フォーマット。CDN・フレームワーク側で対応可能ならAVIF+WebPフォールバックが最適。
  • 表示サイズの3倍以上の解像度 — 400px表示に4000px画像を配信する例が散見される。CSSで縮小しても通信量は変わらない。srcsetで適正サイズ配信を。
  • ファーストビュー画像にlazy loading — LCP指標が悪化する誤設定。ヒーロー画像はloading="eager" fetchpriority="high"で優先読込。
  • EXIFメタデータ未削除 — スマホ撮影画像は位置情報・カメラ機種等のメタデータで数十KB増。ImageOptim等で自動削除。プライバシー面からもEXIF削除は必須。
  • SVGをラスタライズしてPNG化 — アイコン・ロゴはSVGのままの方が軽量・鮮明。Retinaディスプレイでも劣化ゼロ。SVG圧縮はSVGOで20〜50%削減可能。
  • alt属性未設定 — SEO・アクセシビリティ両面でNG。画像内容を的確に表現するalt文でGoogleへの意味理解・スクリーンリーダー対応を確保。

関連規格・法令

  • ISO/IEC 10918-1 JPEG ― 静止画像デジタル圧縮国際標準。DCT変換・量子化テーブルの規格定義。1994年制定、以降World Wide Web時代の写真標準。
  • ISO/IEC 15948 PNG ― Portable Network Graphics規格。可逆圧縮・アルファチャネル・カラー管理の国際標準。W3C勧告 (W3C Recommendation)。
  • W3C WebP規格 ― Googleが策定したVP8/VP9動画コーデック派生の静止画形式。W3C Community Group Reportとして公開。
  • ISO/IEC 23000-22 MIAF(AVIF基盤) ― AV1動画コーデックの静止画コンテナ規格。Alliance for Open Mediaが標準化。
  • W3C Web Vitals(LCP・INP・CLS) ― Webページのユーザー体験指標。Google検索ランキング要因。
  • WCAG 2.1(アクセシビリティ) ― alt属性・コントラスト比等のWebアクセシビリティ規格。JIS X 8341-3準拠。
  • 個人情報保護法・EXIF位置情報削除 ― 撮影画像の位置情報が個人特定に繋がる場合の削除義務。個人情報保護委員会ガイドライン。

参考文献・公的資料

※本ツールの容量推定は各フォーマットの典型的な圧縮率に基づく理論値で、実際の画像内容(写真・イラスト・図表)・色数・複雑度により実測値と数十%の差が生じます。厳密な容量管理・品質検証は、Squoosh・ImageOptim等の実ツールでの変換結果を基準としてください。Core Web Vitals・SEO順位への影響は、Google Search Console・PageSpeed Insights・Chrome UX Reportの実測データで継続的に検証することを推奨します。

よくある質問(FAQ)

1920×1080のWebP容量はどれくらい?

写真で約250〜500KB。同解像度のPNGは約2.5MB、JPEG Q80は約400KB。WebPはPNG比90%、JPEG比25〜35%の削減が期待できます。

WebPとAVIFはどちらを使うべき?

2026年時点では<picture>要素でAVIF → WebP → JPEGの順にフォールバック提供が最適解。AVIFは全主要ブラウザ対応済み、JPEG比50%減の最強フォーマット。

PNGを使うべきケースは?

①ロゴ・アイコン(SVG不可の場合)、②UI スクリーンショット、③透過が必要な画像、④単色・限定色数の図表。写真・グラデーション画像はPNG不適で、JPEG/WebP/AVIFに変換。

SVGをPNG化した方が軽い場合はある?

ほぼない。SVGはベクター形式で、Retinaディスプレイでも劣化せず容量数KBが多い。SVGO圧縮でさらに20〜50%削減可能。アイコン・ロゴはSVG一択が原則。

JPEG品質はいくつが最適?

Q75〜Q85が実用範囲。Q80が業界標準(画質と容量のバランス最良)、Q60はサムネ用、Q90以上は印刷用途で容量増だけで視覚差は小さい。Squooshで視覚比較して決定。

Core Web VitalsのLCP合格ラインは?

2.5秒以下がGood判定、2.5〜4秒がNeeds Improvement、4秒超がPoor。ヒーロー画像のWebP/AVIF変換だけで2〜3秒の改善が期待できます。

WordPressで簡単に一括変換する方法は?

プラグインのEWWW Image OptimizerImagifySmushが定番。管理画面からワンクリックで既存画像を一括変換、以降のアップロードも自動最適化。無料枠あり。

画像CDNを導入すべき規模は?

月間PV10万以上、または画像1000枚以上のサイトが目安。Cloudflare Imagesは月額$5、Cloudinaryは無料枠あり。オリジナル1枚アップロードで全解像度・全形式の動的配信が可能で運用コスト削減。

lazy loadingは全画像に付けていい?

NG。ファーストビュー画像(ヒーロー・LCP要素)に付けるとLCP指標が悪化。スクロールしないと見えない画像だけにloading="lazy"を付与、ヒーロー画像はloading="eager" fetchpriority="high"で優先読込。

EC商品画像の最適サイズは?

拡大表示用に1200px幅、通常表示800px、サムネイル400pxの3サイズをsrcsetで提供。JPEG Q80またはWebP Q80で1枚100〜200KB以下を目標。Amazon・楽天も同水準の運用。

HEIC(iPhone写真)はWebで使える?

Safari以外はまだ非対応で、Webでは非推奨。アップロード時にJPEG/WebPに変換する処理をサーバー側で実装するのが現実的。SharpやPillowで対応可能。

スクリーンショットの最適形式は?

PNGが第一選択(テキストのシャープさ保持)。ただし容量が大きい場合はWebP可逆モードで30%削減。ぼやけて構わないならJPEG Q90でも可。

広告バナー画像の推奨サイズは?

Google Ads・Meta Adsは150KB以下推奨。JPEG Q80または WebP Q80で余裕あり。GIFアニメーションはWebPアニメーション(.webp)に変換すると60〜80%削減。

画像最適化でSEOはどれくらい改善?

Core Web Vitals合格ラインをクリアするとGoogle検索順位の押上げ効果あり。特に競争激しい業界で数位〜十数位の改善事例多数。Search Consoleで「ページエクスペリエンス」レポートを継続監視。

Base64インライン画像は使うべき?

1KB以下の小さなアイコンのみ推奨。HTTP/2以降はリクエスト数のペナルティが少ないため、大画像のBase64化は容量33%増でメリット消失。SVGのインライン化は有効。

プログレッシブJPEGとベースラインの違いは?

プログレッシブは低解像度から段階的に表示、ベースラインは上から順に読込。プログレッシブは体感速度が向上し、モバイル環境で有利。MozJPEGのデフォルトはプログレッシブで、モダンWebでは推奨。

ダークモード対応の画像最適化は?

<picture>要素のmedia属性でprefers-color-schemeを分岐し、ライト/ダーク用に別画像を提供。ロゴ・アイコンはSVGのCSS変数で色制御が最も効率的です。

画像最適化の投資回収は?

ECサイトでは表示速度100ms改善でコンバージョン率1〜3%向上の実測データ多数。年商1億円のサイトなら年間100〜300万円の売上寄与。CDN・変換ツールへの投資は数か月で回収可能な高ROI施策です。

PWA・オフライン対応での画像戦略は?

Service Workerで画像をCache Storage経由キャッシュ、初回はネットワーク→2回目以降はキャッシュのstale-while-revalidate戦略が定番。WebP優先+JPEGフォールバックで、通信状況が悪くても軽量表示を維持。