こんにちは、@kaa_a_zu です。私は、今までいくつかの組織でフロントエンドのパフォーマンス改善に取り組んできました。パフォーマンスが劇的に改善したこともあれば、改善点の洗い出しで終わったこともありました。この記事では、それらの経験に基づいて、どのようにしたらチームがパフォーマンスに意識を向けることができるのか、改善を習慣化できるのかについて基本的なことを紹介させていただきます。少しでも参考になったらありがたいです。また、ご指摘や感想も随時お待ちしております。
※この記事はWebフロントエンド領域を対象にしています。
なぜパフォーマンス改善をするのか
パフォーマンスを改善する目的には、大きく３つあると考えています。
- ユーザー体験の質を向上させるため(追記: この動画はパフォーマンスの重要性を説いています)
- SEO対策のため
- 将来的にリッチな機能を導入するため(既にTWA化の基準にはパフォーマンスの指標がある。また、各ブラウザベンダーはPWAに力を入れており、パフォーマンススコアによる規制が厳しくなることが想像できる)
TL;DR
- チームがパフォーマンスを意識するための環境づくりを行う必要がある
- サービスごとに何の指標を大事にするのかを決め意識しよう
- パフォーマンス改善の施策PRを出すときには何が変わったのかを共有しよう
目次
- 第1フェーズ: 定期的な計測と見える化
- 第2フェーズ: チームで意識するメトリクスを定める
- 第3フェーズ: 施策立案と結果、考察
第1フェーズ: 定期的な計測と見える化
「推測するな、計測せよ」という有名な格言があるように、第一歩目は計測することです。定期計測には大きく2つの手法があります。これら2つの手法は、利用用途が違っておりどちらも利用することが多いと感じています。
①Synthetic monitoring(合成モニタリング)
- 常に同じスペックの環境で機械的に計測する手法
Pros: 変更したコード(PR) によって パフォーマンスに影響がないかを確認できる
Cons: リアルなユーザーが実際に体験している結果ではないため机上の空論になる
よく利用されるツール
②Real user monitoring(リアルユーザーモニタリング)
- サービスを利用しているユーザーの環境で計測する手法
Pros: 所謂UXの改善を具体的に実行しやすい。また、特定の端末においてのパフォーマンスの改善施策につなげることができる
Cons: OS, 端末スペック, ネットワークなどでかなりの変動があるため、変更したコード(PR) によって パフォーマンスに影響を及ぼしているのかがわかりにくい
よく利用されるツール
Firebase
speedcurve
splunk
datadog
pageSpeedInsight
SearchConsole
measure API 利用
どのツールを使っても基本的に同じことができると思います。ここで大事なのは、定期的に計測できるか、チームが意識できるような状態になっているか、ということです。前者はそのツール独自の機能を用いたり、CIに組み込んだり、スケジューラーを回すことで解決ができると思います。後者は、計測が終わったタイミングでSlackなど社内連絡ツールに自動的に投稿する仕組みづくりや、定期的にパフォーマンス振り返りミーティングを行うことで解決ができると思います。
第2フェーズ: チームで意識するメトリクスを定める
リリース毎に何を基にパフォーマンスが良くなったのか、悪くなったのかを判断する考え方にパフォーマンスバジェットがあります。これは、チームが目指すべきメトリクスを予め設けておき、これだけは下回ってはいけないというルールを設ける考え方です。その指標(メトリクス)となるものには、大きく分けて2つのタイミングがあります。
①レンダリング時
- 一般的にパフォーマンス改善の文脈で注目を浴びるのはこのタイミング
- SEOに影響するのはこのタイミング
- CoreWebVitals や WebVitals にあるメトリクスの多くは、このタイミングでのことを指すことが多い
CWV
Largest Contentful Paint (LCP): ファーストビューにおける最も大きなコンテンツの描画が終わるまでのメトリクス。ほとんどの場合はキービジュアル（ヒーローイメージ）
- 2.5 秒 以内にする必要がある
First Input Delay (FID): ユーザーの最初のインタラクションアクティブアクションをした後に、ブラウザーが実際にイベントハンドラーの処理を開始できるようになるまでの時間を計測します。
- 100 ミリ秒 以内にする必要がある
Cumulative Layout Shift (CLS): LSはレンダリングされたコンテンツがShift(動く)ことを意味している。その瞬間瞬間を１フレームと言い、ビューポートのサイズと、レンダリングされた2つのフレーム間のビューポート内の不安定な要素の動きからスコアが算出される layout shift score = impact fraction * distance fraction
- 0.1 点 以内にする必要がある
WV
First contentful paint (FCP): 何かしらのコンテンツ描画されるまでの時間
Time to Interactive (TTI): ページがインタラクティブ(触れる)になるまでの時間
Total blocking time (TBT): メインスレッドのブロッキング時間(FCP~TTI)
Speed Index: ページ全体のスピードを色々な方法で計算する
このほかにも Loaded, DCL, FPなどもある
②レンダリング後、ユーザーが操作をしている時
- ユーザーの動作に合わせての挙動なために一般的に計測することが難しいとされている
- クリックや、スワイプはユーザーが任意のタイミングで行うため他の要因でパフォーマンスが変わってしまう
- しっかりと名前が付いているメトリクスは少ない（上記で紹介したFIDはその１つ）
チームのサービス特性に合わせて、①②どちらのタイミングを重視するべきなのか、より具体的に何を指標としてパフォーマンスの良し悪しを図るのかということが大事になってきます。この時に直近意識する指標は１つにした方が良いと考えています。初めはその1つを意識し、コードを書いたり、PRのレビューをし、慣れてきたら他の指標についても考えるのが良いと思います。TTI, TBT, FIDなどの指標は、少量のコード変更でも変わってしまうことが多いので筆者は特に意識をしています。
パフォーマンスバジェットの具体的な決め方には、「TTI をLighthouse計測で 10s以下に抑えよう」 「トップページのCLS が 落ちがちだから 0.1s以内を意識しよう」などがあると思います。
第3フェーズ: 施策立案と結果、考察
施策立案
具体的な改善施策立案をするときは、以下の思考で行うのが良いと思います。
最初に、既に問題視をしており、絶対的に改善ができるものはないかを考える
例えば、リソース肥大化の問題が既に分かっているなら、「画像フォーマットおかしいよね」や「LIMITかけずに通信しちゃってるよね」など、一般的なパフォーマンス改善手法を当てはめてみるのはありだと思います。
次に、２で設定した目標に対して計測結果を見ながら考える
例1: TTI(Time to Interactive)を改善することが目的
- TTI を改善する目標を立てる
- 計測結果を見て、問題がありそうな部分について調査をする
- 3100ms あたりにあるで LayoutShiftも起きているため、ここを徹底的に調査する
例2: FCP(First contentful paint)を改善することが目的
- FCP を改善する目標を立てる
- 計測をして、問題がありそうな部分について調査をする
- そもそもFPまでに1,000msかかってるのは遅いため、ここを徹底的に調査する
こちらは当たり前ですが、もしも定期計測においてパフォーマンスが落ちていることが判明したら直前のリリース内容を見て怪しい部分を計測する必要があります。そうして行った施策について結果を見て、考察することが大切です。
結果、考察
前提として２つのことを、個人もチームメンバーも意識する事が大事だと思います。１つ目に、パフォーマンス改善に銀の弾丸はないため結果が出なくても落ち込まないということ。２つ目に、調査をする時には技術的な知識の他にドメイン知識(ブラウザ知識、その部分の実装を行った人の知識など)も必要になるため、分からなくなったら直ぐに聞ける環境が必要だということ。です。
それら前提を持った上で、以下2つは絶対にやるべきだと思います。
①結果は、次に繋げるために良くても悪くても目に見える形で共有する
- Before/After があると良い
- Lighthouseなどでの計測結果をPRや社内連絡ツールで共有する
- ブラウザDevToolのPerformanceタブの結果をPRや社内連絡ツールで共有する
②🎉少しでも改善が出来たらチームで祝う
正直、パフォーマンス改善は、好きな人じゃない限り、面倒で退屈な作業な場合が多いです。また、結果が確実に出るような内容ではありません。そのため、チームとしてモチベーションを維持するためにも、少しでも改善をすることができたら大袈裟なくらいに祝うことが大事だと思います。
最後に
パフォーマンスを改善することは、1人では決してできません。サービスの質をより良くするためにも、チーム全体で取り組める体制作りを行うことが大事だと思います。今回は、パフォーマンス改善の入門ということで、「具体的にどのように改善をしていくのか」については触れませんでした。以降、それらノウハウについても記事化していきたいと思っています。
参考資料
いくつか参考になるパフォーマンス改善ブログを載せておきます。
Web3スタートアップ「Gaudiy（ガウディ）」所属エンジニアの個人発信をまとめたPublicationです。公式Tech Blog：techblog.gaudiy.com/
Discussion