これだけは学びたい「メトリックの意味と使い方」。どうするパフォーマンス予算?

  • 2021年3月23日
  • パフォーマンス予算(パフォーマンスバジェット)の理解はあまりされていません。しかし、実践となると必ず要求される考え方のひとつです。Webページは想像以上に複雑で、数多くの指標でモニタリングできます。この記事は 1)パフォーマンス予算を導入し始めたばかり方や、2)すでにパフォーマンス予算を導入し内容を検証したい方、に役に立つはずです。

    パフォーマンス予算とは?

    パフォーマンス予算とは、最も気になるメトリクスに適用するしきい値ことです。そのしきい値から逸脱したときにアラートを送信したり、ステージング環境でテストしている場合はビルドを中断するように監視ツールを設定することで、Webサイトの表示スピード品質を担保することができます。

    パフォーマンス予算の大前提を理解するのはとても簡単です。問題なのは、それを実践しようとするときです。ここで、3つの重要な問題が発生します。

    1. どの指標に焦点をあてるべきか?
    2. 予算のしきい値は何にするべきか? 
    3. どのように予算管理をするか?

    これらに対して、人それぞれ異なる考えがあると思います。以下が私の考えです。

    1.どの指標に焦点をあてるべきか?

    パフォーマンス指標は数多く存在します。それらすべてを一覧にする前に、まずはしっかりとこれらの指標がどんな意味合いをもっているのか確認してみましょう。

    大半の人は、パフォーマンスがユーザーエクスペリエンスに影響を与えることを認識しています。ですが、それは実際にどういう意味なのでしょうか?以下の疑問に帰着するのではないでしょうか。

    • 読み込んでいるか?ページが実際に機能するのはいつですか?
    • 操作可能か?ページに十分なコンテンツが表示され、目的の操作を始められるのはいつですか。
    • 感想は?ページを操作することは簡単/不便でしたか?

    答えようとしている質問が何なのかを明確にすることで、最適な指標を見つける手立てとなるはずです。

    重要:これらの指標のパフォーマンス予算の設定に過度に投資する前に、まず、これらの指標が独自のデータとどのように整合しているかをよく確認してください。

    これを行う最も簡単な方法は、合成テストデータでフィルムストリップのレンダリングを確認することです。当投稿では、公開されている業界ベンチマークのダッシュボードの例を使用しました。ぜひご自身でも確認して指標を調べてみてください。

    読み込んでいるか?

    ユーザーは、そのページが実際に機能していると感じたいのです。ここで考慮すべきいくつかの指標を紹介します。これらの指標を確認するために使用できるツールのタイプ(合成またはリアルユーザーモニタリング(RUM))を挙げてみました。

    Backend(SyntheticおよびRUM)

    バックエンドタイム(別名Time to First Byte / TTFB)とは、最初のナビゲーションの開始から最初のバイトがブラウザーに受信されるまでの時間です(リダイレクト後)。バックエンド時間の責任者でなくても(フロントエンド開発者など)、他のすべての指標が遅延する可能性があるため、追跡することをお勧めします。

    Start Render(SyntheticおよびRUM)

    Start Render(レンダリング開始時間)は、最初のナビゲーションの開始から白以外のコンテンツが最初にブラウザのディスプレイにペイントされるまでの時間として測定したものです。最初に表示されるペイントが意味のある量のコンテンツでなくても、ページが機能していることを示す有用なシグナルであり、ユーザーが直帰するのを防ぐのに役立ちます。

    Start Renderは最近あまりとりあげられなくなりました。おそらく、他の真新しい指標が出てきたためでしょう。しかし、私は多数のユーザビリティ調査に参加して、レンダリング開始時間、ユーザーエンゲージメント、およびビジネス指標の間に強固で一貫した相関関係があることを発見しました。リアルユーザーモニタリングでは以下のようなグラフを生成し、独自のデータを用いてこのような相関関係を示すことができます。

    操作可能か?

    ほとんどのユーザーは、意味のあるの量のコンテンツが表示されるまで、ページの操作を開始しません。画像や動画などの重要なコンテンツを追跡することから始めるのが良いでしょう。

    Largest Contentful Paint(SyntheticおよびRUM)

    Largest Contentful Paint(LCP)とはGoogleのコアウェブバイタルの1つであり、昨今多くの注目を集めています。LCPとは、ビューポートにおける最大の要素がレンダリングされるまでの時間です。IMGやVIDEOなどの特定の要素でのみトラックされます(詳細はこちら

    LCPはChromeでしか利用できないので、他のブラウザを介してページにアクセスするユーザーが多い場合は、以下「Last Painted Hero」によるトラックを検討してみてください。

    Last Painted Hero(Synthetic)

    Last Painted Hero (LPH) とは、どのブラウザーでも測定可能な合成指標です(豆知識:最大コンテンツの表示はLast Painted Heroの影響を一部受けています)。LPHは、重要なコンテンツの最後の部分がブラウザーに描かれたタイミングを示します。重要なコンテンツがいつレンダリングされたかを知るための便利な指標です。

    操作の印象について

    ただサイトに来てもらうだけではなく、サイトを楽しんでもらいたい。そのためには、クリックすればシームレスに応答するリンクやボタン、コンテンツ – 見出し、画像、広告などがスムーズに表示されて、内容が安定されている必要があります。

    Cumulative Layout Shift(SyntheticおよびRUM)

    Cumulative Layout Shift (CLS)とは、Googleのコアウェブバイタルのひとつで、ページの読み込み時にユーザーが予期しないレイアウトのずれに遭遇する頻度を計測したスコアです。広告やカスタムフォントなどの要素は、ユーザーが読んでいるコンテンツをずらす可能性があります。CLSスコアが低いということは、そのページがユーザーから低品質と受け止められていることをあらわします。

    First Input Delay(RUM)

    First Input Delay (FID)も、コアウェブバイタルのひとつです。ユーザーによる入力(クリック、キー、タップなど)に対してページが反応するまでの時間です。トラックするには有益な指標ですが、この投稿で説明しているように、FIDはユーザーインタラクションの全てを網羅するものではないことを理解しなくてはなりません。よって、合計ブロッキング時間でそれを調整することを検討するべきなのです。

    Total Blocking Time (Synthetic)

    Total Blocking Time (TBT)とは、ブラウザーのメインスレッドが応答停止された合計時間のことで、「First Contentful Paint」と「Time to Interactive」(詳細は後述)を示します。TBTは、RUMでのみ測定可能な初回入力遅延の適切な合成プロキシと見なされているため、ラボ/合成テストにおいてGoogleが推奨するコアウェブバイタル指標の1つです。
    Web VitalsにTBTのようなCPUメトリクスが含まれているのは素晴らしいことですが、Total Blocking Timeをトラッキングする場合には、いくつかの注意点があります。それは、「長いタスク」です。

    Long Tasks(SyntheticおよびRUM)

    上記の3つの指標(CLS、FID、TBT)はすべて、Googleのコアウェブバイタルに含まれています。これらは、Chromeユーザーのパフォーマンスに焦点を当ててる場合や(当然のことながら)GoogleのSEOに関心がある場合に有効です。ただし、他のブラウザのパフォーマンスを調べる必要がある場合や前述のFIDおよびTBTの注意点を回避したい場合は、Long Tasks timeを調べる必要があります。これは、ナビゲーションの開始からページが完全に読み込まれるまでの、50ミリ秒を超えるすべてのJavaScriptタスクの合計時間です。Long Tasksの指標を追跡することで、長時間のタスクがページ全体の読み込みとユーザーに与える影響をより深く理解することができます。

    その他の指標

    以上に述べた指標は良い出発点です。ページに最適なものを特定したら、次に考慮すべき点がいくつかあります。

    Custom metrics(SyntheticおよびRUM)

    Custom metricsは高水準な指標です。W3C User Timing スペックを使用することで、特定のページ内の重要な要素にタイムスタンプを追加できます(SpeedCurveにカスタムタイマーを追加する方法はこちら)。Custom metricsを作成することで、見出しからCTA(call-to-action)ボタンまですべてをトラックできます。Twitterは、カスタムタイマーを使って、Time to First Tweet指標を作成しました。Pinterestは、Pinner WaitTime指標を作成しています。

    カスタムタイマーは素晴らしいものですが、トラッキングしたいものを特定し、タイムスタンプをページに追加するための専門知識と、継続的なメンテナンスを必要とします。それを考慮したとしても、実行するためのリソースとニーズがある場合は検討する価値はあるでしょう。

    Lighthouse scores (Synthetic)

    Google Lighthouseは、オープンソースのツールで、パフォーマンス、PWA、アクセシビリティ、ベストプラクティス、SEOのルールに照らしてページの品質をチェックします。これらのカテゴリーごとに100点満点のスコアが表示され、修正すべき点を提案してくれます。

    Lighthouseを悪用して出来の悪いページで高スコアを獲得することは可能ですが、一般的に、Lighthouseのスコア確認と監査をする方がいいでしょう。スコアを追跡してリグレッションが発生していないことを確認することは悪い考えではありません。そしてリグレッションが発生した場合は、監査を掘り下げて原因を特定しましょう。

    Third parties(Synthetic)

    多数のサードパーティが存在する場合、または潜在的に問題のあるサードパーティー(レンダリングを妨げるスクリプト)が存在する場合、サードパーティのパフォーマンス予算を設定を検討すべきです。そして特定のサードパーティーのリクエスト合計数とサイズ並びに、Long Tasks timeを追跡することが好ましいでしょう。 

    上記の例は、Long Tasksでどの程度変動が発生するかについて、驚きの結果を示しています。サイズとリクエスト数だけを見ただけでは気付かなかったことです。

    Page Size & Requests(Synthetic)

    モバイルユーザーに対して重たいページを提供することを懸念している場合(そうあるべきです)、ページサイズやリソース数などの指標を追跡することをを検討すべきです。モバイルデバイスに提供するページは1 MB未満(最大でも2 MB以下)であることが理想です。しかしながら5MBを超えるページがよく見られ、とりわけメディアサイトはこれにあたります。

    これはあるニュースサイトのモバイルホームページの指標を例です。リソースの内訳を見た結果、JS、画像、およびビデオのサイズに特定のパフォーマンス予算を設定することがのぞましいと考えられます。

    トラックする必要がなさそうな指標

    パフォーマンス指標が廃止されると、いつの間にか指標は姿を消してしまう傾向があります。そのため有用でない指標を追跡している可能性もあります。引き続き追跡すべき正当な理由があるかもしれませんが、理由がわからない場合、または他の人がやってるから自分も追跡してるだけの場合は、その理由を調べるべきです。そうでなければ、これらの指標の使用をとりやめる時期なのかもしれません。

    Speed Index(Synthetic)

    Speed Indexは、数年前に初めて登場したときには重要な指標でした。ページの可視部分が表示されたことを識別するためにアルゴリズム が使われます。これは、実際ユーザーの見ているものを測定するツールが抱える問題点に対する初の取り組みで、大きな進化を遂げました。しかし、Speed Indexはページの構築方法に依存するため、万能の指標ではないのです。例を挙げてみましょう。

    Speed Indexが決して悪い指標というわけではなく、単に最近では重要なコンテンツがページ内でレンダリングされ、ページが安定したことをを測定するためのより優れた方法が見つかったということです。

    代用となるのは、Largest Contentful PaintとCumulative Layout Shiftです。

    Load Time / Fully Loaded (SyntheticおよびRUM)

    私はパフォーマンス関連の仕事に長く携わっていますが、以前は Load Time / Fully Loaded (ロード時間/完全ロード)がユーザーエクスペリエンスの指標として有用でした。現在のようにページが何十個(時には何百個)もの分析タグ、トラッキングビーコン、その他のサードパーティでいっぱいになり、総ロード時間をに影響を及ぼす以前のことでした。

    今では、ユーザーが知覚するパフォーマンスの指標としてLoad Time / Fully Loaded の使用はお勧めしません。せいぜいわかるのは、前述のサードパーティがページのレンダリングをひどく遅らせていることくらいです。

    Visually Complete (Synthetic)

    Visually Complete とは、ビューポート内のすべてのコンテンツのレンダリングが完了し、その後、ページの読み込みが続いてもビューポート内に何も変化がない状態の時間です。Speed Indexと同様に、Visually Completeもかつて有用な指標でしたが、ページが完全にレンダリングされるまで表示されないことがあるなど(上記参照)、いくつかの欠点がありました。よって現在、より正確な指標を優先して、非推奨になりました。

    代用となるのは、Last Painted Heroです。

    First Contentful Paint & First Meaningful Paint (Synthetic)

    数年前これらの指標が発表されたとき、多くの期待がありました。ユーザーが感じるパフォーマンスを示す有望な指標のように見えたのですが、時間の経過とともに、普遍的に推奨できるほどすべてのページで一貫していないことがわかりました。私の同僚のJosephはトップランクの40サイトを分析し、FMPイベントの50%とFCPイベントの85%がレンダリング開始前に発生したことを発見しました。つまりビューポートが空の状態で発生していたのです。

    代用としては、Largest Contentful Paintまたは重要なページ要素に独自のカスタムタイマーを設定することです。

    Time to Interactive (Synthetic)

    Time to Interactive(TTI、インタラクティブになるまでの時間)の最大の問題点の1つは、多くの人が思っているような意味ではないということです。ページは、TTIが発生する前からインタラクティブである可能性があります。具体的には、TTIは5秒間の最初のスパンであり、First Contentful Paintが実行された後、ブラウザのメインスレッドが50ミリ秒以上ブロックされず、実行中のリクエストは2つ以下になります。

    (参考までに、私はこの定義を調べなければなりませんでした。これ自体がTTIのもう1つの問題であり、大半の人がいきなり説明することは不可能です。優れた指標の特徴は、定義が簡単であることです。)

    代用として、Long Tasks timeと、上記の「使用感」のセクションにあるその他の指標を使用してください。

     

    2. 予算のしきい値は何にすべきか?

    追跡すべき指標を特定した後は、その指標の予算をどうすべきかを知りたいものです。ひとつ覚えておいていただきたいことがあります。

    パフォーマンス予算とは、パフォーマンスの目標値ではありません。

    • パフォーマンス目標は理想的。最終的にどのくらいのスピードを出したいのか?
    • パフォーマンス予算は実用的。パフォーマンスの目標に向かって取り組んでいる間、サイトが遅くならないようにするにはどうすればよいか?

    重要度1:後退回避のためのパフォーマンス予算作成

    ある指標の過去2~4週間のデータを見て、最も悪い数値を特定し、その数値に対してパフォーマンスバジェットを設定するのが良い方法です。(ハリーロバーツ氏によるベストプラクティス参考)この例では、過去1か月の最悪のStart Render Time(レンダリング開始時間)は3.5秒だったので、これがパフォーマンス予算となります(グラフ赤線)。

    また、予算を設定しておけば、しきい値を超えたときアラートを送信するように設定することもできます。ページの最適化と数値の向上に取り組むときは、2~4週間ごとに予算を見直し、更新しましょう。理想的には、各指標の目標達成に向けてパフォーマンス予算がどんどん小さくなっていくことです。

    重要度2:長期目標の設定

    パフォーマンスの目標は、以下ような多数の要因により左右されます。

    競合他社はどれくらいの速さですか?

    経験則:最低でも競合他社より20%速くなることを目標にしましょう。次のような方法で競合他社の速さを知ることができます。

    ビジネス指標を改善するためにどれくらいの速さが必要か?

    ここで必要になるのが、自社のリアルユーザーデータの追跡です。パフォーマンス指標をビジネス指標にマッピングし、以下のような相関チャートを作成しましょう。これは、CLSスコアが悪化するにつれてコンバージョン率がどのように低下するかを示しています。

    SEOのためにどれくらい速くするべきか?

    Googleのコアウェブバイタルは2021年6月の検索ランキングシグナル になります。幸いなことに、Googleは目標とすべきしきい値を開示しています。

    最終的にパフォーマンス目標は何にすべきか?

    これは、一般的なベンチマークとGoogleの推奨値に基づいた、指標と目標値(パフォーマンス予算ではない)のチートシートです。これらをあくまでも出発点として、ご自身の業界や競合他社のベンチマークやデータを参考にしてください。

     

    求める状態 指標 到達目標
    読み込み状態 Backend / TTFB 0.5秒
    Start Render 2秒
    操作可能か LCP(Largest Contentful Paint ) 2.5秒
    Last Painted Hero 4秒
    操作の印象 CLS(Cumulative Layout Shift) 0.1
    FID(First Input Delay) 0.1秒
    Total Blocking Time 0.3秒
    Long Task 0.05秒

    Googleの75パーセンタイルでの各推奨値(RUMを使った場合)

     

    3.パフォーマンス予算の管理方法

    追跡すべき指標の候補リストと、使用するいくつかの数値が決まりました。ここではその他のFAQをご紹介します。

    パフォーマンス予算はシンセティックorリアルユーザーモニタリング、または両方で計測するべきか?

    理想的には、シンセティック・モニタリングsynthetic)とリアルユーザーモニタリング(RUM)の両方を使用することです。予算から何を確認したいかによりますが、両方でパフォーマンス予算を作成することができます。

    • RUMでパフォーマンス予算とアラートを設定し、合成synthetic)でドリルダウンする
      RUMと合成の両方で同じ指標(「Start Render」や「Largest Contentful Paint」など)を追跡できるチャートを作成するのがいいでしょう。指標に対してRUMバージョンの予算を作成し、予算の値から逸脱したときにアラートを受け取ります。同じチャートで合成synthetic)データを追跡しているので、簡単にドリルダウンして詳細なテスト結果や診断を得ることができます。
    • パフォーマンス予算を合成synthetic)で設定し、CI / CDプロセスと統合する
      パフォーマンス予算とアラートをCI / CDプロセスと統合することで、デプロイのたびにテストを実行し、変更が行われて予算違反が発生した場合に、アラートを送ることができます。バジェット違反があった場合は、ビルドを中断することもできます。

    すべての指標に対してパフォーマンス予算を設定するべきか?

    管理可能な数の測定基準で、小さく始めましょう。最初のうちは、いくつかの指標に絞っても問題ありません。全ての指標に対してパフォーマンス予算を設定できますが、アラートを設定する場合は、「 Backend time」、「Start Render」、「Largest Contentful Paint」などの重要な指標に絞ってアラートを設定するとよいでしょう。

    どのくらいの頻度で予算の再検討が必要か?

    上記のような実践的で反復的なアプローチをとっているなら、2~4週間ごとに予算を見直し、それに応じて(できれば下方修正して)調整してください。

     

    結論

    これから(是非)サイトのパフォーマンス指標と予算の検討を始める場合は、次のことを念頭においてください。

    1. スモールスタートで始めましょう。
      非常に多くのパフォーマンス指標が存在するので、その多さに困惑させられてしまうため。
    2. この指標を見る人の属性に合わせて指標を調整しましょう。
      誰がこのデータを見ますか?マーケティング?SEOチーム?エンジニア/開発者?ビジネス関係者?これらのグループは、それぞれ異なることに関心を持っています。各グループごとになぜその指標をトラックしているのか、そして予算の合理的根拠を理解しておく必要があります。 
    3. これらの推奨事項は出発点であり、厳格なルールはありません。
      これらの指標は、そのページに適していない可能性もあります。また、今回触れてない他の指標の方があなたのサイトに適しているかもしれません。パフォーマンス計測をさらに押し進める過程で、追跡する指標が微妙に変わってくる可能性があります。追跡を検討している指標を、合成レンダリングのフィルムストリップを介して視覚的に検証するようにしてください。
    4. 指標は常に進化しています。
      いま追跡している指標は、必ずしも1年後に追跡している指標とは限りません。それは素晴らしいことで、ページが読み込まれて以来、長い道のりを歩んできたということなのです!

     

    Tammy Everts


    ※この記事は”https://speedcurve.com/blog/performance-budgets-guide/” の英文情報を元に、内容を分かりやすく編集、翻訳した記事です。

>サイトが重い、ファーストビューが速く表示されないこんなお悩み、ご相談ください。

サイトが重い、ファーストビューが速く表示されないこんなお悩み、ご相談ください。