離脱防止にはパフォーマンスが非常に重要
toshick氏：パフォーマンスについての発表を始めたいと思います。はじめまして。世界のtoshickといいます。私は2020年の3月に株式会社メルペイにジョインして、開発を続けています。カポエイリスタです。もしカポエイリスタがいたら、次のホーダでお会いしましょう。ホーダとはカポエイリスタの会合みたいなものです。
それでは始めます。この回では、Merpay Frontendがどのようにパフォーマンスに取り組もうとしているのか、現状のパフォーマンスをどのように把握しているのかを発表したいと思います。結論から言うと、Web Vitalsのスコアをベースにしています。
Jakob Nielsen氏の言葉を引用すると、「遅延が10秒までになると、ユーザーがコンピュータに振り回されている気持ちになり、ストレスを感じ始める。10秒以上遅くなると、サイトからの離脱率が高くなる」。これを、コンテンツ以外の要因で離脱されることを防ぐためには、パフォーマンスは非常に重要になると解釈しました。
Web Vitalsの4つの指標を計測して追いかける
ところで、お客さまが満足するパフォーマンスが出せているのか、いったいどうやったら証明できるのでしょうか？
この答えはWeb Vitalsにあると思います。Web Vitalsは、「Google」が主導している品質指標のガイダンスで、どれだけ良好なユーザー体験を提供できているのかを標準化し、計測できるものです。中でもこの「LCP」「FID」「CLS」というバイタルは「Core Web Vitals」と呼ばれていて、かなり重要視されています。
私たちMerpay Frontendは、4つの指標を計測して追いかけていくことにしました。LCP（Largest Contentful Paint）、CLS（Cumulative Layout Shift）、TBT（Total Blocking Time）、そしてTTI（Time To Interactive）です。
それらを非常に簡単に説明すると、こうなります。LCPは「メインのコンテンツをなるべく速くロードせよ」ということです。CLSは「Stop layout shifts！」。layout shiftはガタツキのことです。ロードがし終わったあとに、カクついたりするあの現象のことです。それをなるべく減らすこと。TBTは、ページをロードする際に、インタラクティブじゃない状態の時間をなるべく少なくすること。TTIも非常に似ていて、ユーザーに対してのレスポンスを可能なかぎり素早く行うこと。これらが4つの指標です。
先ほど重要だと言っていた「FID」（First Input Delay）は、Lighthouseというコマンドがあって、それがスコアを弾き出してくれるんですが、シミュレートされた環境でしか弾き出せないので、ユーザーをトリガーとしたアクションを測ることはできません。そのため、4つの指標から外しています。
「field metric」と呼ばれているものは、現場で起きるパフォーマンスのことで、私たちが今から測ろうとしている、CIなどのいろいろな実行結果のスコアのことを「lab metric」と呼ぶそうです。
一方で、lab metricであるTBTの改善が、直接FIDの改善につながるというWeb Vitalsのドキュメントもあるので、私たちはFIDをいったん諦めて、TBTにフォーカスしています。
指標の結果をグラフで可視化
「Looker」のグラフがありますが、1つのURLに対して、追っかけようとしている4つの指標の結果をグラフ化しています。
Lookerのグラフの生成は「Lighthouse」というコマンドで、対象ページのさまざま指標のスコアをJSONで出力できます。これを加工して「BigQuery」に保存します。そのBigQueryのデータを吸い上げて、Lookerでビジュアライゼーションを行っています。
JSONにはさまざまなデータがあるのですが、その中で重要なのはscoreとnumericValueの2つだと思います。scoreは、実際の指標を100点満点で結果を出力してくれます。numericValueは、scoreのミリセカンドなど、リアルな数値を出力してくれます。これらを使ってグラフを生成します。
青いバーと赤い折れ線グラフが見えると思います。青いバーは、0～100の100点満点のスコアで、赤いラインがミリセカンドの数値です。スコアをパッと見た時に、良いのか悪いのかが直感的にわかるように、後ろにバーを表示しています。バーが上下最大になっている場合は、100点に近くてとても良いパフォーマンスが出ているということです。
スコアはいったいどう決まっているのかをお話しします。赤いラインと緑のラインで、それぞれ4,000ミリ秒と2,500ミリ秒になっていますが、これはWeb Vitalsチームが決めている指標ごとのGood／Needs Improvement／Poorの境界値です。
LCPは、2,500ミリ秒よりも少なければGoodということになります。このスコアを目指すことによってサイトの健全化の指標を追っかけられます。
既存と改善のスコアを比較して改善結果を確認している
改善の確認についてです。自分の修正の結果が実際にうまくいったかどうか、1回のスコア算出で喜んでよいのでしょうか。実際、スコアはかなりブレがあって、毎回変動します。なので、数日から1週間ぐらいの単位で改善したかどうかを見る必要があると思います。
私たちはテスト環境に対してチェックを行っていて、オリジナルのグラフとは別に、改善の施策を講じたものもグラフ化しています。Lookerのグラフを手動で作成するとかなりコストがかかるので、ビルドスクリプトを用意して、簡単にグラフが出力できるようになっています。
メルペイでは、テスト環境のPR（Pull Request）ごとにそれぞれのバージョンを好きなだけデプロイできるので、それを使って既存のものと改善したもののスコアを見比べて、改善したかどうかを確認しています。
パフォーマンスチームの次のアクションとして、ベストプラクティスを探して共有すること、ペイロードサイズを監視してパフォーマンスが悪くならないようにすること、あとはパフォーマンスがビジネスに与える影響を計測したり、先ほど諦めたユーザーのfield metricsであるFirst Input Delayなどの項目もチェックしたりといったような仕組みを整えていきたいと思っています。
Merpay Frontendではパフォーマンス改善に興味のある仲間を募集しているので、ぜひ応募をよろしくお願いします。一緒にベストプラクティスを見つけましょう。以上でパフォーマンスの説明を終わります。
