背景画像のデータをBase64としてCSSに埋め込むことは良い習慣ですか、それとも悪い習慣ですか？
私はgreasemonkeyのユーザースクリプトのソースを見ていたところ、CSSに次のことがわかりました。 .even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom} greasemonkeyスクリプトは、サーバー上でホストするのではなく、ソース内で可能なすべてのものをバンドルすることを望んでいることを理解できます。しかし、このテクニックを以前に見たことがなかったので、その使用を検討しましたが、いくつかの理由で魅力的であると思われます。 ページ読み込み時のHTTPリクエストの量を減らし、パフォーマンスを向上させます CDNがない場合は、画像とともに送信されるCookieによって生成されるトラフィックの量が減少します CSSファイルをキャッシュできます 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/devsummit/sessionsを参照してください。実際のスライド