実は、当初iconDecotterは、最終的な処理をPHPのGDライブラリで行なってはいたものの、ユーザー向けのプレビューとして表示しているサイト上のアイコン加工状態の表示は、canvasを利用していました。APIで取得したアイコン画像をいったんサーバーに保存し、そのパスをjavascriptに渡して読み込み・canvasへ描画して元アイコンを表示し、更にフレーム画像のサムネイルをクリックすると、そのフレームをまたjavascriptで読み込んでcanvasへ上から重ねる、といった手順です。
つまりこの時は、同時に選んだフレームのIDや、位置調整のパラメータ等をinputにも同時に挿入しておき、サーバーにはパラメータ送信のみで、以降をサーバーサイドで処理する形にしていたというわけです。
なぜcanvasを利用しておきながら、最終処理はPHPに渡していたかというと、ユーザーのブラウザがcanvas非対応の場合、使用不可能になってしまうことを考慮していました。具体的にはIE8以下です。表示上だけならば、canvasを再現するライブラリのおかげで何とかなっていたんですが、そのcanvasのデータをサーバーに送信したりする等のことは出来なかったので、結局前述のような方法を取ることにしていました。
が。
やはり全てのブラウザでサーバーサイドの加工をしているのは負荷的にどうなのか、と思っており、せっかく対応ブラウザならばクライアントサイドで加工が済んでいるものをまたやり直しているのも無駄であろう、ということから、対応ブラウザのみcanvasで加工したものをそのまま送信する方法に切り替えることにしました。
決め手は、iconDecotterのアクセス解析の結果です。
iconDecotter2012年12月のアクセス解析・ブラウザの割合
iconDecotter2012年12月のアクセス解析・IEのバージョンの割合
アクセスブラウザの割合を見るところ、まずIEが全体の15.31％で、更にその中でIE8以下が約18％程度です。つまり、全体から見るとIE8以下=canvas非対応ブラウザの割合は約2.7％程度だということです。実際は他のモダンブラウザでも、まだcanvas非対応のVer.で来ている人も居るかもしれませんが、多分極々少数だと思われます。
※ちなみに、AndroidやSafari(in-app)が合計で半数を超えているのは、Twitter関連サイトであることの特徴かもしれません。スマートフォンの割合が非常に高いです。
したがって、ほとんどの人がcanvasが利用出来る状態であるならば、canvas加工をメインでやってしまって良く、逆に非対応の一部の人向けにPHPがフォローすれば良いという判断で、canvasを表示のみから実際の加工を任せるという仕様に切り替えることにしました。
canvasを実際に使用する上でのあれこれは、次回以降書いていこうと思います。
コメント