web-dev-qa-db-ja.com

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

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

このような：

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

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

ボーナス質問：CSSとJSに対してもこれを行うのは理にかなっていますか？

htmlcssbase64
129
meo

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

IEの互換性が問題にならない場合（CSSスプライトなど）一緒に使用される非常に小さなCSSイメージの場合のみ、通常は良い習慣であり、リクエストの保存はキャッシュ可能性よりも重要です。

注目すべき欠点がいくつかあります。

  • IE6および7ではまったく機能しません。

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

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

  • Base64エンコードは、画像サイズを33％増大させます。

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

154
Pekka 웃

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

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

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

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

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

私の見解。

34
JAR.JAR.beans

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

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

欠点

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

Data-uriを1か月ほど使用していましたが、スタイルシートが非常に巨大になったため、使用をやめました。

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

Data-uriを使用して得られた1つの利点は、スタイルシートがダウンロードされるとすぐにレンダリングされる背景画像であり、そうでない場合は徐々にロードされることです

この手法を利用できるのは嬉しいことですが、今後はあまり使いません。試してみることをお勧めします

9
stephenmurdoch

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

3
Steve Claridge

一般的なベストプラクティスについてはわかりませんが、手助けできるなら、そのようなものを見たくありません。 :)

Webブラウザーとサーバーにはキャッシュが大量に組み込まれているため、サーバーにクライアントに画像ファイルをキャッシュするように指示するのが最善策だと思っていたでしょう。ページ上に非常に小さな画像がたくさんある場合を除き、複数のリクエストのオーバーヘッドがそれほど大きなものだとは思いませんでした。ブラウザは通常、同じ接続を使用して大量のファイルを要求するため、新しいネットワーク接続は確立されないため、HTTPヘッダーを介したトラフィックの量が画像ファイルのサイズと比較して大きくない限り、複数の要求をあまり心配しません。

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

2
Chris

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

  • 小さい、Base64エンコードによりサイズが増加するため
  • 多くの場合、これはより長い初期ロード時間を正当化するため

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

詳細はここに集められます： http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/

0
Sebastian