俺もするするさせたい：DroidKaigiウェブサイトのスクロール
2017年に開催される DroidKaigiのウェブサイトが公開された。めっちゃ楽しみにしているし、すぐウェブサイト開いて情報収集モードに入った。
ウェブサイトを見ていたら目がなんかに引っかかった。あれ？思って今のはもしかして・・・ジャンク？
ちょうど、先週の日曜日にグランドフロントエンド大阪にてレンダリングパフォーマンスについて発表させて頂いたので頭がああいうのを求めていたやろけど、とにかくそういう事でジャンクなのかを調べてみた。
ひとまず、測ってみよう。クロームDevToolsのタイムラインからスクロールした操作を記録する。こっちは最高スペックのMacBook Proなので一般ユーザのマシンに一致しないと思って、それからちょうど Chrome 54 からは CPU Throttling が可能になったので使ってみよう。※ ちなみに CPU Throttling を無効にしても結果に変更はあまりなかった。
結果をさくっとみるとまず赤が多い事がわかる。DevTools#Timeline の中は赤が現れると注意するべき。それから、最近のタイムラインタブでは RAIL のステップもわかりやすくなっていて、今回はスクロールをしている部分がすぐわかるし、あとヘッダーが隠れたり表示したりのも Animation のところでわかる。
しかし、スクロールしていない時も 60fps 満たしていないのが一番目立つ。定期的に JavaScript が実行されているようで詳細みてみると各フレームに 7ms ぐらいかかる JavaScript 処理が呼ばれている。
60fps を実現するにフレームを 16ms で作らないとだめやけど毎回、7ms のかかる処理が含まれたらあと残っている UI タスクもいっぱいあってブラウザにしてはレベルが高すぎる。実際、毎回走っている処理はバナーの壁紙アニメーション。
デザインとパフォーマンスのトレードオフになるけど、7ms は個人的にちょっと高いかなと思う。
という事で解決は簡単ではないが、下記のを考えられると：
- スクロールの途中はアニメーションを一時停止する。ちょっと満足しない解決。スクロールの時以外も 60fps を満たしていないし、でもするするなスクロールは実現できるメリットはある。
- particles.js をリファクタリングしてみる。アニメーションされている要素の数を減らしたり、コードを改善するとか。
- 実際、particles.js が起こしているアニメーションのコストを減らしてみる。例えばペイント処理は今、毎回実行されているけど、それを防ぐようにするとか？
- 今は particles.js が requestAnimationFrame で動いているけど、じゃ例えば優先度を下げてアニメーションを requestIdleCallback で実行する？そもそもそんな事はできるのかな。やっぱり requestIdleCallback の目的に合わないと思う。アウト。
書く前に解決を付けてなんか書いたろと思ったけど結論じゃよくわからないという事や！もちろん、DroidKaigi のウェブサイトを作った人がだめだとかは一切思っておらずかっこいいウェブサイトを少しでも改善したいと思っただけ。レンダリングパフォーマンスムズカシイ。
以上。
