CSSまたはHTMLにdata / base64として画像を埋め込む必要がありますか

サーバーでのリクエスト数を減らすために、いくつかの画像（PNGとSVG）をBASE64として直接cssに埋め込みました。（ビルドプロセスで自動化されています）

このような：

background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);

これは良い習慣ですか？これを回避する理由はありますか？データURLをサポートしていない主要なブラウザーはありますか？

おまけの質問：CSSとJSでもこれを行うのは理にかなっていますか？

これは良い習慣ですか？これを回避する理由はありますか？

これは、IEの互換性が問題ではなく、CSSスプライトのように一緒に使用される非常に小さなCSS画像に対してのみ通常は適切な方法であり、リクエストを保存することはキャッシュ可能性よりも重要です。

それにはいくつかの注目すべき欠点があります：

• IE6と7ではまったく機能しません。

• IE8では、サイズが最大32kのリソースでのみ機能します。これは、base64エンコード後に適用される制限です。つまり、32768文字以下です。

• リクエストを保存しますが、代わりにHTMLページを膨らませます！そして、画像をキャッシュ不可にします。それらは、含まれているページまたはスタイルシートが読み込まれるたびに読み込まれます。

• Base64エンコードでは、画像サイズが33％膨張します。

• gzip圧縮されたリソースで提供されている場合、data:画像はサーバーのリソースに大きな負担となるでしょう。従来、イメージは圧縮に非常にCPUを集中的に使用しており、サイズの縮小はほとんどありません。

ここでの一般的な回答は、一連の正当な理由から、これは必要ないことを示唆しているようです。ただし、これらはすべて最新のアプリの動作とビルドプロセスを無視しているようです。

フォルダーの画像をウォークスルーし、このフォルダーのすべての画像を含む単一のCSSを生成する単純なプロセスを設計することは不可能ではありません（実際には非常に簡単です）。

このCSSは完全にキャッシュされ、サーバーへのラウンドトリップを劇的に減らします。これは、@ MemeDeveloperが最大のパフォーマンスヒットの1つを正しく示唆していることです。

確かに、それはハックです。間違いない。スプライトと同じハックです。完全な世界では、これは必要ありません。それまでは、修正する必要があるものが次の場合は、可能なプラクティスです。

1. 簡単に「スプライト」できない複数の画像を含むページ。
2. サーバーへの往復は実際のボトルネックです（モバイルと考えてください）。
3. 速度（ミリ秒レベルまで）は、ユースケースにとって本当に重要です。
4. IE5とIE6を気にしないでください（必要に応じて、Webを進めたい場合）。

私の見解。

それは良い習慣ではありません。一部のブラウザーは、データURI（例：IE 6および7）をサポートしていないか、サポートが制限されています（例：IE8の場合は32KB）。

データURIの欠点の詳細については、このWikipediaの記事も参照してください。

• データURIスキーム

短所

• データURIは、含まれているドキュメント（CSSファイルやHTMLファイルなど）とは別にキャッシュされないため、含まれているドキュメントが再ダウンロードされるたびにデータがダウンロードされます。
• 変更が加えられるたびに、コンテンツを再エンコードして再埋め込みする必要があります。
• バージョン7までのInternet Explorer（2011年1月現在、市場の約15％）にはサポートがありません。
• Internet Explorer 8では、データURIを最大長の32 KBに制限しています。
• データは単純なストリームとして含まれ、多くの処理環境（Webブラウザーなど）はコンテナー（multipart/alternativeまたはなどmessage/rfc822）の使用をサポートしていないため、メタデータ、データ圧縮、コンテンツネゴシエーションなどの複雑さを提供できません。
• Base64でエンコードされたデータURIのサイズは、同等のバイナリのURIの1/3です。（ただし、HTTPサーバーがgzipを使用して応答を圧縮する場合、このオーバーヘッドは2〜3％に削減されます）
• データURIは、セキュリティソフトウェアがコンテンツをフィルタリングすることをより困難にします。

私は約1か月間data-uriを使用していましたが、スタイルシートが非常に巨大になったため、使用を中止しました。

Data-uriはIE6 / 7で機能します（これらのブラウザーにmhtmlファイルを提供する必要があるだけです）。

data-uriを使用して得られた1つの利点は、スタイルシートがダウンロードされるとすぐにレンダリングされる私のバックグラウンドイメージです。

このテクニックを利用できるのは良いことですが、今後はあまり使いません。ぜひ試してみることをお勧めします。

CSSスプライトを使用して画像を結合し、リクエストに応じて保存したいと思います。私はbase64テクニックを試したことはありませんが、IE6とIE7では動作しないようです。もちろん、画像が変更された場合は、CSSファイルが複数ある場合を除いて、失われた画像全体を再配信する必要があります。

私は一般的なベストプラクティスについては知りませんが、私がそれを助けることができれば、そのようなことを見たくありません。:)

Webブラウザーとサーバーには組み込みのキャッシュ機能がたくさんあるので、サーバーにクライアントに画像ファイルをキャッシュするように指示することをお勧めします。ページに非常に小さな画像を大量にロードしているのでなければ、複数のリクエストによるオーバーヘッドがそれほど大きな問題になるとは思いませんでした。ブラウザーは通常、同じ接続を使用して多くのファイルを要求するため、新しいネットワーク接続は確立されないため、HTTPヘッダーを介したトラフィックの量が画像ファイルのサイズに比べて重要でない限り、複数の要求はあまり気にしません。 。

現時点でサーバーへのリクエストが多すぎると思う理由はありますか？

Webアプリケーションの一般的なアイコンなど、非常に頻繁に使用される小さな画像に使用することをお勧めします。

• ちなみに、Base64エンコーディングではサイズが大きくなるため
• 初期ロード時間を長くすることが正当化されるため、よく使用されます。

もちろん、古いブラウザでのサポートの問題に留意する必要があります。また、フレームワークの機能を使用して、GWTのClientBundleなどのデータURLの画像を自動的にインライン化するか、少なくとも要素のスタイルに直接追加するのではなく、CSSクラスを使用することをお勧めします。

より多くの情報がここに集められます：http : //davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/