LocalFlux
JA
無料試用を開始
メニュー
無料試用を開始
← ブログに戻る

WindowsでJPGをWebPにオフライン変換する方法

Windows 11でJPG写真をローカルにWebPへ変換し、実際の容量差を測定して、JPGフォールバック付きの軽量なWeb画像を公開する方法を説明します。

執筆 LocalFlux Editorial Team

生産性ヒント
LocalFluxで3件のWebサイト向けJPGからWebPへの変換が完了し、容量削減率が表示されている画面。
この記事の内容
  1. 最短手順
  2. JPGからWebPがWebサイトに役立つ理由
  3. 検証に使ったファイル
  4. 手順1：JPGを追加する
  5. 手順2：直接変換かWebサイト用テンプレートを選ぶ
  6. 手順3：実際のオプションを確認する
  7. 手順4：変換してコピーを確認する
  8. 測定結果
  9. WebPを正しく公開する
  10. メタデータとプライバシーは別の作業
  11. 制御を保ったバッチ変換
  12. JPGのままがよい場合
  13. よくある質問
  14. WebPを作り、測定してから公開する

大きな写真は、ほかの設計上の工夫が効く前にWebページを遅く感じさせます。JPGをWebPへ変換するとダウンロード量を減らせる場合がありますが、大切なのはWebPが新しい形式かどうかではありません。実際に小さくなったか、見た目を許容できるか、Webサイトから正しく配信されるかを確認することです。

Windows 11のLocalFluxでは、1件または複数のJPGを追加し、WebPを選んで、オンラインサービスへ送信せずに変換できます。Web公開向けの最初の試行にはWebsite imageテンプレートを使えます。検証したLocalFlux 1.0.7では、WebP、品質82、縦横比固定、長辺最大1920ピクセル、小さい画像は拡大しない、メタデータ削除はオフ、という設定でした。

LocalFluxで3件のJPGからWebPへの変換が完了し、削減率が表示されている。

Webサイト向けバッチはPC上で完了しました。3件のWebPは表示されたJPGより66%、67%、75%小さくなりました。この結果は今回の検証ファイルに限られ、一般的な保証ではありません。

適した用途: ランディングページ、記事、商品ページ、ポートフォリオなど、転送量が重要なWeb公開用JPG写真。

JPG原本は保存: WebP変換は別の非可逆エンコードです。JPGですでに失われたディテールは戻らず、編集元やフォールバックには原本が安全です。

最短手順

  1. Windows 11でLocalFluxを開きます。
  2. .jpgまたは.jpegを追加します。
  3. Convertを選んだまま、出力をWebPにします。
  4. Web公開用ならTemplates、Web & social、Website imageを選びます。
  5. 大量処理の前にサイズと品質を確認します。
  6. Convertを選びます。
  7. WebPを開き、細部をJPGと比較して実際のバイト数を測ります。
  8. 明示的な寸法を指定し、必要ならJPGフォールバックを付けて公開します。

Microsoft StoreでLocalFluxを入手するか、対応形式と変換経路を確認してください。

JPGからWebPがWebサイトに役立つ理由

画像リクエストは帯域を使い、ほかのページ資源と競合します。バイト数が少なければ、特に低速なスマートフォン回線で転送を短縮できます。ただし、拡張子の変更だけで高速になるわけではありません。エンコード結果、表示寸法、キャッシュ、レスポンシブ画像、優先度、ページ上の位置も影響します。

Googleの画像形式の選び方は、品質と容量の結果が適切ならWebPやAVIFのような形式を使い、必要に応じて旧形式も用意することを勧めています。Google画像SEOガイドも品質と速度を重視しており、WebPだけで検索順位が上がるとはしていません。

JPGと非可逆WebPはいずれも写真の配信用形式です。目的は、許容できる品質で小さな配信用コピーを作ることです。低品質JPGの修復ではありません。失われた微細な質感や輪郭のリンギングは、再エンコードしても復元できません。

次の3つの作業も分けて考えます。

目的適切な操作
ブラウザーへ配る形式を変えるJPGをWebPへ変換
過大なピクセル寸法を減らす実際に表示する最大寸法へ縮小
位置、端末、作者、日時情報を除く対応するメタデータ削除を使い、出力を検証

Website imageは最初の2つを控えめに組み合わせますが、Share safelyは有効にせず、目標バイト数も保証しません。

検証に使ったファイル

C:\tmp\LocalFluxJpgToWebPBlogに置いた、権利確認済みの3件のJPGを使いました。

写真では自然な質感とグラデーション、画面では小さな文字と硬い輪郭、プロモーション画像では広い単色面と微妙な階調を確認します。すべて不透明です。透過やグラフィックについてはPNGからWebPへのガイドを参照してください。

検証に使った3件の権利確認済みJPG。

写真、細かなUI、横長のヒーロー画像を含みます。中立的な作業パスとリポジトリ管理のメディアにより、個人アカウントや顧客資産は公開されません。

手順1：JPGを追加する

JPGをLocalFluxへドラッグするか、Add filesを選びます。各行がJPG → WebPになっていることを確認します。1つのバッチでは出力と画質設定を共有するため、必要寸法や品質が異なるファイルは分けてください。

WebPが選択され、3件のJPGがLocalFluxで待機している。

WebPはバッチに対して一度選びます。LocalFluxはJPGを置き換えず、隣に新しいコピーを書き出します。

初めて扱う画像群では、詳細な写真、ポートレートがあれば顔、グラデーション、文字やロゴを含む画像を先に試します。草木で問題のない品質でも、文字が柔らかくなりすぎることがあります。

手順2：直接変換かWebサイト用テンプレートを選ぶ

直接変換は寸法を維持したままWebPへ変え、既定の品質動作を使います。形式だけを変えた基準になります。

Website imageはWeb配信用プロファイルを適用します。Templates、Web & social、Website imageを開きます。検証版の設定は次のとおりです。

JPGバッチにWebsite imageテンプレートを適用したLocalFlux。

コマンドバーにWebsite imageが表示されます。Share safelyはオフのままで、これはWeb配信用テンプレートであり、自動的なプライバシー処理ではありません。

1920ピクセルは上限で、拡大指示ではありません。3件はいずれも上限以下だったため、寸法は変わりませんでした。直接変換よりさらに小さくなった理由は品質設定であり、リサイズではありません。

手順3：実際のオプションを確認する

Optionsを開き、Advanced adjustmentsを展開します。将来のすべての版でテンプレート名と実装が同じだと仮定せず、値を確認してください。

LocalFluxにWeb向け寸法、固定された縦横比、品質82%が表示されている。

1920 × 1080のヒーロー画像は同じ寸法を維持し、縦横比を固定して品質82を使います。小さい画像は拡大しません。

品質値は形式やツールをまたぐ共通尺度ではありません。あるエンコーダーの82が別の82と同じとは限らず、特定の容量も保証しません。この手順で再現できる開始値として扱い、結果を比較します。レイアウト上800ピクセル幅でしか表示しない画像なら、1920ピクセルはまだ大きすぎる可能性があります。実際の幅に合うレスポンシブ画像を作り、必要な高密度表示まで削りすぎないようにします。

手順4：変換してコピーを確認する

Convert 3 filesを選びます。LocalFluxは別名の.webpを作り、JPGを残します。ブラウザーで開き、100%表示でも次を確認します。

コンタクトシートだけで判断しないでください。ネイティブサイズでは、Webサイト用WebPの細部やUIが少し柔らかく見えます。非可逆の第2世代コピーだからです。配信用には妥当でも、JPGは原本またはフォールバックとして残します。

JPGとWebsite image WebPを容量とともに比較した画像。

3件とも寸法を維持し、大幅に小さくなりました。ピクセル同一や可逆変換を示す比較ではありません。

測定結果

直接変換とWebsite imageは、同じ3件とLocalFlux 1.0.7を使いました。

ファイルJPG入力直接WebP直接変化Web用WebPWeb用変化寸法
山の写真274,913バイト169,980バイト38.2%減92,448バイト66.4%減1440 × 960
LocalFlux UI126,755バイト64,626バイト49.0%減42,334バイト66.6%減1320 × 940
LocalFluxヒーロー67,861バイト28,880バイト57.4%減17,216バイト74.6%減1920 × 1080
合計469,529バイト263,486バイト43.9%減151,998バイト67.6%減該当なし

実際の山のJPG、直接WebP、Web用WebP、UIのJPG、直接WebP、Web用WebP、ヒーローJPG、直接WebP、Web用WebPを確認できます。

Webサイト用バッチは直接WebPバッチより合計42.3%小さくなりました。品質82がすべてのサイトに正しいという証明ではなく、品質の判断が形式選択と同じくらい重要だと示す結果です。

出力はすべて有効で不透明な静止WebPでした。山のJPGにはEXIFプロファイルがあり、直接出力とWeb用出力にも残りました。ほかの2件にはプロファイルがありませんでした。変換後も元JPGのSHA-256は一致しました。

結果は今回のファイルに固有です。最適化済みJPGでは削減量が小さい、変わらない、またはWebPのほうが大きくなる場合もあります。出力を測定し、コピーを増やす価値がなければ採用しないでください。

割合は元の容量と一緒に読む

割合には分母が必要です。小さなサムネイルの70%より、大きなヒーローの20%のほうが多くのバイトを節約することがあります。このバッチでは317,531バイト、転送前で約310KiBを削減しました。最大の元ファイルだった山の写真が、絶対量でも最大です。

ファイル容量と表示サイズも別です。1920 × 1080をCSS幅600ピクセルで表示しても、適切な候補がなければ全データを取得します。逆に小さい画像をCSSで拡大してもディテールは戻りません。元と出力のバイト数、公開URLを記録し、代表的なモバイル回線で確認してください。ローカル容量だけから一定の読み込み時間を主張することはできません。

WebPを正しく公開する

WebPの作成は作業の半分です。正しいマークアップ、安定した寸法、有用な代替テキスト、適切なフォールバック方針が必要です。<picture>要素はWebPと最後の<img>を用意できます。

<picture>
  <source srcset="mountain-photo.webp" type="image/webp">
  <img
    src="mountain-photo.jpg"
    width="1440"
    height="960"
    alt="夕暮れの山の草原"
    decoding="async">
</picture>

優先するWebPを先に、<img>を最後に置きます。widthとheightによりダウンロード前に縦横比が確保されます。CSSではレスポンシブ表示を維持できます。

img {
  max-width: 100%;
  height: auto;
}

複数の表示幅が必要なら、実体の異なる候補を作ってsrcsetとsizesを使います。同じ画像に複数の幅指定を付けないでください。ファーストビューより下ではloading="lazy"を使えますが、ヒーローやLCP候補を遅延させないでください。ブラウザーの遅延読み込みガイドも、最初に見える画像は早く読むよう勧めています。

サーバーがimage/webpを返すこと、バージョン付き資産を長期キャッシュすること、開発者ツールで本番応答を確認することも必要です。公開前に次を確認します。

メタデータとプライバシーは別の作業

WebP変換だけで写真が自動的に安全になるわけではありません。Share safelyがオフだったため、山の画像と2つのWebPにはEXIFプロファイルが残りました。位置、端末、作者、日時が問題になる場合は、対応する削除処理を使い、出力を確認してください。写真変換でEXIFは削除されるかも参照してください。

メタデータ削除で少し小さくなることはありますが、隠れた性能対策ではなく、明示的なプライバシー判断にします。法務、編集、アクセシビリティ、資産管理で必要な情報は残してください。

制御を保ったバッチ変換

  1. 代表的なファイルを先に試します。
  2. ヒーロー、記事画像、サムネイル、UI画面を必要寸法で分けます。
  3. バッチごとに適切な出力とサイズ方針を適用します。
  4. 最初の結果をネイティブサイズで比較します。
  5. 公開名を記録または自動化します。
  6. JPG原本を生成物フォルダーの外に保存します。

LocalFluxは準備済みの各行に1つの出力を書きます。壊れたファイルは個別に調べてください。大量の画像についてはWindowsで画像を一括圧縮する方法を参照してください。

JPGのままがよい場合

すでに十分小さい、送信先がWebP非対応、追加コピーの運用負担に見合わない場合はJPGを使い続けます。古いWebView、メールクライアント、取り込みシステム、後工程のツール向けにJPGが必要な場合もあります。

JPGからWebP、さらにJPGへ戻す編集サイクルは避けてください。非可逆変換を繰り返すと劣化が累積します。最良の原本を編集し、最後に配信用資産を生成します。ロゴ、アイコン、透過切り抜き、図には輪郭とアルファを保てる形式を使います。PNGからWebPとWebP互換性ガイドも参照してください。

よくある質問

WebPは常にJPGより小さくなりますか？

いいえ。今回の3件では小さくなりましたが、内容、元品質、出力品質、寸法、プロファイル、エンコーダーによって変わります。

JPGからWebPで画質は上がりますか？

いいえ。効率的な配信用コピーにはなっても、失われたディテールは復元せず、もう一度エンコードします。

Website imageは今回のファイルをリサイズしましたか？

いいえ。すべて長辺1920ピクセル以下で、1440 × 960、1320 × 940、1920 × 1080のままでした。

変換するとEXIFは削除されますか？

決めつけないでください。山のJPGと両方のWebPにEXIFプロファイルがあり、削除設定はオフでした。

元JPGは上書きされますか？

この手順では上書きされません。LocalFluxは新しいWebPを作り、元のハッシュも変わりませんでした。

すべてのWebサイトにJPGフォールバックが必要ですか？

必須ではありません。現在の主要ブラウザーはWebPを扱えますが、古いWebViewやブラウザー以外のシステムが対象なら<picture>で対応できます。

WebPだけでページは高速になりますか？

いいえ。適切なレスポンシブ寸法、明示的な寸法、効果的なキャッシュ、妥当な読み込み優先度も必要です。

WebPを作り、測定してから公開する

信頼できる流れは、JPGを保存し、ローカルでWebP配信用コピーを作り、ネイティブサイズで比較し、本番ページが正しい資産を返すことを確認することです。今回のWebsite imageバッチは、リサイズせず469,529バイトから151,998バイトになりました。測定値が根拠になり、原本の保存と正直な品質確認が安全性を支えます。

Microsoft StoreでLocalFluxを入手するか、対応形式を確認してください。