Have questions about images on the web? Tweet your questions to @ChromiumDev with #AskChrome and we'll answer the top questions in our next #AskChrome episode on YouTube.

画像の最適化

ウェブページ上のダウンロード容量の大半を画像が占めることはよくあり、表示スペースのかなりの部分を画像が占有することも少なくありません。 そのため、画像を最適化することでウェブサイトの容量の大幅な削減とパフォーマンスの改善につながることがよくあります。ブラウザでダウンロードする必要がある容量が少ないほど、クライアントの帯域幅における競合は減り、ブラウザで有効なコンテンツをダウンロードして画面に表示するまでの時間も短縮されます。

画像の最適化は芸術でもあり科学でもあります。つまり、個々の画像を最も適切に圧縮する方法について明白な正解がないという点では芸術であり、画像のサイズを大幅に削減できる非常に高度な技術やアルゴリズムがたくさんあるという点では科学なのです。 画像に合った最適な設定を見つけるには、フォーマット機能、エンコード データのコンテンツ、画質、ピクセル数など、多くの観点で入念な分析が必要です。

画像の除去と置換

TL;DR

  • 不要な画像リソースを除外します
  • 可能な場合は CSS3 エフェクトを利用します
  • 画像にテキストをエンコードせず、ウェブフォントを使います

最初に検討すべきことは、必要な効果を出すために画像が本当に必要かどうかということです。 優れたデザインとは、シンプルであると同時に常に最高のパフォーマンスを発揮するものです。 画像は HTML、CSS、JavaScript などページ上の他のアセットと比べて大きな容量を占めることが多いため、画像リソースを省くことができれば、必ず最高の最適化戦略になります。 一方、画像を適切に使用すれば、数千文字を費やすより多くの情報を伝えることもできます。そのバランスをどう取るかはウェブ デベロッパー次第です。

次に、別の技術を使って、目的とする結果をもっと効率よく出力できないかを検討します。

  • CSS エフェクト(グラデーション、シャドウなど)や CSS アニメーションを使えば、解像度やズームのレベルにかかわらず、常に鮮明に表示される、解像度に依存しないアセットを、通常、画像ファイルに必要な容量の何分の 1 かで生成できます。
  • ウェブフォントを使用すると、美しい書体を利用できるだけでなく、テキストの選択、検索、サイズ変更の機能も維持されるため、ユーザビリティが大幅に向上します。

活かし画像アセットにエンコード テキストを含めている場合は、一旦立ち止まって再検討してください。 優れたタイポグラフィーは良いデザイン、ブランディング、読みやすさという点では重要ですが、画像内テキストはユーザー エクスペリエンスを低下させます。テキストの選択、検索、ズーム、アクセスができないうえ、DPI の大きい端末にも適していません。 ウェブフォントを使うには独自の最適化が必要ですが、これはテキストを表示するための最適な手法であり、上述の懸念はすべて解消されます。

ベクター画像と ラスター画像

TL;DR

  • 幾何学的図形で構成された画像にはベクター画像が最適です
  • ベクター画像はズームや解像度の影響を受けません
  • ふぞろいな形や細部の多い複雑なシーンにはラスター画像を使用する必要があります

目的のエフェクトを実現するために画像を使うのが最適であると判明したら、次の重要な選択は、適切な画像形式を選ぶことです。

ズームされたベクター画像
ズームされたベクター画像
ズームされたラスター画像
ズームされたラスター画像

形式ごとに、それぞれ長所と短所があります。 ベクター形式は、単純な幾何学的図形で構成される画像(ロゴ、テキスト、アイコンなど)に最適です。解像度とズームの設定にかかわらず鮮明に結果が表示されるため、高解像度画面やさまざまなサイズで表示する必要があるアセットに理想的な形式です。

ただし、ベクター形式は、シーンが複雑な場合(写真など)には適していません。すべての形状を表現するには SVG マークアップの量が極めて多くなることがあり、それでも「写真と変わらないリアルさ」で出力できないことがあります。 このような場合は、GIF、PNG、JPEG などのラスター画像形式や、JPEG-XR、WebP などの最新の形式のいずれかを使用することをおすすめします。

ラスター画像には、ベクター画像のように解像度やズームを問わないという便利な特性はありません。ラスター画像を拡大すると、ギザギザしてぼやけたグラフィックになります。 そのため、ユーザーに最適なエクスペリエンスを提供するには、さまざまな解像度のラスター画像を複数バージョン保存しなければならないことがあります。

高解像度画面の影響

TL;DR

  • 高解像度画面では 1 つの CSS ピクセルに複数のデバイス ピクセルが対応します
  • 高解像度画像では、必要なピクセル数とバイト数が膨大になります
  • 画像最適化テクニックは解像度にかかわらず同じです

画像のピクセルについて議論するときは、ピクセルの種別、すなわち CSS ピクセルとデバイス ピクセルを区別する必要があります。 1 つの CSS ピクセルには複数のデバイス ピクセルが含まれていることがあります。たとえば、1 つの CSS ピクセルがそのまま 1 つのデバイス ピクセルに対応することもあれば、複数のデバイス ピクセルに対応していることもあります。 ここで重要なのは、デバイス ピクセルの数が多いほど、画面上のコンテンツが詳細まで鮮明に表示されるという点です。

CSS ピクセルとデバイス ピクセル

高 DPI(HiDPI)画面では美しい出力を得られる一方で、明白な代償が 1 つあります。デバイス ピクセルの数が多いという利点を活かすためには、精細な画像アセットが必要です。 幸い、ベクター画像は解像度にかかわらず鮮明にレンダリングできるため、この処理に最適です。より詳細にレンダリングするうえで処理コストが高くなることはあっても、ベースとなるアセットは同じであり、解像度に依存しません。

一方、ラスター画像では、ピクセル単位で画像データをエンコードするため、非常に厄介な問題が生じます。 つまり、ピクセルの数が多いほど、ラスター画像のファイルサイズも大きくなるのです。 一例として、100 x 100(CSS)ピクセルで表示される写真アセットで違いを見てみましょう。

画面解像度 合計ピクセル数 未圧縮ファイルサイズ(ピクセルあたり 4 バイト)
1x 100 x 100 = 10,000 40,000 バイト
2x 100 x 100 x 4 = 40,000 160,000 バイト
3x 100 x 100 x 9 = 90,000 360,000 バイト

物理的な画面の解像度を 2 倍にすると、合計ピクセル数は 4 倍になります。水平方向のピクセル数 x 2 に垂直方向のピクセル数 x 2 を乗算するためです。 したがって、「2x」画面で必要なピクセル数はそのまま 2 倍になるのではなく、4 倍になります。

これは、現実的にはどのような意味を持つでしょうか。高解像度画面では美しい画像を提供できるため、製品の大きな売りになります。 ただし、高解像度画面には高解像度画像も必要です。ベクター画像は解像度に依存せず、常に鮮明な結果が出力されるので、可能な限りベクター画像の利用をおすすめします。ラスター画像が必要な場合は、srcset および picture を利用して、画像ごとに複数のバージョンを提供して最適化します。

ベクター画像の最適化

TL;DR

  • SVG は XML ベースの画像形式です
  • サイズを削減するには SVG ファイルを縮小する必要があります
  • SVG ファイルは GZIP で圧縮する必要があります

最新のブラウザはすべて Scalable Vector Graphics(SVG)をサポートしています。これは、2 次元グラフィック用の XML ベースの画像形式です。SVG マークアップをページに直接埋め込むことも、外部リソースとして使用することもできます。 そして、SVG ファイルの作成はほとんどのベクターベースの描画ソフトウェアで可能です。また、任意のテキスト エディタで直接手作業で作成することもできます。

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator:Adobe Illustrator 17.1.0, SVG Export Plug-In . SVG Version:6.00 Build 0)  -->
<svg version="1.2" baseProfile="tiny" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
   x="0px" y="0px" viewBox="0 0 612 792" xml:space="preserve">
<g id="XMLID_1_">
  <g>
    <circle fill="red" stroke="black" stroke-width="2" stroke-miterlimit="10" cx="50" cy="50" r="40"/>
  </g>
</g>
</svg>

上記の例では、シンプルな円形が黒の輪郭線に赤い背景でレンダリングされます。これは Adobe Illustrator からエクスポートされたものです。 おわかりのように、このファイルには、レイヤ情報、コメント、XML 名前空間など、ブラウザでアセットをレンダリングする際には必要ない多くのメタデータが含まれています。 このため、svgo などのツールを使って SVG ファイルを縮小化することが常に推奨されます。

たとえば、svgo を使用すると、Illustrator で生成された上記の SVG ファイルはサイズが 58% 縮小されて、470 バイトから 199 バイトになります。 さらに、SVG は XML ベースの形式なので、GZIP 圧縮を適用して転送サイズを縮小することもできます。サーバーが SVG アセットを圧縮するように設定されていることを確認してください。

ラスター画像の最適化

TL;DR

  • ラスター画像はピクセルのグリッドです
  • ピクセルごとにカラー情報と透過度情報をエンコードします
  • 画像圧縮ツールでは、さまざまな技術でピクセルあたりの必要ビット数を削減して画像のファイルサイズを縮小します

ラスター画像は、単純に個々の「ピクセル」で構成された 2 次元グリッドです。たとえば、100 x 100 ピクセルの画像は 10,000 個のピクセルが並んだものです。 そして、各ピクセルには「RGBA」値が格納されています。(R)は赤、(G)は緑、(B)は青、(A)はアルファ(透明度)のチャンネルです。

内部処理で、ブラウザはチャンネルごとに 256 の値(シェード)を割り当てます。これは、チャンネルあたり 8 ビット(2^8 = 256)、ピクセルあたり 4 バイト(4 チャンネル x 8 ビット = 32 ビット = 4 バイト)になります。 そのため、グリッドの寸法がわかれば、ファイルサイズを簡単に計算できます。

  • 100 x 100 ピクセルの画像は 10,000 ピクセルで構成される
  • 10,000 ピクセル x 4 バイト= 40,000 バイト
  • 40,000 バイト / 1024 = 39 KB

注: 余談になりますが、サーバーからクライアントにデータを転送するときの画像形式によらず、画像をブラウザでデコードする場合はピクセルごとにメモリが必ず 4 バイト使用されます。 これは、画像が大きい場合や、メモリの空き容量が少ない端末(低価格のモバイル端末など)の場合に、重大な制約になるおそれがあります。

寸法 ピクセル数 ファイルサイズ
100 x 100 10,000 39 KB
200 x 200 40,000 156 KB
300 x 300 90,000 351 KB
500 x 500 250,000 977 KB
800 x 800 640,000 2500 KB

100 x 100 ピクセルの画像で 39 KB であればたいしたことはないと思えるかもしれませんが、画像が大きくなるとファイルサイズは急激に肥大化し、画像アセットのダウンロードに時間も通信コストもかかるようになります。 幸い、これまでの説明は「未圧縮」の画像形式についてです。 では、画像ファイルのサイズを縮小するにはどうしたらよいでしょうか。

シンプルな戦略の 1 つは、画像の「ビット深度」をチャンネルあたり 8 ビットからさらに小さいカラーパレットに縮小することです。チャンネルあたり 8 ビットでは、1 つのチャンネルに 256 の値が割り当てられ、合計で 16,777,216(256 ^ 3)色になります。 パレットを 256 色に減らすとどうなるでしょうか。RGB チャンネルには合計 8 ビットのみで済むため、ピクセルあたり即座に 2 バイト削減できます。つまり、元のピクセルあたり 4 バイトの形式からすると 50% の圧縮となります。

圧縮による画像の乱れ

注: 左から右に(PNG): 32 ビット(1,600 万色)、7 ビット(128 色)、5 ビット(32 色)。 徐々に色が変わる複雑なシーン(グラデーション、空など)では、5 ビット アセットの場合に空にピクセルが出現するなど、圧縮による画像の乱れを避けるためには大きいカラーパレットが必要です。 逆に、限られた色しか使用していない画像に大きいパレットを使うと、貴重な容量を浪費することになります。

ここまでは個々のピクセルに格納されているデータの最適化を行いましたが、次は少し高度な内容に移り、隣接するピクセルについて考えてみましょう。空や、繰り返しのテクスチャなど、多くの画像(特に写真)では隣接するピクセルの色が似ていることがわかります。 この情報を有効に活用すれば、圧縮ツールは「差分符号化」を適用でき、ピクセルごとに値を保存するのではなく、隣接するピクセルとの差分を保存できます。隣接するピクセルが同じであれば、差分は「ゼロ」で、1 ビットを保存するだけで済みます。しかし、これで終わりではありません。

人間の目の感度は色ごとに異なっています。色のパレットを増減することにより、感度の違いを考慮して色のエンコードを最適化することができます。 「隣接する」ピクセルは 2 次元のグリッドを構成します。つまり、各ピクセルには複数の隣接ピクセルがあります。この点を活かして差分エンコードをさらに改善できます。 直接隣接するピクセルのみに注目するのではなく、隣接するピクセルで構成されたより大きなブロックに注目し、それぞれのブロックを異なる設定でエンコードします。 他にもさまざまな技術があります。

このように、画像の最適化はすぐに込み入った話になり(これが楽しい人もあるでしょう)、学問や商用の研究が活発に行われている分野です。 画像が占める容量は大きいため、優れた画像圧縮技術の開発には大きな価値があります。興味のある方は、Wikipedia のページをご覧ください。また、実践例については、WebP 圧縮技術に関するホワイトペーパーをご覧ください。

繰り返しになりますが、どの方法も優れている反面、非常に学術的です。これらは、ページ上の画像を最適化するうえで、どのように役立つのでしょうか。新しい圧縮技術を発明する立場にはなくても、問題の全体像を理解することは重要です。つまり RGBA ピクセル、ビット深度、さまざまな最適化技法などの理解です。 各種ラスター画像形式の詳細な説明に入る前に、こうした概念をすべて理解し、留意することが大切です。

可逆画像圧縮と非可逆画像圧縮

TL;DR

  • 人間の目の仕組み上、画像は非可逆圧縮の有力候補です
  • 画像最適化は、非可逆圧縮および可逆圧縮の一種です
  • 画像形式の違いとは、画像を最適化するために非可逆アルゴリズムと可逆アルゴリズムのどちらをどう使うかの違いです
  • すべての画像に合った最適な形式や「画質の設定」は存在しません。特定の圧縮ツールと画像コンテンツの組み合わせに応じて、固有の出力が生成されます

ページのソースコードや実行可能ファイルなど、特定の種類のデータの場合は、圧縮しても元の情報が変わらず、失われないことが大切です。データが 1 ビットでも損失したり間違っていたりすると、ファイルの中味の意味がまったく変わり、もっと悪ければ、完全に壊れてしまうこともあります。 一方で画像、音声、動画など、その他のデータの場合は、元のデータの表現と「ほぼ」合っていればまったく問題ありません。

実際、人間の目の仕組み上、画像のファイルサイズを縮小するために各ピクセルの情報を一部省いてしまっても、通常はまったく差し支えがありません。たとえば、人間の目は色によって感度が異なるため、色によってはわずかなビット数でエンコードできます。 そのため、通常の画像最適化パイプラインは次の 2 つの大きな手順で構成されます。

  1. 一部のピクセルデータを除去する「非可逆」フィルタで画像を処理する
  2. ピクセルデータを圧縮する「可逆」フィルタで画像を処理する

1 つ目の手順は省略可能です。具体的なアルゴリズムは特定の画像形式によって異なりますが、重要なのは、どの画像も非可逆圧縮手順を実施してサイズを圧縮できる点を理解することです。実際、GIF、PNG、JPEG など、さまざまな画像形式の違いは、非可逆手順と可逆手順を適用する際に使う(または省略する)具体的なアルゴリズムの組み合わせによるものです。

では、非可逆最適化と可逆最適化の「最適な」設定とはどのようなものでしょうか。その答えは、画像のコンテンツや、ファイルサイズと非可逆圧縮による画像の乱れのバランスをどう取るのかといった独自の基準によって異なります。非可逆最適化を省略し、複雑な細かい点まで厳密に表現する必要がある場合もあれば、非可逆最適化を積極的に適用して画像アセットのファイルサイズを縮小する場合もあります。 つまり独自の判断と状況によるため、いつでも使える万能の設定はありません。

ウェブ用に保存

実践的な例をあげると、JPEG などの非可逆形式を扱う場合、一般的に圧縮ツールではカスタマイズ可能な「画質」設定が用意されています(Adobe Photoshop の「Save for Web」機能で表示される画質スライダなど)。通常は、1~100 の値で、非可逆アルゴリズムと可逆アルゴリズムの固有の組み合わせである内部処理を制御します。 最良の結果を得るには、画像でさまざまな画質の設定を試し、思い切って画質を下げてみましょう。多くの場合、表示される結果は非常に良好で、ファイルサイズも大幅に削減されます。

注: 異なる画像形式の画質レベルは、画像のエンコードに使用するアルゴリズムが違いうため、単純に比較することはできません。画質 90 の JPEG と画質 90 の WebP では、生成される結果は大きく異なります。 実際、画像形式と画質レベルが同じでも、圧縮ツールの実装に応じて表示結果が異なることがあります。

適切な画像形式の選択

TL;DR

  • 最初に適切な汎用の形式(GIF、PNG、JPEG)を選択します
  • 各形式において、画質やパレットサイズなどの最適な設定を探して選択します
  • 最新のクライアント向けに WebP アセットや JPEG XR アセットを追加することを検討してください

さまざまな非可逆圧縮アルゴリズムと可逆圧縮アルゴリズムに加えて、画像形式に応じて、アニメーション、透明度(アルファ)チャンネルなど、異なる機能がサポートされています。 そのため、特定の画像の「適切な形式」を選択するとは、希望どおりの結果が表示され、しかも機能要件を満たす形式を選択する、ということになります。

形式 透明度 アニメーション ブラウザ
GIF 対応 対応 すべて
PNG 対応 非対応 すべて
JPEG 非対応 非対応 すべて
JPEG XR 対応 対応 IE
WebP 対応 対応 Chrome、Opera、Android

幅広くサポートされている画像形式は、GIF、PNG、JPEG の 3 つです。 これらの形式の他に、WebP、JPEG XR などの新しい形式にも対応しているブラウザもあります。最新の形式では、全体的な圧縮率が向上し、機能の数も増えています。 それでは、どの形式を使用すべきでしょうか。

ウェブ用に保存

  1. アニメーションが必要ですか。その場合、一般的な選択肢は GIF のみです。
    • GIF ではカラーパレットが最大で 256 色に制限されるため、ほとんどの画像にとって魅力のない選択肢となります。 さらに、パレットが小さい画像の場合は PNG-8 のほうが高圧縮率になります。 このため、GIF はアニメーションが必要な場合に限り適切な選択肢です。
  2. 最高解像度で精細さを維持する必要がありますか。その場合、PNG を使用します。
    • PNG では、カラーパレットのサイズ選択以外は、非可逆圧縮アルゴリズムは適用されません。 このため、最高画質の画像が出力されますが、他の形式よりもファイルサイズが著しく大きくなるという代償も伴います。 そのため慎重に使用してください。
    • 画像アセットに幾何学的図形で構成された画像が含まれている場合は、ベクター(SVG)形式に変換することを検討してください。
    • 画像アセットにテキストが含まれている場合は、再検討してください。 画像内のテキストは、選択も、検索も、「ズーム」もできません。 カスタマイズした外観を(ブランディングなどの理由で)出力する必要がある場合は、代わりにウェブフォントを使用してください。
  3. 写真、スクリーンショット、または同様の画像アセットを最適化していますか。その場合、JPEG を使用します。
    • JPEG では、非可逆最適化と可逆最適化を組み合わせて画像アセットのファイルサイズを削減します。 JPEG の画質レベルをいくつか試して、アセットに合った最適な画質と ファイルサイズのバランスを見つけてください。

最後に、アセットごとの最適な画像形式と設定を決定したら、WebP や JPEG XR でエンコードした別バージョンを追加することを検討してください。 この 2 つの形式はどちらも新しいため、残念ながら(まだ)すべてのブラウザで広くサポートされているわけではありませんが、新しいクライアントであれば大幅なサイズ削減を実現できます。たとえば、WebP では、同等の JPEG 画像よりも平均でファイルサイズを 30% 縮小できます。

WebP も JPEG XR も幅広くサポートされてはいないため、アプリケーションやサーバーに別のロジックを追加して適切なリソースを提供する必要があります。

  • 一部の CDN では、JPEG XR や WebP の配信を含め、画像の最適化をサービスとして提供しています。
  • 一部のオープンソースのツール(Apache 向けまたは Nginx 向けの PageSpeed など)を使用して、適切なアセットの最適化、変換、提供を自動化できます。
  • アプリケーション ロジックを追加して、クライアントを検出し、クライアントでサポートしている形式を確認することで、利用できる最適な形式で画像を提供できます。

最後になりますが、Webview を使ってネイティブ アプリケーションでコンテンツをレンダリングすると、クライアントを完全に制御できるため、WebP を使うだけで済みます。Facebook、Google+ など多くのサービスでは WebP を使って画像をすべてアプリケーション内で配信しています。削減される容量は、この労力に完全に見合っています。 WebP の詳細については、2013 年度 Google I/O の WebP: Deploying Faster, Smaller, and More Beautiful Images のプレゼンテーションをご覧ください。

ツールとパラメータの調整

すべての画像に当てはまる完璧な画像形式、ツール、最適化パラメータのセットはありません。 最良の結果を得るには、画像のコンテンツ、画像の表示要件とその他の技術要件に応じて、形式や設定を選ぶ必要があります。

ツール 説明
gifsicle GIF 画像を作成して最適化
jpegtran JPEG 画像を最適化
optipng 可逆 PNG 最適化
pngquant 非可逆 PNG 最適化

各圧縮ツールのパラメータを思い切って試してみましょう。 画質レベルを下げ、表示を確認し、調整する作業を繰り返してください。 適切な設定の組み合わせが見つかったら、サイト上にある他の同様の画像に適用できます。ただし、すべての画像を同じ設定で圧縮しなければならないわけではありません。

スケーリングした画像アセットの配信

TL;DR

  • スケーリングしたアセットを配信することは、最も単純で最も効果的な最適化の 1 つです
  • オーバーヘッドが大きくなるので、大容量のアセットには十分注意してください
  • 表示サイズに合わせて画像の倍率を変更することで不要なピクセルの数を削減します

画像の最適化は次の 2 つの基準に要約できます。各画像ピクセルをエンコードするために使うバイト数の最適化と、合計ピクセル数の最適化です。画像のファイルサイズは、合計ピクセル数と、各ピクセルをエンコードするために使うバイト数を乗算した値に過ぎません。 実に単純です。

サイズ変更された画像

このため、最もシンプルで最も効果的な画像の最適化技法の 1 つは、目的のサイズでアセットをブラウザに表示するのに必要とされる数を超えるピクセルを送信しないようにすることです。 これは簡単に聞こえるかもしれません。しかし、残念ながら大部分のページは画像アセットが多く、この基準を満たしていません。通常は、大容量のアセットを配信し、ブラウザにアセットの拡大縮小を委ね(これは、CPU リソースの無駄使いにもつながります)、解像度を下げて表示しています。

注: Chrome DevTools で画像要素にカーソルを合わせると、画像アセットの「実」サイズと「表示」サイズの両方が表示されます。 上記の例では、300 x 260 ピクセルの画像がダウンロードされていますが、表示されるときはクライアント上でサイズが(245 x 212 ピクセルに)縮小されています。

不要なピクセルを配信して、ブラウザだけに画像のサイズ変更をまかせることによるオーバーヘッドは、ページのレンダリングに必要な合計バイト数を削減して最適化するという大きなチャンスを逃したことを意味します。 さらにサイズ変更は、画像を縮小した後のピクセル数だけでなく、画像の実サイズにも依存します。

画面解像度 実サイズ 表示サイズ(CSS ピクセル) 不要ピクセル数
1x 110 x 110 100 x 100 110 x 110 - 100 x 100 = 2100
1x 410 x 410 400 x 400 410 x 410 - 400 x 400 = 8100
1x 810 x 810 800 x 800 810 x 810 - 800 x 800 = 16100
2x 220 x 220 100 x 100 220 x 220 - (2 x 100) x (2 x 100) = 8400
2x 820 x 820 400 x 400 820 x 820 - (2 x 400) x (2 x 400) = 32400
2x 1620 x 1620 800 x 800 1620 x 1620 - (2 x 800) x (2 x 800) = 64400

上記のすべてのケースで、表示サイズは各画面解像度に対して必要なアセットより「10 CSS ピクセル小さいだけ」です。 ただし、画像の表示寸法が大きくなるほど、余分なピクセル数と、それに伴うオーバーヘッドは著しく増大します。このため、すべてのアセットを正確な表示サイズで配信することはできないかもしれませんが、不要なピクセルの数を最小限に抑え、特に大きいアセットは表示サイズにできる限り近づけて配信するよう心掛ける必要があります。

画像最適化チェックリスト

画像の最適化は芸術でもあり科学でもあります。つまり、個々の画像を最も適切に圧縮する方法について明白な正解がないという点では芸術であり、画像のサイズを大幅に削減するために役立つ非常に高度な技術やアルゴリズムがあるという点では科学なのです。

以下に、画像の最適化に取り組むうえで留意すべきおすすめの方法やテクニックを紹介します。

  • ベクター形式を優先する: ベクター画像は解像度やスケールに依存しないため、複数端末、高解像度の環境に最適です。
  • SVG アセットを縮小して圧縮する: ほとんどの描画アプリケーションでは、多くの場合、削除可能な不要なメタデータを含んだ XML マークアップを生成します。SVG アセットの GZIP 圧縮を適用するようにサーバーが設定されていることを確認してください。
  • 最適なラスター画像形式を選ぶ: 機能要件を判別し、それぞれの特定のアセットに適した形式を選択してください。
  • ラスター形式に最適な画質設定を試す: 思い切って「画質」設定のレベルを下げましょう。多くの場合、結果は非常に良好で、バイト数も大幅に削減されます。
  • 不要な画像メタデータを削除する: 多くのラスター画像には、地理情報、カメラ情報など、アセットに関する不要なメタデータが含まれています。 適切なツールを使用してこのデータを取り除いてください。
  • スケーリングした画像を提供する: サーバー上の画像のサイズを変更し、「表示」サイズを画像の「実」サイズにできるだけ近づけることを心掛けてください。 大きい画像はサイズ変更に伴うオーバーヘッドの大半を占めているため、特に注意してください。
  • 自動化を徹底する: 自動化されたツールやインフラストラクチャに予算をかけ、画像アセットのすべてが必ず最適化されるようにしてください。

フィードバック

Was this page helpful?
Yes
What was the best thing about this page?
It helped me complete my goal(s)
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had the information I needed
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had accurate information
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was easy to read
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
Something else
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
No
What was the worst thing about this page?
It didn't help me complete my goal(s)
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was missing information I needed
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had inaccurate information
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was hard to read
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
Something else
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.