これは一般的な方法だった。描画を高速に処理できるGPUの恩恵を受けたいなら、transformを使って以下のように記述する。*/}サイドメニューのDOMのレイアウト位置としては、x位置のleftもy位置のtopも、0のまま。横幅widthも縦幅heightも、100%ということで、全面を覆っているという扱いになる。translateX(-102%);で描画の位置自体を、左に寄せている。translateZ(0);をCSSプロパティに指定して、パフォーマンスを改善するというハックが出回ったのをご存知だろうか。このCSSが指定されると、描画には必然的にGPUの力が必要になるため、強制的にGPUに描画を依頼することになる。transform;という新しいCSSプロパティをWeb標準として追加することによって、同様のことを実現できるようにした。transform;といったCSS指定は、常時ビデオカード上のRAMメモリーに描画結果をテクスチャーとして保存することになる。モバイル環境では、バッテリー消費などに悪影響を及ぼすことになる。none;するといい。これが、バッテリー消費パフォーマンスと描画速度パフォーマンスのトレードオフ問題に対する、落とし所だ。opacity;というプロパティがあり、transformと同様の方法で、高いパフォーマンスで描画させることができる。CardsCSSを使ったパフォーマンス改善のテクニックの他に、注意しなくてはいけないのが、スワイプ操作時のコンポーネントの移動処理。ユーザーからの指の位置状況を入力し、それをスクリーン上に反映しなくてはいけない。この際、有用なのが「ゲームループ」のノウハウだ。描画のイベントは常に、1/60秒ごとに発生する。対してスワイプのイベントは、常に一定には発生しない。描画のタイミングにはあわせてくれないのだ。そこで、スワイプにより発生するイベントについては、変数に位置情報だけを記録する。描画時のイベントでは、記録された位置情報を元に、CSSを通じて描画位置変更をおこなう。this.startX、this.currentX、this.targetXといった変数に、現在の位置や、移動すべき位置を記録している。false;}描画のタイミングにrequestAnimationFrameから呼び出されるコールバックで、先ほどの位置情報を元に反映していく。Collapse」にノウハウが似ているので割愛。Collapseタップすると、領域が広がり全体化されるUIコンポーネント。Cards」とは異なり、スワイプ操作でなくタップによって、自動的にアニメーションする。この点で、より効率的な実装が求められる。アニメーションについて、動作中の状態はJS上で持たない。動作前後の状態だけを、CSSプロパティを通じてGPUに指示する。${invert.sy})`;そのままでは、タップした要素は一瞬にして全体化されてしまう。どのようにして何ミリ秒もかけて徐々に広げていくか?その方法は、CSSで指定する。原理的には、従来よく使われているCSSアニメーションだ。peformance」が役に参考になる。一読するといいだろう。Appsのパフォーマンス改善。Lewis氏が言いたかったことは単純な話です。AppsにおけるAnimationやReactionの課題は、いかにしてブラウザのレンダリング処理における「レイアウト」を減らすか、という話です。この講演は、そのTIPS集といえます。今日のノウハウ、特に新しいというわけでもなく2年前には既に実践されていたことです。実際のところ多くの現場では、OnsenUIやIonicのようなUIライブラリを活用することになり、このあたりの話を意識することはないのでしょう。Webのサービスを作っているフロントエンドエンジニアにとっては、ライブラリの有無に関係なく知っておくべき知識のように思えます。Appsか否かはもはや関係ないノウハウだったに違いありません。Webがモバイルに順応していくことは、今後もさらに求められていきます。これは、フレームワークやライブラリに限った話ではなく、トータルにみたWeb、フロントエンドへの要求に変化を与えるに違いません。今後も、モバイルとWebの関わりに、目が離せませんね。