背景画像のデータをBase64としてCSSに埋め込むことは良い習慣ですか、それとも悪い習慣ですか？

私はgreasemonkeyのユーザースクリプトのソースを見ていたところ、CSSに次のことがわかりました。

.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}

greasemonkeyスクリプトは、サーバー上でホストするのではなく、ソース内で可能なすべてのものをバンドルすることを望んでいることを理解できます。しかし、このテクニックを以前に見たことがなかったので、その使用を検討しましたが、いくつかの理由で魅力的であると思われます。

1. ページ読み込み時のHTTPリクエストの量を減らし、パフォーマンスを向上させます
2. CDNがない場合は、画像とともに送信されるCookieによって生成されるトラフィックの量が減少します
3. CSSファイルをキャッシュできます
4. CSSファイルはGZIPPEDできます

IE6（例えば）が背景画像のキャッシュに問題があることを考えると、これは最悪の考えではないようです...

それで、これは良い習慣か悪い習慣ですか、なぜそれを使用せず、画像をbase64エンコードするためにどのツールを使用するのですか？

更新-テストの結果

• 画像でテスト：http://fragged.org/dev/map-shot.jpg - 133.6Kb

• テストURL：http : //fragged.org/dev/base64.html

• 専用のCSSファイル： http://fragged.org/dev/base64.css - 178.1Kb

• GZIPエンコーディングサーバー側

• クライアントに送信される結果のサイズ（YSLOWコンポーネントテスト）：59.3Kb

• クライアントブラウザに送信されたデータの保存：74.3Kb

いいですが、小さい画像にはあまり役に立たないと思います。

更新：Googleのソフトウェアエンジニア、ブライアンマクエードは、PageSpeedに取り組んでおり、ChromeDevSummit 2013で、CSSのdata：urisは、講演中にクリティカル/最小限のCSSを提供するためのレンダリングブロッキングアンチパターンと見なされると述べました#perfmatters: Instant mobile web apps。http://developer.chrome.com/devsum​​mit/sessionsを参照してください。実際のスライド

画像とスタイル情報を別々にキャッシュしたい場合はお勧めできません。また、大きな画像または大量の画像をcssファイルにエンコードする場合、ブラウザーがファイルをダウンロードするのに時間がかかり、ダウンロードが完了するまで、スタイル情報なしでサイトを離れます。小さな画像の場合は、頻繁に変更するつもりはないが、それでも良い解決策です。

base64エンコーディングを生成する限り：

• http://b64.io/
• http://www.motobit.com/util/base64-decoder-encoder.asp（アップロード）
• http://www.greywyvern.com/code/php/binary2base64（下に小さなチュートリアルがあるリンクから）

この回答は古くなっているため、使用しないでください。

1）2017年のモバイルの平均レイテンシははるかに高速です。https：//opensignal.com/reports/2016/02/usa/state-of-the-mobile-network

2）HTTP2マルチプレックス https://http2.github.io/faq/#why-is-http2-multiplexed

「データURI」は、モバイルサイトでは必ず検討する必要があります。セルラーネットワーク経由のHTTPアクセスでは、リクエスト/レスポンスあたりのレイテンシが高くなります。そのため、CSSまたはHTMLテンプレートへのデータとしての画像のジャムがモバイルWebアプリで有益な場合があるいくつかの使用例があります。使用状況はケースバイケースで測定する必要があります-データURIをモバイルWebアプリのあらゆる場所で使用する必要があるとは主張していません。

モバイルブラウザでは、キャッシュできるファイルの合計サイズに制限があることに注意してください。iOS 3.2の制限はかなり低い（ファイルあたり25K）が、新しいバージョンのMobile Safariでは大きく（100K）なっている。したがって、データURIを含める場合は、ファイルの合計サイズに注意してください。

http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

その画像を1度だけ参照しても、CSSファイルに埋め込む問題は発生しません。ただし、複数の画像を使用するか、CSSで複数回参照する必要がある場合は、代わりに単一の画像マップを使用して、単一の画像を切り取ることができます（CSSスプライトを参照）。

私が提案することの1つは、2つの個別のスタイルシートを用意することです。1つは通常のスタイル定義を使用し、もう1つはbase64エンコーディングで画像を含むものです。

もちろん、画像スタイルシートの前にベーススタイルシートを含める必要があります。

このようにして、通常のスタイルシートがダウンロードされ、ドキュメントにできるだけ早く適用されることを保証すると同時に、httpリクエストの削減や、データURIがもたらすその他のメリットから利益を得ます。

Base64はGZipped後の画像サイズに約10％を追加しますが、モバイルに関してはそれを上回る利点があります。レスポンシブWebデザインには全体的な傾向があるため、強くお勧めします。

W3Cはモバイルにもこのアプローチを推奨しており、レールでアセットパイプラインを使用する場合、これはCSSを圧縮するときのデフォルトの機能です

http://www.w3.org/TR/mwabp/#bp-conserve-css-images

非エディトリアル画像用に個別のCSSファイルを作成するという推奨に同意しません。

画像がUIの目的であると仮定すると、それはプレゼンテーションレイヤーのスタイリングです。前述のように、モバイルUIを実行している場合は、すべてのスタイリングを1つのファイルに保持して一度にキャッシュできるようにすることをお勧めします。

私の場合、関連する画像は既に内部に埋め込まれているため、コピーすることを心配することなく、CSSスタイルシートを適用できます。

CSS / HTMLアナライザーツールのオンラインコンセプトを作成してみました。

http://www.motobit.com/util/base64/css-images-to-base64.asp

できる：

• HTML / CSSファイルをダウンロードして解析し、href / src / url要素を抽出します
• URLの圧縮（gzip）とサイズデータを検出する
• 元のデータサイズ、base64データサイズ、gzip圧縮されたbase64データサイズを比較する
• URL（画像、フォント、cssなど）をbase64データURIスキームに変換します。
• データURIによって回避できる要求の数を数える

コメント/提案は大歓迎です。

アントニン

あなたはそれをPHPでエンコードすることができます:)

<img src="data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>">

Or display in our dynamic CSS.php file:

background: url("data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>");

1 That’s sort of a “quick-n-dirty” technique but it works. Here is another encoding method using fopen() instead of file_get_contents():

<?php // convert image to dataURL
$img_source = "feed-icon.gif"; // image path/name
$img_binary = fread(fopen($img_source, "r"), filesize($img_source));
$img_string = base64_encode($img_binary);
?>

ソース

Sublime Text 2のユーザーのために少し持っていくと、STに画像をロードするbase64コードを提供するプラグインがあります。

Image2base64と呼ばれる： https //github.com/tm-minty/sublime-text-2-image2base64

PS：ファイルを上書きして破壊するため、プラグインによって生成されたこのファイルを保存しないでください。

ここに情報をありがとう。私はこの埋め込みが便利で、特にモバイルで特に埋め込み画像のcssファイルがキャッシュされている場合に便利です。

私のファイルエディタはこれをネイティブで処理しないため、作業を簡単にするために、ラップトップ/デスクトップの編集作業用の簡単なスクリプトをいくつか作成しました。私はphpをそのまま使用しているのは、これらの処理を直接かつ非常にうまく行っているからです。

Windows 8.1の下で言う---

C:\Users\`your user name`\AppData\Roaming\Microsoft\Windows\SendTo

...管理者として、パスにバッチファイルへのショートカットを設定できます。そのバッチファイルは、php（cli）スクリプトを呼び出します。

次に、ファイルエクスプローラーで画像を右クリックし、バッチファイルを送信します。

Admiinstartorリクエストに同意し、黒いコマンドシェルウィンドウが閉じるまで待ちます。

次に、クリップボードの結果をテキストエディターに貼り付けるだけです...

<img src="|">

または

 `background-image : url("|")` 

以下は他のOSにも対応できるはずです。

バッチファイル...

rem @echo 0ff
rem Puts 64 encoded version of a file on clipboard
php c:\utils\php\make64Encode.php %1

パスにphp.exeを使用すると、php（cli）スクリプトが呼び出されます...

<?php 

function putClipboard($text){
 // Windows 8.1 workaround ...

  file_put_contents("output.txt", $text);

  exec("  clip < output.txt");

}


// somewhat based on http://perishablepress.com/php-encode-decode-data-urls/
// convert image to dataURL

$img_source = $argv[1]; // image path/name
$img_binary = fread(fopen($img_source, "r"), filesize($img_source));
$img_string = base64_encode($img_binary);

$finfo = finfo_open(FILEINFO_MIME_TYPE); 
$dataType = finfo_file($finfo, $img_source); 


$build = "data:" . $dataType . ";base64," . $img_string; 

putClipboard(trim($build));

?>

私が調査した限りでは

使用：1. svgスプライトを使用している場合。2.画像​​のサイズが小さい場合（最大200MB）。

使用しないでください：1.大きい画像の場合。2. svgとしてのアイコン。それらはすでに良好であり、圧縮後にgzipされているため。