※例によって個人調べなので，多分に間違いが含まれているものと思われます…
2014/3/4 ちょっと改訂
序
昨今webブラウザ上でベクタグラフィックを描くことができることからsvgが脚光を浴びるようになりました．現状ではそれほど利用率が高くないものの，今後様々な用途で広く使われていくことが予想されます．
さて，このように非常に便利なsvgですが，大抵はjpgやpng形式などのラスタ形式と比較することで紹介されることも多く，svgを単なるベクタ画像形式の一つと理解されている方も多かろうと思います．しかし見方を変えるとそれ以上に多くの考慮すべき点が浮かび上がってきます．
プログラム言語としてのsvg
html5においてsvgに似た機能を提供するものとしてcanvas要素があります．canvas要素にはグラフィックを描くためのapiが定められており，これをスクリプトから操作することでグラフィックを描きます．
一方のsvgでは「画家のモデル」と呼ばれる方法でグラフィクを描いていきます．つまりxmlツリーとして記述されたグラフィックの描画指示を上から順に実行し，目的のグラフィックを得ているのです．
まとめると，次のようになります．
- canvas要素…javascriptの文法を使ってグラフィックを描く
- svg…xmlの文法を使ってグラフィックを描く
つまり，canvas要素もsvgも基本的には同じものとも言えるのです．実際svgにもjavascriptのfunctionに相当する仕組みはdefs-use要素として用意されていますから，ちょっと乱暴ですがsvgを画像プログラム（スクリプト）言語と言ってもそれほどおかしくないのです．
※確かに事前に提供されているapiの差から得意とする分野は別れますが．
※話はずれますが，canvas要素でもsvgのような動作を実現することは可能です．
※この類推から得られる結論としては次のようなものが挙げられます．
- svg文書はソースコードであり，環境毎にコンパイルすると最適なラスタ画像が得られる．
- svgをjavascriptで操作するというのは「ソースコードをマクロプログラムで自動生成している」ということである
良いsvg・悪いsvg
さてsvgにプログラム言語的な側面があることが判ったら，次の事を考えてみましょう．
一般にプログラムというものは何らかの目的を果たすために作られるものです．ですがその実現には様々な方法が考えれます．
※「html文書を表示する」と言った目的に対し，firefoxやchromeといった様々な選択肢がるといったようにです．
すると，自ずと「良いプログラム」「悪いプログラム」と言ったものが見えてきます．何れも同じ目的を果たせるのですが，実際にそれを使う場面（ユースケース）に応じて優劣が発生するのです．例えば軽い・重い，判りやすい・判りにくい，使いやすい・使いにくい等．
※いわゆる非機能要件ってやつです．
例えばsvgでドット絵を表現する例で言えば，
- 1画素に1rect要素を割り当てる
- 1色に1path要素を割り当てる
svgをwebで利用する上での「良いsvg」とは
では今後需要が高まると予想される「web上でsvgを使う」という場合においては，どのようなsvgが求められるのでしょうか？何より次の点が挙げられるでしょう．
- 動作が軽快なsvg
webブラウザがsvgファイルを読み込むと，その内容に従ってグラフィックを描いていきます．要はプログラムが実行されるわけですが，いかな素晴らしいグラフィックであるとしても，その処理に時間が掛かるようでは意味は無いでしょう．
また，無駄な処理が多ければそれだけ無駄に電力を消費します．モバイル機器が主流となりつつある今，「あのサイトを開いていると，なんだかわからないけれどもりもりバッテリー残量が減っていく」と言った悪評判がたてばビジネスチャンスを逃す結果となりかねません．
つまり，svgの節度ある活用が今後web上でsvgを利用する際のエチケットとして定着することが有り得るわけです．
※この問題はsvg(1.1)が必ずしもweb上でのみ動作しうるものとして設計されたわけでないことに起因しています．（流石にユースケースとしては想定していたと思われますが）
svg2以降ではhtml5と連携しうることを前提に，より使いやすいものとなっていくことでしょう．
svgのパフォーマンスチューニングの勘所
では軽快なsvgとするにはどうすればよいのでしょう？
以下筆者の経験です．いずれもsvgを画像ファイルと捉えただけでは気付きにくいものばかりです．
※いずれも通常の利用においては意識せずともよいのですが，svgを仕組みを知ると無闇に使いたくなるものです．ですから，svgを作成する際はこれらの注意点を念頭に置いて危ないなと感じたら引き返す余裕を持ちましょう．
※もちろん，きちんとした目的がある場合はこの限りではありませんが，単なる静的なアイコン・ロゴの表示に大きな負荷が掛かってしまうのはいかにも無駄と感じざるを得ません．
※先頭ほど注意すべきもので，下に行くほど優先度は低くなります．
・要素数を極力減らす
大雑把には1要素1手順と言ってよいです．従ってこの数が増えるほど処理時間が増えていきます．それ以外にもsvgファイルの増大によるネットワークトラフィックへの負荷，dom展開の手間を考えるとできるだけ要素の数は減らしたほうが良いと言えます．従って，同様の設定が為されているrectやcircle要素等が多数存在するのであれば，単一のpath要素に複合パスとしてまとめることが出来ないか検討しましょう．
また過剰な演出はそれだけで多量の要素を消費することになります．svgでは出来る限り見た目にもコード的にもシンプルな方が望ましいと言えます．
※とは言え，2〜3個の要素であればそれほど問題はありません．むしろ，グラフデータや地図データ等の外部リソースからsvgを自動生成した際に，細切れの要素が大量に作られてしまうケースに有効なテクニックです．
※極論すればillustratorやinkscapeが悲鳴を上げるようなベクタ画像がwebブラウザで使えるわけがないのです．
・コンテナ要素の利用を減らす
コンテナ要素とはsvg,g,use,marker,clipPath,mask要素等を指します．これらは大元のsvg要素が生成するメインカンバスの他に暗黙のカンバスを生成するため，その分処理が増加します．とりわけmarker要素はマーカーの描画毎に処理が発生するため，見た目の要素数以上に処理速度を低下させます．svgを手書きする際は，これらの要素を過剰に使わないように注意し，場合によっては先ほどと同様に単一のpathで置き換えられないか検討します．
※もちろん，web以外の用途（例えばpng画像自動生成のソースコードとしての利用）であればむしろコードのメンテナンス性が優先されますからガンガン使って良いです．
・過剰な画像フィルタを掛けない
filter要素による画像処理はラスタライズ後のグラフィックに対してピクセル操作を施すことに他なりません．従って過剰な原始フィルタの掛けあわせは厳に控えるべきです．また大きな画像にフィルタを掛ける行為は絶大なパフォーマンス低下を招きます．※巨大なcanvas要素が重いのと同様です．
※どうしてもその効果が必要であれば事前にpng画像としてラスタライズしておき，image要素から読み込ませるようにします．
・パスの複雑度を下げる
webでsvgを使う場合，それほど高精細なデータは必要無いはずです．従って過剰に頂点を持つpathを定義するより，見た目でわからない程度に頂点を減らしたり，3次ベジェ曲線を2次ベジェ曲線や直線で近似するようにしてパス文字列をシンプルにしましょう．また頂点座標の小数点桁数を減らすことでもsvgファイルサイズを抑える事が出来ます．
※画像を拡大可能とする場合には適しません．
・viewBox範囲外に画像要素を配置しない
描画されない要素は無駄と言えます．処理上必要な場合であっても「display:none」として描画処理をスキップさせるようにしましょう．※svgをパンさせて描画範囲を移動させるようなケースではこの限りではありません．が，工夫次第で処理速度を向上させることが出来るとも言えます．
・アニメーションを行わない
(smil/dom/css)アニメーションは必要以上にsvgの再描画を発生させる原因となります．出来ることなら静的なグラフィックとしましょう．※一度描画したら，極力触らないのが鉄則です．
・一部をラスタ画像に置き換える
全てをベクタデータとして描くのではなく，image要素を使って一部をラスタ画像に置き換えます．多量の要素があるということはそれだけ細かい画像と言えるため，ラスタ画像に置き換えても見た目上問題は起こり難い筈です．xlink:href属性にdataスキーム形式で画像を埋め込んでしまえば（ファイルサイズこそ増大しますが） 単一のsvgファイルとして扱うことが出来ます．※svg2では待望のcanvas要素をsvg内部で直接扱えるようになります．従ってグラフィックの役割毎に処理を切り替えると言った使い分けが容易となるでしょう．
・style要素によるスタイルの指定を控える
セレクタによる暗黙のスタイル設定処理が発生するため，処理速度に影響します．特に擬似クラス等のtree構造に関わるものは利用しないほうが良いでしょう．※なおstyle要素を使うことでsvgファイルのサイズが小さくなるケースもあるため，一概にこうすべきというわけではありません．
・ディスプレイに表示される画像のサイズを小さくする
いかなsvgとは言え，無闇に大きな領域を専有するのは処理速度に影響します．また，画像サイズを小さくすることで副次的にパスの簡略化が行えるようになります．※svgのwidth，height属性と言ったものは本質的に意味はなく，結局のところどの位のサイズのカンバスにグラフィックが描画されるかが重要となります．ですが，実用上それほど意識する必要はないかも知れません．
・余計なデータを削除する
inkscapeやillustratorなどを使ってsvgを生成した場合，webブラウザでは必要のない情報（メタデータ）が多数含まれています．dom展開処理に影響するため予めコードから削除しておきましょう．※なお，注釈やタイトル等のsvgのアクセシビリティに関わる要素・属性はsvgがxmlであることの利便性を損なう可能性があるため削除しないほうが良いでしょう．
・buffered-rendering属性を活用する
http://www.w3.org/TR/2014/WD-SVG2-20140211/painting.html#BufferedRendering次期svg2ではbufferd-rendering属性を使ってグラフィックの描画内容をキャッシュさせることが可能となります．現状では本プロパティをサポートする環境がpresto(旧opera,現operaはblink)のみと，使い勝手が悪いですが，将来を見据えて今からこっそりと記述しておくのも悪くありません．
・DOMのパフォーマンスチューニングテクニックも併用する
javascriptと組み合わせる場合，一般的なhtmlやxmlで行われている高速化テクニックはsvgにおいても有効です． 代表的なものとしては，- ノードの検索にはより具体的な条件を付ける（getElementByIdを使う）
- ノードの検索結果はキャッシュして使いまわす
- ノードの生成にはcreateElementNSよりcloneNodeを用いる
- ノードの廃棄は最小限に止め，出来ることなら再利用する
- ノードの一括追加にはdocumentFragmentオブジェクトを使う
- getAttribute，setAttributeよりも専用のapiがあればそちらを使う．(hrefプロパティ等)
- style等のアクティブオブジェクトは内部でキャッシュして使いまわす
※プログラミングの経験者の方であれば，svgの仕様書を読んで自分ならどう組むかを考えてみて下さい．難しそうだな，面倒だなと思った部分は大抵処理が重い部分です．
※コードを短くするのが目的というのであればこちらも参考になるかと．
Advent Calendar 3日目:SVG画像を1バイトでも削るためのコードゴルフ
http://d.hatena.ne.jp/rikuo/20131203
もうひとつの解決策
上記の対策を行うとなるとどうしても画像がシンプルとなりがちです．そうは行っても豪華なグラフィックを使いたい！というのであれば次の方法が考えられます．
・canvas要素を使ってsvgをラスタライズしブラウザにキャッシュさせる
現行のブラウザであればまずcanvas要素をサポートしているはずなので，ここにsvgの内容を（img要素を使って）描画し，その処理結果をブラウザにキャッシュさせるのです．html5のweb strage機能を使えば何とかなる気がします．※あくまで理屈上です．仕組みは考えねばなりません．
・思い切ってsvgの利用を諦める（身も蓋もねー）
予めsvgをpng画像に変換しておくのです．そんなの面倒！と思われるかも知れませんが，事前のpng変換処理でその後の数千数万台の端末で行われるであろうラスタライズ処理が浮く事を考えると，検討するに値します．メディアクエリと組み合わせて考えましょう．また，下のような仕組みも役に立つと思われます．
An HTML extension for adaptive images
http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/
まとめ
- svgはプログラム言語である
- よって使い方により良いsvg，悪いsvgというものが考えられる
- 「webでsvgを使う」場合において悪いsvgとは処理が重いsvgである
- 重いsvgをばらまく行為はエチケットとして慎んだほうが良い
- 従ってwebでは基本的にシンプルな構造で短いsvgを使いたい
0 件のコメント:
コメントを投稿