最近、著者がbackgroud-imageにSVGを使用することを推奨している記事が増えています。 実際、SVGの使用には大きなメリットがあります。 ブラウザで毎回ラスターを再描画する必要があるため、すべての記事で非常に簡単にSVGレンダリングのパフォーマンスが言及されていますが、これはより高価な操作です。
そして、ある晴れた日、1つのWebアプリケーションを開いたときに、ブラウザが狂ってメモリを「食い尽くしている」ことに気付きました。1つのタブは約600 MiBを「食べました」。 MacBookでは、網膜はさらに悪化しました。 その瞬間から、メモリが流れる場所で調査が始まりました。 誰も気にしない、猫へようこそ。
私が最初に気づいたのは、1つのポップアップを開いたときのメモリの増加でした。アイコンでは20個の要素しか描画されませんでした。 クロムでプロファイルを作成したので、私はそれがjavaScript、CSS、HTMLのいずれにもないと結論付けました。
しかし、アイコンのある要素が少ないほど、消費されるメモリが少ないことに気付きました。 アイコンがどこから来たのかを見た後、私はそれらが2000px x 500pxのスプライトから取られているのを見ました。 SVGスプライトを同じサイズのPNGスプライトに置き換えた後、奇跡が起こりました-メモリ使用量が妥当な制限に戻りました。 推論すると、小さなアイコンごとに大きなビットマップが描画され、メモリに費やされたという結論に達するのは簡単です。
私が思いついた最初の考えは、SVGを放棄することでした。 ただし、高解像度モニターを使用しているユーザーのことを考えているため、これを受け取ってpngに置き換えることはできません。
SVG 仕様とさまざまな記事（記事の最後にあるリンク）を読んだ後、pxではなくemでSVGサイズを設定することにしました。 その結果、予想通り、相対単位で、消費されるメモリの量はpngスプライトが使用された場合とほぼ同じであることが判明しました。
以下の表は、16個のアイコンをレンダリングするときの、マシン上のクロムのメモリ消費量を示しています。
| SVG、寸法はemで与えられます | 9 216k | デモ |
| SVG、寸法はpxで与えられます | 101 600k | デモ |
| PNG、小さいキャンバスサイズ | 7 748k | デモ |
| PNG、大きなキャンバスサイズ | 10 060k | デモ |
SVGについて読むことをお勧めする記事のリスト：
coding.smashingmagazine.com/2012/01/16/resolution-independence-with-svg
habrahabr.ru/post/141654
www.broken-links.com/2012/08/14/better-svg-sprites-with-fragment-identifiers
www.w3.org/TR/SVG
smus.com/canvas-vs-svg-performance
UPD ：それで、一般的な研究の過程で、そのような動作はクロムベースのブラウザに存在することがわかりました。 ブラウザでは、Firefox、オペラ、つまり同様の効果は見られません。 コメントは、メモリの量が測定単位ではなくキャンバスのサイズに依存することを正しく示しています。 ただし、測定単位はSVGのスケーラビリティに影響する可能性があるため、タスクの単位を選択してください。 他のブラウザで実行されたコメントとテストに感謝します。
UPD ： code.google.com/p/chromium/issues/detail?id=196524はバグ追跡システムにバグを追加しました。
UPD ：バグはクローズされ、カナリアビルドで修正されました。