ある日、私は、私の React コードにレンダリング バグがあるため、クライアントのサイトが遅いという確信を持って午後を過ごしました。 コンポーネントをプロファイリングし、メモを取り、再レンダリングを追跡しました。 実際の問題は、背景のヒーロー画像でした。3.1 MB の JPEG は品質 100% で保存されました。80% の品質でまったく同じ画像が 480 KB で、同じように見えた場合です。 私はアプリを使いすぎて、アセットを十分に考えていませんでした。 これは、1 日を無駄にするための開発方法です。
それ以来、画像圧縮は私がチェックする最初のものであり、最後のものではありません。 It& #39; s もっとも誤解されている - " 品質を失うことなく圧縮" 逆説のように扱われる、いつ本当にit& #39; sは、ただどのレバーがデータを破棄し、どれがdoes& #39; tを知ることの問題です。 このガイドは私が使用するメンタルモデルで、出荷中に構築されています Toolz.dev とチューニング コア Web Vitals クライアント サイト: 圧縮が実際にどのように機能するか、非可逆と可逆をいつ使用するか、および特定の品質数値が常に勝利し続ける理由。
tl;dr: 使い 画像圧縮 ウェブ写真のための約80% の質で - that& #39; s ファイルが60 ″80% 縮まるスイートスポットとあなたはまだすることができます& #39; tは、通常のサイズでオリジナルからそれを圧縮します オリジナルから (JPEG を再圧縮しないでください)、そして常に リサイズする 圧縮前に寸法を表示します。 最大限の節約のために、 変換する 写真 to ウェブP まず.ブラウザーですべてが実行されます - アップロードされるものは何もありません.
画像を圧縮すると、実際に何が起きているのでしょうか?
デジタル画像は、ピクセルのグリッドで、それぞれが色を格納します。 生の画像が膨大なのはそのためです。 24 ビット カラーの 1920×1080 のイメージは次のとおりです。
1920 × 1080 × 3 bytes = 6,220,800 bytes ≈ 5.93 MB
1 枚の写真に対して約 6 メガバイト。 そのうちの 10 ページは、テキストが読み込まれる前に 60 MB のダウンロードになります。 圧縮は、それを生き残ることができるようにするために存在します。それは、根本的に異なる 2 つの方法のいずれかで実行されます。
ロスレス圧縮 データ内のパターンを見つけて、何も破棄せずによりコンパクトにエンコードします。 解凍された画像は、ピクセルごとのピクセルであり、元の画像と同じです。 ランレングス エンコーディングが「赤、赤、赤、赤」を「5 倍の赤」に折りたたむと、「5 倍の赤」に折りたたまれて、ランレングス エンコーディングが折りたたまれて、繰り返しパターンをショート コードに置き換えます。予測フィルタリングは、各ピクセルを予測値との差として格納するため、スムーズなグラデーションは、美しく圧縮される小さな数の長距離になります。 PNG、ロスレス WebP、ロスレス AVIF はすべてこのように機能します。
損失のある圧縮 視覚系が気付かないであろうデータを捨てることで、はるかに大きな節約を実現します - そして、それ& #39; s " よりも賢い; いくつかのピクセルを削除します。 " 画像を RGB から輝度プラス色モデルに変換し (目は色よりも明るさにはるかに敏感です)、明るさを鮮明に保ちながらカラー チャネルの解像度を低下させます。画像をブロックに分割し、それぞれを周波数係数に変換し、高周波の画像 (微妙なテクスチャとノイズ) をより少ない値に丸めます。その丸めステップである量子化は、データが実際に失われる場所です。 JPEG、非可逆 WebP、および非可逆 AVIF はすべて、このアークに従います。
The practical upshot: lossless is for images where every pixel is meaningful - logos, screenshots, diagrams, anything with crisp text.損失は写真や自然画像のためのもので、どこ" looks identical" matters far more than " is bit-for-bit 同一です"
品質設定は実際には何を意味するのでしょうか。
「品質 80%」は、何を買うのかわからないまま、人が設定する人数です。 これは、実際の表示サイズでの多くの前後の比較に基づいて、JPEG と Lossy WebP に使用するマップです。
100% (最大): 正しい選択はほとんどありません。 ファイルは、多くの場合、80% よりも 3 ～ 5 倍大きく、改善は見られません。 あの午後を無駄にするヒーローの画像はここに保存されました。
85 ～ 95% (高): 微妙なディテールが本当に重要な写真のポートフォリオや画像に。 90% の場合、100% ズームでもほとんどの視聴者にはアーティファクトが見えません。
75 ～ 85% (Web スイート スポット): 最大値より 60 ～ 70% 小さく、通常の表示サイズではアーティファクトは見えません。 これは、ほとんどすべての Web イメージが属する場所です。
50 ～ 75% (攻撃的): サイズが重要なサムネイルとプレビューの場合。 よく見ると、アーティファクトが滑らかなグラデーションと細かいテクスチャで表示され始めます。
50% 未満: 目に見えるブロック性と色のバンディング。 本当に優先度の低い画像やハード サイズの制約のために予約してください。
PNG does' には "quality" slider がありません。 it's はロスレスであるため、スライダーは別の方法で最適化されます。圧縮レベル (0 ～ 9) は、エンコード時間をより小さなファイルに交換し、6 は賢明なデフォルトです。画像が少数の色を使用する場合、色深度の削減は非常に役立ちます。24 ビットから 8 ビットにドロップされた 16 色のロゴは、目に見える変化がゼロになると劇的に縮小します。メタデータ - EXIF、カラー プロファイル、タイムスタンプの削除 - は、画像に影響を与えることのないバイトをトリミングします。
WebPは、Webのための私のデフォルトです: 品質で 80 それは同等の品質でJPEGよりも25 ~ 35% 小さく実行し、それはまた、PNGを約4 分の1 打ち負かすロスレスモードを実行します.AVIFはさらに強く圧縮します - 一般的にJPEGよりも50% +小さい - しかし、エンコードはより遅く、isn& #39; かなり普遍的にサポートされているので、私は単独でではなくWebPフォールバックでそれを提供します。
どのフォーマットに圧縮する必要がありますか?
フォーマットを選ぶのは圧縮戦の半分であり、決定はオプションによって見えるよりも簡単です。 これが、私が新しいチームメイトに渡す比較です。
| フォーマット | タイプ | 対。 JPEG サイズ | 透明度 | に最適 |
|---|---|---|---|---|
| jpeg | 不サンク | ベースライン | いやー | 電子メールでの写真、ユニバーサル フォールバック |
| png | ロスレス | 写真の方がはるかに大きい | はいって | スクリーンショット、ロゴ、テキスト、図 |
| ウェブP | 両方 | 25 ～ 35% 小さい | はいって | Web の写真とグラフィックのデフォルト |
| avif | 両方 | ~50% 小型 | はいって | WebP フォールバックを使用した最大節約 |
最も一般的なフォーマットの間違い - と I& #39; は、コードレビューで私が数えられるよりも何度もそれをキャッチしました - は、写真を PNG として保存しています。 PNG はロスレスであるため、PNG として保存された写真は、目に見える違いがない 85% 品質の JPEG と同じ写真よりも何倍も大きくなる可能性があります。 PNG は、自然な画像ではなく、ハードエッジとテキストを備えたグラフィックスのためのものです。写真には JPEG または WebP を使用すると、肥大化したページの大部分を取り戻すことができます。 & #39;s 重みは 1 回の変更で表示されます。
変換は、2 クリック ジョブです。 フォーマット変換。 私が実際に出荷するパターンでは、ブラウザーが交渉できるようにします。
<img src="photo-800.webp"
srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1600.webp 1600w"
sizes="(max-width: 600px) 400px, 800px"
alt="Description">
あれか srcset ブラウザにいくつかのサイズを渡して、デバイスに合うものをダウンロードできるようにします。これにより、電話機がデスクトップ イメージを取得することはありません。 適切なフォーマットと組み合わせると、高速サイトと遅いサイトの違いです。
Web 画像を圧縮する正しい順序は何ですか?
注文は、どのような設定よりも重要であり、それを誤解することは、ほとんどの「圧縮したが、それでも大きな不満」の背後にある静かな間違いです。 毎回シーケンス:
最初にサイズを変更します。 4000×3000 の画像を圧縮すると、800×600 で表示される画像が破棄されようとしているピクセルに対して労力を無駄にし、結果は必要以上に大きくなります。 リサイズする ディスプレイの寸法 (Retina の 2 倍) 前に コンプレッサーに触れる。 この 1 つを再注文すると、品質の調整よりも大きな画像の問題が修正されます。
2 番目に変換します。 を使用して写真を WebP (またはフォールバックのある AVIF) に移動します。 フォーマット変換。 より小さく、より適切な形式の画像を圧縮しています。
3 番目に圧縮します。 走る 画像圧縮 損失の多い Web 画像の場合は約 80% で、結果を判断します 実際の表示サイズで- 誰も Web ページをそのように表示しないため、400% にズームされません。
その具体的作るために、here' s the web-optimization pass I run on the real page: audit with Lighthouse to find the heavy images, resize each to its display size, convert to WebP, compress at 75 ~ 80%, then re-run Lighthouse to confirm.典型的な結果は、画像の総重量が50 ~ 80% オフになり、最大のコンテンツペイントの測定可能なジャンプです - これは、そもそも私をこの道全体に送り込んだ指標です。
サイズ変更、フォーマットの選択、背景の削除を圧縮と並べてより広範に見学するために、 イメージ ツール ガイド 完全なツールキットをカバーしています。
最もコストがかかる圧縮ミスはどれですか?
ほとんどの無駄なバイトと最も目に見える品質の損傷を考慮したエラーが、ほんの一握りです。 全部作ったよ。
再 -すでに圧縮された JPEG を圧縮します。 損失の多い圧縮の各ラウンドでは、古いアーティファクトが古いものの上に積み重なって、ダメージが累積的で永続的です。 常に圧縮する 元のソースから、そしてそれらの原本を保つ - それらからすべての圧縮された版を、決して前の圧縮されたコピーから生成しなさい。
写真に png を使用します。 上記で取り上げましたが、見つけたときの最大の 1 勝です。5 MB の PNG 写真は 500 KB の JPEG になり、目に見える違いはありません。
過圧縮。 JPEG を 30% に落とすと、目に見えるブロック性とバンディングのある小さなファイルが作成されます。 Web では 75 ～ 85% のままで、実際のサイズでテストして自分のフロアを見つけてください。
サイズ変更ステップをスキップします。 上記のように、サイズ変更前に圧縮すると、必要以上に大きく、品質も低いファイルが生成されます。
現代のフォーマットを無視します。 WebP が利用可能になったときに JPEG を提供すると、理由もなく、潜在的な節約額の 25 ～ 35% が残ります。
仕事を客観的にチェックしたい場合は、知覚指標が存在します。0.95 を超える SSIM は通常 " 視覚的にロスレス、" です。そして Google's Butteraugli のスコアは 1.0 未満であり、平均差は基本的に目に見えません。しかし、正直に言うと、日常業務では、オリジナルと圧縮バージョンを実際のサイズで並べて表示すると、計算のほぼすべてのことがわかります。
よくある質問
画質を損なわずに画像を圧縮するにはどうすればよいですか?
真のピクセルパーフェクトな可逆圧縮の場合は、PNGまたは可逆WebPを使用します。 " visually lossless" - no difference you can see - 80 ~ 90% の品質でJPEGまたはWebPを使用してください。 The 画像圧縮 ツールを使用すると、ダウンロード前に品質を設定し、オリジナルを圧縮バージョンと比較して、サイズが縮小する正確なポイントを見つけることができますが、画像はそのままに見えます。
なぜ 80% の品質がマジック ナンバーと見なされるのですか?
実際の表示サイズでの多くの前後のテストで、JPEG または WebP の品質が約 80% であると、ファイルが最大値から 60 ～ 70% 縮小しましたが、アーティファクトはピクセル ピーピングなしではまだ見えません。 より高くすると、多くのバイトを支払うと、誰も見ていない。はるかに低くなると、勾配がバンドに入り始めます。 これは、Web での使用に最適なバランスであるため、デフォルトであるのはそのためです。
2026 年の Web サイトに最適な画像形式は何ですか?
WebPは最良のデフォルトです - 効果的にユニバーサルブラウザのサポートでJPEGより約25 ~ 35% 小さく 最大限の節約のために、AでWebPフォールバックで提供されるAVIF (JPEGより約50% 小さく) を使用します <picture> 要素。 で変換する フォーマット変換。 本物のベクター アートは、ロゴをラスターとして圧縮するのではなく、SVG として保持します。
損失圧縮と損失のない圧縮の違いは何ですか?
ロスレス圧縮は、データを一切破棄せずに効率的にデータを並べ替えるため、結果は元のものと同じピクセル単位になります - PNG はこのように機能します。 ロス圧縮は、目に気づく可能性が低いデータを永久に削除し、はるかに高い節約を実現します - JPEG はこのように機能します。ロスレスは通常、10 ～ 40% の削減をもたらします。; ロッシーは通常、60 ～ 90% の削減をもたらします。テキストとグラフィックスにはロスレス、写真にはロスを使用します。
圧縮前または圧縮後に画像のサイズを変更する必要がありますか?
常に最初にサイズを変更します。大きな画像を圧縮してから縮小すると、サイズ変更によって破棄されるピクセルに圧縮労力が浪費され、本来よりも大きくて低品質のファイルが残ります。最初にディスプレイの寸法にサイズを変更し、次に小さい画像を圧縮します。この順序により、最小かつ最もクリーンな結果が得られます。
オンライン ツールで画像を圧縮しても安全ですか?
ほとんどのオンライン コンプレッサーは、自分のサーバーに画像をアップロードして処理します。これは、個人の写真やクライアントの作業に問題となります。 ザ・ 画像圧縮 Toolz.dev 上のツールは、canvas API を使用してブラウザー内で完全に実行されるため、画像がデバイスから離れることはありません。プライベートまたはプロプライエタリなものに安全です。
同じ画像を 2 回圧縮するのが悪い考えなのはなぜですか?
損失の多い圧縮は詳細を破棄し、それを2 回行うと2 回破棄します - 2 回目のパスでは、最初のパス& #39; sの上に新鮮なアーティファクトが追加され、そのどれもが戻ってこないので、すでに一度圧縮されたファイルを圧縮するのではなく、常にオリジナルを保持し、そこからすべての圧縮バージョンを生成する必要があります。
自分の画像が大きすぎるかどうかは、どうすればわかりますか?
Google Lighthouse または PageSpeed Insights をページに対して実行すると、どちらも、特大サイズの画像にフラグを立て、より良いサイズを提案します。 簡単な経験則: 1 つの画像が 200 KB を超える場合は、最適化する価値があります。ヒーローの画像は、最大のコンテンツを駆動するため、特にその下に収まるはずです。 サイズ変更-コンプレス ワークフローを通じて違反者にフィードし、再監査します。
画像を 200 KB や 1 MB などの特定のファイル サイズに圧縮するにはどうすればよいですか?
最初に表示寸法にサイズ変更し、目標をクリアするまで品質を下げます。80% から開始し、まだオーバーしている場合は 70%、60% を試してください。 ザ・ 画像圧縮 ツールは、スライダーを移動するときに出力サイズを表示するため、推測して再エクスポートするのではなく、スライダーを超えるのを確認できます。 フォーマットを WebP に切り替えると、通常、同じ品質設定でさらに 25 ～ 35% 購入できます。これは、多くの場合、それ自体で十分です。
画像を圧縮すると、解像度や寸法が低下しますか?
いいえ - 圧縮とリサイズは別々の操作です。 3000 x2000 の写真を圧縮すると、3000 x2000; は、いくつかの細かいディテールを犠牲にして、より少ないバイトを使用してそれらのピクセルを保存するだけです。ピクセルを少なくしたい場合は、that's リサイズ、および it's 通常、最も重量を節約する変更の両方をこの順序で行うと、6 MB のカメラ ファイルが 90 KB の Web 画像に変わります。
