読者の皆様は、「Extensible Web」というキーワードについてご存知でしょうか。

Extensible Webは、現在のWebが抱える大きな問題点を解決しようとする考え方であり、ムーブメントです。 その問題点とは、誤解を恐れず言うなら、「HTML5の流れで生み出された様々なAPIが実際にはあまり使われておらず、役に立っていない」という点に尽きると思います。

Extensible Webはそうした問題を解決するために、「開発者によって拡張可能なWebを目指そう」と呼びかけます。そのために必要なのは、特定のユースケースを想定した粒度の粗いAPIではなく、粒度が細かく、より基本的な機能を提供する低レベルなAPIを提供することで、開発者が様々なライブラリを作りやすくすることです。詳しくはこちらの記事も参考にしてください。

Extensible Webは、「Extensible Web Manifesto」というマニフェストが公開されてから広く世に知られるようになりました。Extensible Web Manifestoの文書がGitHub上で公開されたのが2013年6月9日ですので、既に2年以上が経過していることになります。本対談では、Extensible Webが誕生してから2年で何が変わったのか、そしてこれからWebはどうなっていくのかを、有識者の方々にそれぞれの立場から語っていただこうという発想で企画しました。

標準化団体のスタッフがどんな目線でWebを見ているのか、ブラウザベンダが開発者に求めているものは何か、Web標準にも詳しいエキスパートが現在のWebをどう捉えているかなど、普段聞けない話がいっぱいです！前後編でお届けしますので、どうかお楽しみくださいませ。

ちなみに、前編は全体的に、HTML5や関連（あまり知られていないかもしれない）APIを広範にdisる批評するという流れになってしまったので、ちょっとマニアックかもしれません…あしからず。

自己紹介

白石 皆さん、本日はお集まりいただき、ありがとうございます。非常に豪華なメンバーにお集まりいただき、誠に光栄です。今日は脱線大歓迎というノリで、自由闊達にExtensible Web、そしてWeb全体について語っていただきたいと思います。ではまずは、自己紹介からお願いできますでしょうか。

小松 小松と申します。通信会社（NTTコミュニケーションズ）でWebに関する研究開発をしておりまして、最近ではWebRTCやIoT/WoTに関する開発、標準化活動をやっています。

浅井 Mozilla Japanの浅井です。最近はエヴァンジェリストとしてWeb技術に関して開発者の皆さんの前でお話したり、モバイル＆エコシステムマネージャーとして、パートナーさんとの協業を促進しています。Fx0というスマートフォンの開発や、FirefoxOSを搭載したビエラの開発をお手伝いしたりなど、パートナーさんと「Webを使ったものづくり」を広げていく仕事をしています。

白石 ビエラって、FirefoxOS積んでるんですか。知らなかった…。

斉藤 株式会社リッチメディアで、主にメディア事業に携わりながら、対外的にはUXエンジニアとして活動しています。ここにいる皆さんは、標準化に近いところで働いていらっしゃる方が多いと思いますが、僕は一番現場に近いところで実装寄りの仕事をしているんじゃないかな。

ダニエル W3Cのダニエル・デイビスと申します。半分はTV・ビデオ関係の仕事を、もう半分はマーケティングやコミュニケーション、特に開発者向けに標準をどう伝えていくかといったことを担当しています。特に最近注目しているのはセキュリティです。今セキュリティに関する仕様書がたくさん増えているので、そうした情報を開発者に伝えるにはどうしたらいいかを考えています。

Extensible Web以前 – Application Cacheの失敗

白石 では、Extensible Webが出てもう2年が過ぎたわけですが、そもそもExtensible Web以前は何が問題だったのでしょうか？例えば、標準化の失敗例としては Application Cache (※) がよく引き合いに出されますね。AppCacheの何がいけなかったのでしょう？

小松 使えるシーンが限られていたのが一番の問題じゃないかと思います。数ページ程度の静的なWebサイトならいいんだけど、ページ数が増えたり、ちょっと複雑になるととたんに使えなくなっちゃう。あと、キャッシュのバージョン管理が面倒臭かったですね。

斉藤 アプリケーションキャッシュのファイルのバージョンを書き換えるGruntタスク、なんてのもあったりしますが、「勘弁してくれよ」って感じですね(笑) キャッシュが更新されるタイミングもブラウザによってまちまちですし。

白石 実務だと、キャッシュの最大容量とかもよく問題になりましたね。巨大な動画ファイルとかはキャッシュされなかったり、キャッシュの最大容量を知ろうと思っても知る手段すらない、とか。

ダニエル 「オフラインの場合はキャッシュを、オンラインの場合はWeb上にある最新のリソースを使う」といったユースケースにも対応できていませんでしたね。

斉藤 仕様としても、結構珍しいかなと思いますね。長くWeb屋をやっていますが、1ファイル（マニフェストファイル）だけ用意すれば、あとはブラウザがうまくやってくれる…という仕様は他に見たことがありません。

JavaScriptのAPIは、だいたいにおいてPolyfill (※)を用意できるように作られていて、レガシーなブラウザの上でも動作をエミュレートできるようにしてあるものが多い。でもアプリケーションキャッシュの場合は、使うか使わないかの「ゼロイチ」を要求される。APIではなく、いきなりプラットフォームを作りにいったという感じがありますね。

白石 僕、Google Gears（※）っていう技術の本を書いたことがあって、そういうのだけよく知ってるんですが、Gearsの仕様を参考に作られたからこんなことになったんだと思ってます…どうでもいい話ですが。。

※ Application Cache…Webサイトをオフラインでも利用できるようにする仕組み。マニフェストファイルというファイルを一枚用意するだけで、キャッシュの管理はすべてブラウザが行ってくれるというのがウリの一つ。

※ Google Gears…Googleが昔開発していた、オフラインWebアプリを実現するブラウザプラグイン技術。Application CacheやWebSQL Database、Web Workersなど、HTML5関連APIの仕様策定に参照され、HTML5がメジャーになると開発が終了された。

Webはアプリケーションプラットフォームになった

白石 他に、問題だったAPIとかありますか？

小松 よく言われるのは contentEditable (※)ですね。

浅井 ああ…死んでましたね。実装する側が(笑) 。「誰だ、こんな、実際には誰も使わないAPI作ったの」って開発者が文句言ってました(笑)。

白石 確かそれって、IEかなんかで実装されていたのを仕様に起こしたって感じじゃありませんでしたっけ。

浅井 そうかもしれませんね。「Webはみんなで作るもの」ってなる前の時代に作られた仕様という気がします。

斉藤 ちょっと全般的な話になってしまうのですが、かつて単なる「ドキュメントレンダラー」だったWebブラウザが、HTML5のブームの中で、アプリケーションのランタイムへと変化していったという流れがあると思うんですよね。

白石 かつてはHTML5の仕様書の先頭の方にも、「アプリケーションプラットフォームを目指します」と書いてありましたしね。

ダニエル それは今も変わっていませんね。W3CとしてはWebのことをオープン・ウェブ・プラットフォームと呼び表しつつ、プラットフォームがあまりに広くなりすぎているので、Application Foundation（アプリケーション基盤）として8つのカテゴリに集中するという動きをしています。

浅井 ブラウザベンダ側からすると、JavaScriptを生み出した時点で「僕らはアプリケーションプラットフォームです」と言い続けていたんですよ。機能不足で、そうは見えなかったんでしょうが…ただ、それを目指していたというのはNetscapeの時代からありました（若い人向けの注: Netscape NavigatorというブラウザがFirefoxの前身）。

NetscapeがJavaScriptを動的な、拡張可能な言語として設計した時点から、Webはずっと拡張可能なプラットフォームです。なので、Extensible Webというキーワードには、（Webは拡張可能であるという）ブラウザベンダの思いを、Web開発者に伝わりやすいように言い直したという一面があるんじゃないかな、と思っています。

※ contentEditable…任意の要素を、ユーザが編集可能な領域にすることのできる属性。<div contentEditable>とするだけで、簡単なWYSIWYGエディタを作成可能

disってない。disってないですよ

白石 イマイチという評価のAPIとしては、他にもそういえばWeb Storage（※）もありますね。同期型のAPIなので、ループの中とかで使っちゃうとUIスレッドがビジーになっちゃって、UIがもたついちゃったりフリーズしちゃったり、という。

小松 僕は割と好きなんですけどね。

斉藤 ハードに使っちゃダメなんですよ。ちょっとした優しさのために使うべき(笑) 。例えばフォームの入力内容を入れておいて、ネットワークが切れた時でも失われないようにするとか、その程度。

ダニエル 問題のあるAPIというと、<input type="date">とかもそう。昔私はOperaにいたんですが、そこらへん（inputの様々なtype）をいち早く実装したのが自慢でした。でも開発者からのフィードバックとしては褒められるどころか、「（<input type="date">使った時に）自動的に表示されるカレンダーのデザイン変えさせろ」でした(笑)。

斉藤 Operaかわいそう(笑)。

浅井 HTML5の発端（の一つ）だったのにね(笑) 。※

斉藤 僕は結局使ったことないですね(笑) 。デザインが合わないと、結局使いものにならないので。フォーム関係の仕様で言えば、required属性とか、<input type="email">とか<input type="number">とかはすごく助かりますよね。

小松 モバイルで、タイプに合わせた最適なキーボードが出てきてくれるのが嬉しいですよね。

白石 ほかには、存在はするけどあんまり使われてない、ってAPIも多そうですよね。例えばWeb Workers（※）とか。Shared Worker（※)なんてのもあったなあ…。

浅井 いや、（Mozillaは）使ってますよ！

白石 いやまあ、一般のWeb技術者が使っているかというと、あんまり…という気がしますよね。他には…えーと…名前が出てこない。EventSourceとかいうAPI使うやつ。

小松 Server Sent Events（※）だ。

一同: ああーー

小松 テキストしか扱えないし、サーバプッシュの用途だったら、他にWebSocketがあるから。HTTPサーバで事足りるっていうのはいいんですけどね。

ダニエル WebSocketを使えないホスティングサービスの上で、「しょうがないから」Server Sent Events使ったということはありましたね(笑)。

白石 まあ、こういう風に、「あるけど使われてない」とか「あるけどイケてない」という仕様がいっぱいあって。

ダニエル 他にももう一つ思い出しました。Network Service Discovery API（※）。W3Cスタッフとして言っていいかどうかわからないけど、あれはセキュリティの問題もあって、ちょっと残念な感じでした(笑)。

白石 でもこの対談、HTML5のAPIをdisる流れになってて、こんなの初めてで面白いなあ(笑)。

浅井 disるように誘導してません？(笑)。

白石 いや、そんなつもりは…(汗) 。

※ Web Storage…シンプルなローカルストレージAPI。localStorage.setItem('key', 'value')とするだけで、ローカルのストレージに値を保存できる。

※ Network Service Discovery API…ネットワーク上のサービスを動的に発見するためのAPI。ホームネットワーク上で、デバイスを発見する用途に利用できるとされていた。

プレフィックスの反省を活かす

白石 あと、Extensible Webの情報漁ってた時に「Indexed Database API（※）は、開発者のフィードバックを受けながら作った素晴らしいAPI」と書いてあったんですが、正直同意できない(笑) 。かなり使いにくいAPIだと思うんだけど…。

浅井 えーと、いや、それは、申し訳ない。だいぶうちら（Mozilla）が推進しちゃって(笑)。

小松 一番最初に実装してなかったけ？

浅井 してました(笑)。 （それ以前に提案されていた）WebSQL Database（※）なんて、標準化されていないSQLiteの仕様に依存してて全然ダメだ、と。

白石 いや、その主張は同意できたんですけど、できあがってみたIndexed Database APIの仕様がこれかーー、と(笑)。

浅井 いやでもまあ、Extensibleではあるじゃないですか。プリミティブで、パフォーマンスも上げられるAPIは一応揃っていて。APIの使い勝手については、申し訳ない、ライブラリ使ってくださいと。MDN (Mozilla Developer Network) に掲載されているIndexed Database APIの解説でも、「localForageかdexie.jsを使ってください。そっちのほうが『More user friendlyだから』と」と書いてあります(笑)。

ダニエル 素で使うのが厳しいという意味では、WebGL（※）とかもそうですよね。ラッパーライブラリがないとコーディングは厳しいけど、プリミティブでパフォーマンスの高いAPIを提供している。

浅井 そういう点から言うと、Extensible Webの考え方があと数年早かったら、Web Audio API（※）じゃなくて、Mozillaが作っていたAudio Data APIだったんじゃないかな、と思いますね。プリミティブなAPIを提供して、ライブラリはJavaScriptで作ればいいじゃん、と、そういう発想で作られていたAPIだったんです。

小松 さっき話に上がってたWebSQL Databaseは、実はまだ結構使われてたりする。

浅井 ああ、結構ありますね。たまにユーザから「動きません」ってフィードバックもらって、見てみるとWebSQL Databaseのせいだったりする。WebKitがWebSQLを実装したあたりで、急にみんなが新しいWebの機能を使い出して、そのままになってるサイトが多いんですよね。

白石 それは、-webkit-プレフィックスに依存したサイトが未だに大量にある、って問題とも繋がってますよね。

浅井 そうなんですよ… プレフィックス付けてる間に開発者からの意見を取り入れていこう、というシナリオをブラウザベンダは考えていたのですが、開発者たちは便利なものがあれば使ってしまう。我々（ブラウザベンダ）が考えていたようには、うまくいきませんでした。かと言って、ブラウザベンダ自らがライブラリを作って提案したりしても、使われるのは最初だけで、すぐ使われなくなったりしてしまう。だから、ライブラリを作りやすくして開発者の意見を取り込みやすくしていこうというのがExtensible Webの目標の一つです。プレフィックスの失敗も、反省の一つだと思うんですよね。

※ Indexed Database API…ブラウザ上で利用できるキー・バリュー・ストレージ。Web Storageに比べると複雑だが高機能。

Extensible Webの起源はjQueryにあり？

小松 あと、Extensible Web以前という話で言うと、4年前にサンタクララで行われたTPAC（※）のブレークアウトセッションの中で、「開発者とW3Cがうまく関わっていくにはどうしたらいいか」という議論をしたのを覚えています。そこで、開発者が中心になってWebを伸ばしていくという話で、jQueryの例が取り上げられていました。

で、（DOM操作に）セレクタを使用するというのがWeb開発者に受け入れられるというのが判明したので、パフォーマンスの問題を解決するために、ネイティブでquerySelector API（※）が実装されたと。ここではフィードバックループがうまく働いたので、こういう例をどんどん増やしていこうという話がありまして、こういう流れがExtensible Webに繋がったのかなあ、と思います。

ダニエル jQueryの話が出たところで、一ついいですか？Extensible Webとは全然関係ないんだけど。

白石 なんですか？

ダニエル …小松さん、John Resig（※）に似てない？

斉藤 ああー、ググって出てきた写真で見ると、ちょうど黄色のやつに似てる。黄色いJohn Resig。

一同: (爆笑)

ダニエル すいません、脱線しまして…。

白石 いえいえ、最初にお伝えしたように、脱線大歓迎です。この、「黄色いJohn Resig」の話も、記事に含めさせていただきます(笑)。

ではここらで一旦まとめますと、まずjQueryをきっかけとしてquerySelector APIが出てきたといった流れがあり、これは実際に役立つAPIとして世界中で利用されているし、jQuery、もしくは類似ライブラリのパフォーマンス向上にも一役買っている。

一方で、Webプラットフォームには今やたくさんAPIがあるけど、使われていないものや、イケてないものもたくさんあると。こうした問題を解決する一つの糸口として、querySelector APIが生み出された経緯をヒントにしつつ、現在のExtensible Webというムーブメントに繋がっている…という流れでしょうか。

（以後、後編に続く）

※ TPAC…W3Cが主催する、Web標準技術に関するカンファレンス。

※ John Resig…jQueryを作った人。

前編から引き続き、後編でも最適化のために知っておきたいレンダリングプロセス、計測方法、そして最適化を妨げるよくあるアクシデントとその回避方法について紹介していきます。

アニメーションを高速化するために知っておきたいレンダリングプロセス

ブラウザがどのようにウェブサイトを表示しているのかを知ることは、アニメーションだけに限らず、Webのパフォーマンス全体の高速化を行うために大切なステップです。 イスラエルの開発者であるTali Garsiel氏が公開した『How Browsers Work』は、HTML5 Rocksに転載され、複数の日本語訳も提供されている、ブラウザの内部動作を学ぶために読んでおきたいリソースの1つです。 そのリソースを参考に、レンダリングエンジンのメインフローについて見ていきましょう。

ブラウザはまずHTMLドキュメントを解析し、HTMLタグをコンテント・ツリーと呼ばれるDOMノードに変換します。そして外部CSSやスタイル要素に含まれるスタイルに関するデータを解析し、レンダーツリーを作成します。
このレンダーツリーが色や大きさのような情報を持つ矩形を持っています。

ここから先が特にアニメーションのパフォーマンスに関わりの深いフローになりますが、レンダーツリーが作成された後、レイアウト(リフロー)と呼ばれるプロセスに入り、そしてペイントがそれに続きます。

ここでは非常に大まかな流れしか解説しませんが、Paul Irish氏が言うとおり、ブラウザがHTMLやCSSを画面に表示するまでのフローを理解することは、開発におけるベストプラクティスの背後にある根拠を理解する手助けとなります。少々慣れない用語が多いかもしれませんが、ぜひ先ほど紹介した記事を一読ください。

アニメーション・ボトルネック: レイアウト(リフロー)

Google ChromeやSafariなどのWebKit系ブラウザではレイアウト、FirefoxなどのGecko系ブラウザではリフローと呼ばれるプロセスは、パフォーマンス向上において大きな障害となるプロセスの1つです。
Satoshi Ueyama氏が2007年に『出張 Shibuya.js 24』にて発表した際に使用した以下の動画で見ることができます。様々な大きさの矩形が徐々に配置されていくプロセスがレイアウト/リフローです。

Gecko Reflow Visualization

このレイアウトのプロセスを、どのように最小限に抑えることができるかが、アニメーションの高速化において大切なポイントになります。 レイアウトを引き起こす原因について、詳しくはTony Gentilcore氏による「How (not) to trigger a layout in WebKit」を参考にしてください。
記事のタイトルにもある通り、あくまでWebKit系ブラウザのみに限定されていますし、2011年の記事でもありますので、必ずレイアウトの発生を確認できるツールを利用して確認することをおすすめします。
（執筆時点ではGoogle Chrome、Safariの開発者ツール、そして紹介記事から得た情報でしかありませんが、IE11の開発者ツールでもレイアウトの発生を確認できます）

アニメーション・ボトルネック:ペイント

やや乱暴ではありますが、ブラウザで何かを表示するということは、HTMLやCSSから得た情報を画像化して表示しているのと大きな差はないと言えます。　

CSS3がプロダクションレベルで利用されはじめた今、角丸やシャドウなどを画像を利用せずに表現することが当たり前になってきているかと思います。読み込む画像が少なくなれば、その画像を制作するコストも減り、画像の読み込みにかかるコストも減りますが、その代わりにブラウザがそのコストを背負ってくれているわけです（もちろん1対1の割合ではありませんが）。
この後の段でアクシデントとして紹介しますが、すべてのスタイルが同じコストでペイントを行うわけではなく、また組み合わせによってコストが甚大になるケースもあるので注意が必要になります。

ブラウザは、表示領域をいくつかのタイルとしてレンダリングを行います。それぞれの個別のタイルごとにレンダリングをし、その結果をキャッシュしていきます。
そのため、大きな領域でペイントを行うことを避ける必要があります。レイアウトと同様に、ペイントを行う範囲を最低限にしておくことがポイントになります。

アニメーションのパフォーマンスの計測、デバッグツール/ワークフロー

パフォーマンス最適化において、最も大事なことは計測することです。私自身もよく陥る失敗ですが、どこかで読んだから、以前はうまく回避できた問題だからと盲目的にそれらの情報を頼りにするのではなく、計測する方法をきちんと学び、計測を日々続けることがベストプラクティスです。

開発者ツールについての詳しい記事は今後本サイトで紹介される予定ですので、ここでは私が実際にアニメーションのパフォーマンスについて計測するのに利用しているツールとワークフローを、ほんの一部ですが紹介していきます。

パフォーマンス計測を行う上で欠かすことができないのが、Google Chrome Canaryの開発者ツールです。Chromeではなく、日々更新を続けていくCanaryを利用する理由は、計測ツールとしての機能の多さと深さがChromeとは異なるからです。

アニメーションの最適化という文脈においてタイムラインパネルは、エディタとブラウザの描画エリアと同じくらい見る画面です。

まずは上図の1、Framesタブに切り替えて、上図2のRecordボタンをクリックし、計測を行いたいアニメーションを実行します。

すると、上図のような棒グラフが記録されていきます。その下にある表は棒グラフをより詳細にしたものです。
棒グラフは、背が高ければ高いほど処理に時間がかかっているということになります。計測対象にもよりますが、グラフ上にある2本の線は30FPSと60FPSを示しています。60FPSを目指すのであれば、それ以上の高さになっている棒グラフの周りをドラッグすることで、下にある表にその選択したタイミング内の詳細情報を表示させることができるようになります。

表にある横グラフは、マウスオーバーさせることでその特定の処理についての詳細を見ることができます。
レイアウトやペイントがどの範囲で行われているか、そしてそれにかかっている時間がどのくらいか、などの情報を確認することが可能です。
これらの情報と最前にも紹介したレンダリングの仕組みの情報を踏まえて、トライアル&エラーを繰り返し、最適化を図っていくのが大まかなワークフローとなります。

アニメーションを遅くするよくあるアクシデント

最後にアニメーションのパフォーマンス最適化を妨げる、よくある3つのアクシデントを紹介します。

1つ目は本連載の前編でも少し触れたGPUにまつわるアクシデントです。
GPUを使ってRenderLayerを作成し、そのレイヤー上でアニメーションを行うことそのものはベストプラクティスと言えます。しかしCPUからGPUへのデータ転送にはコストがかかり、特にモバイルデバイスなどCPUもGPUも非力である場面で問題になります。

この問題については、Phamtom.jsの作者としてよく知られるAriya Hidayat氏によるデモが非常にわかりやすいです。デモそのものはこちらのcodepenで実際に動作しているので、参考にしてください。

Ariya Hidayat氏によるGPUへのデータアップロードデモ

それぞれのボックスの右上に数字があり、カウントされているのが確認できたでしょうか？　このカウントがCPUからGPUへのデータの転送数を示しています。このデータ転送が少ないほうがパフォーマンスはよくなります。
ですが、実際にデータ転送を行わないプロパティは非常に少なく、Ariya Hidayat氏によれば、opacity、transform、filterの3つのみと言われています。
アニメーションの表現としてデータ転送が回避できない場面が多いのも事実ですが、同時にデータ転送には相応のコストがかかることを知っておくことも大切です。

GPU関連でもう1つの落とし穴があります。GoogleのJake Archibald氏によるデモをご覧ください。

オレンジ色の矩形が、GPUによって処理されるComposited Layerを示しています。実際にComposited Layerを生成したかったのは左上の緑のボックスだけなのにも関わらず、どういうわけか見出しにもComposited Layerが生成されてしまいます。デスクトップ上であれば、このComposited Layerの生成にかかるコストは気にするほどのことでもありませんが、モバイルデバイスにおいては大きなコストになってしまいます。
この問題を回避するのにはシンプルな解決があります。

先ほどのデモ内においてはアニメーションする要素そのものに、z-index: 1を付与することで回避できます。
このアクシデントは、カルーセルのようなUIパターンによく見られます。自作する際も、すでにあるライブラリを利用する際も、思っていない場面でComposited Layerが生成されていないか確認し、z-indexを使って回避できるか試してみてください。

Ariya Hidayat氏によるW3Confでのプレゼンテーション『Fluid User Interface with Hardware Acceleration』はハードウェア・アクセラレーションを使った最適化を行うのにあたり、見ておくべきリソースの1つです。またThe Chromium ProjectsにてドキュメントされているGPU Accelerated Compositing in Chromeも参考になりますので、ぜひ一読してください。

ここで紹介する最後のよくあるアクシデントが、CSSプロパティの組み合わせによるペイントコストの増大です。このアクシデントはモバイルデバイスでよく見かけるものです。例えば、角丸とシャドウを組み合わせたボックス、非常によくあるスタイルにも関わらず、これらのスタイルがあると、とたんにスクロールが引っかかるように感じてしまうことがあります。この「引っかかる感じ」の原因の多くがペイントです。

どのプロパティの組み合わせがどれくらいのペイントコストとなるかを計測するためのツールは存在はしますが、ここでは紹介しきれませんので割愛します(チャレンジしてみたい方はこちらのドキュメントを参考にしてください。また取得方法は異なりますが、Colt McAnlis氏によるHTML5 Rocksの記事『CSS Paint Times and Page Render Weight』も合わせて参考にしてください。)。しかし前段で紹介したタイムラインパネルでもペイントコストを確認できますので、トライ&エラーを繰り返すことで、最適化を進められるでしょう。

前後編にわたってWebアニメーションの最適化について紹介してきました。
いずれブラウザや端末そのものも賢くなり、これらの知識やテクニックも早晩時代遅れになっていくだろうと思います。しかし、我々はその過渡期にいる最中です。「使いやすさ」を向上する上で欠かすことができない最適化は多くの苦難があっても報われるものです。

アニメーション／トランジションは身の回りに当たり前にあるものです。
むしろ普段の生活では「0」が「1」に変化するものの方が珍しいでしょう。
アニメーション／トランジションはデジタルなWebに対して自然な変化を提供する大切なツールです。
今回はそんなアニメーション／トランジションをより自然にスムーズに動作させるために知っておきたいことを前・後編の2回に分けて紹介していきます。

アニメーションを高速化する理由

アニメーションは先ほど書いたように普段の生活にも存在しています。だからこそ、我々はスムーズではないアニメーションを見つけるのが得意です。

アニメーションに限定した話ではありませんが、FacebookのShane O’Sullivan氏が、ページロード後のレンダリングパフォーマンスが一定でない場合は「いいね！」や「シェア」などのアクション率が低下すると、昨年Londonで開催されたEdge Conferenceで話していました。

特にモバイルデバイスは触って操作するだけあって、ユーザが無意識に自分の感覚と近いものを求めることは当然とも言えるでしょう。

アニメーションの速さを計る「FPS」について

これまでパフォーマンスを計る単位はページロード速度を計るミリ秒が主でしたが、最近ではページロード後のレンダリングやアニメーションのパフォーマンスを計る単位としてフレームレート(単位時間あたりいくつフレームが処理されるかを表す単位)が利用され始めていて、WebにおいてはFPS(Frames Per Second)、つまりフレーム/秒という単位で表すのが一般的です。

ここでいう「フレーム」は映画などで指す「コマ」と同じものと考えて差し支えないでしょう。例えば映画の世界では24FPSが標準的に使われていて、Webにおいては60FPSがたどり着くべき目標とされています。

JavaScriptとCSSではどちらがアニメーションに最適なのか？

Web上でアニメーションを表現するには多くの方法がありますが、ここではJavaScriptとCSSを使った手法にフォーカスします。

CSS3を使ってのアニメーションの以前はJavaScriptによる実装しか選択肢がありませんでした。jQueryの.fadeIn()や.slideUp()などを使ったアニメーションの実装の経験は多くの人が持っているでしょう。

Web開発におけるすべての問題への正しい解答はいつだって「時と場合による」ものですから、どちらが最適かという問いに対する答えも同じです。しかし、本誌のユーザーの体感速度を高めるためのJavaScriptチューニング（後編）にある通り、JavaScriptはシングルスレッドで動作するもので、JavaScriptがアニメーションを行っている間はそれ以外の処理を行うことができません。

JavaScriptは現在のWebサイト/アプリにおいて非常に多くの処理を行う傾向にあるため、CSS3にその処理を代わって実行させることができるようになったことは、パフォーマンス観点では大きな一歩と言えるでしょう。

しかしCSS3のアニメーションを使ったからといって、60FPSの目標を自動的にクリアできるものでは決してありません。

ハードウェア・アクセラレーションは銀の弾丸ではない

CSS3を使ったアニメーション実装が進むにつれ、思った以上にパフォーマンスが出ない場合にハードウェア・アクセラレーションを強制的に利用するテクニックが紹介され始めました。

ブラウザが行う処理はこれまでCPUで行ってきましたが、アニメーションをスムーズに実行するにはGPU(グラフィックス プロセッシング ユニット)を使う方が効率的です。

ハードウェア・アクセラレーションを利用すると言った場合、端的に言ってしまえば、transform: translate3d(0,0,0)あるいは、transform: translateZ(0)という3Dに関連するプロパティを追加すると、実際に値がゼロであってもブラウザはGPUを利用し、そうすることでアニメーションがスムーズに実行される。というように解説されることが多いです。

どんなツール/テクニックにも当てはまることですが、得るものがあれば、必ず失うものもあります。ハードウェア・アクセラレーションを利用することで得られることは、GPUが得意とするグラフィック処理を行うレイヤーを生成(後述)し、そのレイヤー上で処理が完結できること、そして失うものはそのレイヤーを生成し、管理するコストです。

例えば、ハードウェア・アクセラレーションが効果的だからと言って、body * { transform: translateZ(0) } というような記述をすると、本来であればレイヤーが必要ない要素に対してもレイヤーを生成してしまうことになります。これはレイヤーを生成し、管理するためのメモリを余分に費やすことになり、サイト全体で見るとパフォーマンスが低下してしまうことになります。

ハードウェア・アクセラレーションは必要なタイミングで必要な要素にだけ利用するようにするべきです。また、transform: translateZ(0)というような記述でブラウザにハードウェア・アクセラレーションさせるのはあくまでもハックとして考えておいた方がいいでしょう。ブラウザのアップデートとともにハックが利用できなくなるかもしれません。

CSSのプロパティによってアニメーションのパフォーマンスはどう変わるのか

ハードウェア・アクセラレーションはtransform: translateZ(0)だけで利用できるようになるわけではありません。

例えば、ある要素の位置をA地点からB地点に移動させるアニメーションを実装する際に:

1. transform: translate()を利用する
2. position:absoluteで要素の位置を指定しtopやleftの値を利用する

というケースが考えられます。

Paul Irish氏はこの2つケースを実装し、両者のパフォーマンスを比べています。

結論から言うと、1)のtransform: translate()を利用するほうがパフォーマンスはよくなります。

Paul Irish氏は2)で実装する場合、アニメーションする要素はCPUを利用し、かつ敷かれている背景に対して移動する度に描画を行う必要があるのと比べて、1)の場合、要素はGPUが生成するRenderLayerと呼ばれる専用のレイヤー上を移動し、敷かれている背景などへの影響がないため、スムーズに移動することができると解説しています。

RenderLayerについてはブラウザの内部的な話になってしまうので、ここでは詳しくは触れませんが、2)のposition:absolute + top/leftを使った場合のアニメーションは、ブラウザを白い壁に例えると要素が移動するたびに要素を白く塗りつぶし、移動先に書き直す、というような処理になりますが、1)のtransform: translate()を使った場合は、白い壁に透明のシート(RenderLayer)を被せ、そのシート上に要素を描くことで、移動はシートを動かすだけで実現できるようになる、という様に考えてみるとわかりやすいでしょう。もちろんアニメーションによってはRenderLayerが得意な表現だけを利用できるわけではありませんし、あくまでも現時点のブラウザの仕様に依存する部分も多くあります。

次回後編ではレンダリングプロセス全体について簡単に解説し、アニメーションのボトルネックとなるレイアウトとペイントの2つのプロセスについて、そして、より詳しい計測、デバッグのワークフロー、最後によくあるアクシデントと回避方法について紹介します。