Google I/O 2021 フロントエンドまとめ（4/6）〜 読み込み後のパフォーマンスについて（1/2）〜
この記事は、Google I/O 2021で発表されたフロントエンド関連情報の中で個人的に気になったものをまとめたもので、
全6記事中4本目。
読み込み後のパフォーマンス の話
読み込み後のパフォーマンス @Google I/O 2021
「読み込み後のパフォーマンス」とは。というお話
まず「読み込み後のパフォーマンス」（「ロード後性能」）を語る前の、「そもそもロード（＝読み込みまでの）性能とは？」の話から始まる。
「初めにページに遷移してきてから何かしらの操作（クリック、入力、etc.）や主要機能の使用が可能になるまで。その時間枠に収まるすべてのものの性能」との説明。
そしてロード性能の重要性として「なかなかロードされないページをユーザは離れてしまう」から、「誰も来ないページを最適化しても意味ない」からとと説明、またページロードをどれくらい待ってくれるかは、ユーザにより個人差があること、またユーザが「そのページ、Webアプリケーションにどれくらいの価値を見出しているか」によること、などを説明し、そして「一般的にはロード時間は秒単位の問題」と語っていた。
次に、（前述を踏まえて）サイトには「ロード性能」の最適化が重要なパターンと、「ロード後性能」の最適化がより重要（※「『ロード性能』の最適化が重要じゃない」とは言ってない）となるパターンがあり、
「ロード性能」の最適化が重要なのは、ニュースやブログなどの遷移時にページ全体をロードするのが一般的なもの、
「ロード後性能」の最適化がより重要なのは、Webベースのメールクライアントなどのように一度ロードしたら遷移も全てクライアントサイドで行うものと説明。
そして、「皆さん（我々）のアプリはおそらくこれらの両極端（前述の2例）の間のどこかにあります」そして「アプリがこの範囲のどのあたりに位置するかに応じて最適化の配分を決める必要があります」という話に繋げる。
そして最後に、これらの配分をちゃんと再検討するのも大切、なぜならアプリが成長・変化するにつれて最適な配分は変化し、複雑すればするほど「ロード性能」より「ロード後性能」の方が重要になるからという結論で結ぶ。
読み込み後のパフォーマンス測定について。というお話
「ロード後性能」を語るためにはまず測定が必要で、
じゃあその「ロード後性能」はどうやって計測すんの？というお話。
そして、アプリの「ロード後性能」に関わりうる（そして定量化の困難な）指標として、以下を挙げる。
- 電力消費→バッテリーをバカ食いするアプリって良くないよね
- 消費メモリ→端末のメモリを逼迫させると、ガベージコレクションが発火してフリーズしたりするよね、でなくてもデバイスごとに許容可能なメモリ使用量って異なるよね
ちなみに上記を挙げる前説として、ロード性能の測定方法も上げていた。
具体的はWeb Vitalsの
-
LCP（Largest Contentful Paint; ページの主役となる最も大きなコンテンツのロード時間。
なお本当に「最も大きなコンテンツのロード時間」とは限らない模様 #何を言っているのかわからねーと思うが） - FID（First Input Delay; 最初の入力ができるようになるまでの遅延）
などが挙げられた。（なおCore Web Vitalsの主要指標としてもう一つ「CLS（Cumulative Layout Shift; 表示されるページ コンテンツにおける予期しないレイアウトのずれの量を定量化したもの。「いっぺん表示された風になった後ガタッってUIがずれて誤タップさせられたりする不快なアレ」の指数）」というのがある。これは「ロード後性能」に分類される）
「滑らかさと応答性」とそのCore Web Webへの採用の可能性について。というお話
滑らかさ
「滑らかさ」というのは、表示やアニメーションなどのアプリケーションの諸動作がカクついたりせず、遅延なく動作することで、ここの品質に問題があるとユーザをイライラさせることになる
「滑らかさ」を測定するにはRAF（requestAnimationFrame）ループを使ってその呼び出し間の経過時間を追跡する手段がある（※なお、望ましい手段とは言ってない。後述）こと、そしてその中で特にレンダリングに時間がかかる長いフレームに注意を払う必要があること、一方で長いフレームであってもレンダリング対象がなくて「滑らかさ」に影響しない場合への考慮も必要、との説明。
からの、急に「実はこのRAFを使った手法が悪手」とか言い出す。じゃあなぜ紹介したし！
その理由としては、「レンダリング対象がなくても、ブラウザに全フレームのシフトを強要する（要は「『滑らかさ』の計測」が「『滑らかさ』自体」に悪影響を与えている）ため」とのこと。（なるほど確かに。）
そして、その代替手段としてPerformance Observer APIを紹介する。
Performance Observer APIではフレームのレンダリング時間を追跡でき、かつフレームループが矯正される問題も防げるとのこと。
使用時の注意事項として、「アプリ固有のロジックに関する知見と組み合わせて、不要なデータを大量に収集したりしないようにしてね」とのこと。
応答性
「応答性」というのは、ユーザエクスペリエンスがユーザの操作に応答する速さのこと。
「応答性」は人が実際に知覚する現象のため、たとえば「ボタンを押下してからモーダルが表示されるのが遅い」、「入力した文字の表示に1秒かかる」のように言語化して説明がしやすく、しかしその一方で応答性を測るアルゴリズムを見つけるのは難しいとのこと。
そしてこれらを定量的に測定する手段として、peformance.measure()メソッドを使ってアクション間の遅延を計測する手法を提案していた。
Q.滑らかさと応答性は2022年にWeb Vitalに組み込まれるの？
A. maybe(たぶん)
→ （2021年ではなく）2022年ということらしい（※あくまで「maybe(たぶん)」）