プロダクトマネジャーのためのWebパフォーマンス

  • 2021年7月16日
  • 私はWebパフォーマンスに関する会話が大好きです。お相手はさまざまで、よくフロントエンド開発者やエンジニアリング責任者であることが多いのです。最近ではプロダクトリーダーとの会話も増えています。

    私の同僚のプロダクトマネジャーにも、興味を持ってもらってWebパフォーマンスの世界に引き入れたいと思っていますが、彼に対する理解のためには、もっといい会話方法があると感じていました。この記事がそのヒントとなれば幸いです。また、プロダクト管理の技術を磨く上での、Webパフォーマンスの大切な基本的事項を取り上げてみます。

    あなたがプロダクトマネジャー職であろうとなかろうと、パフォーマンスに不慣れであれば、すぐに活用できる実用ガイドをまとめてみました。

    • ページが遅くなる原因は何ですか?
    • パフォーマンスはどのように測定されますか?
    • さまざまな指標(メトリック)の意味は?
    • パーセンタイルの理解と使用方法
    • 関係者にパフォーマンスの価値を伝える方法

    ページが遅くなる原因は何ですか?

    知っておくべき重要な要素について、いくつかご紹介します。パフォーマンスは多面性を持つ生き物のようですから、異なる要素にも注意が必要です。

    リクエスト数

    Webページは、個別のアセットで構成されています。画像、フォント、JavaScript、CSS、ピクセルなどなど、これらはすべてリッチなエクスペリエンスを提供するための機能を果たしています。しかし、これらをまとめた途端に「傷だらけの死」という悲惨な結果となってしまいます。

    Steve Soudersの黄金律今でも変わりはあるません。レンダリング時間の80〜90%はフロントエンドで費やされ、大半はネットワークで送信されるリクエスト数です。サイトを最適化したいなら、まずリクエスト数をできるだけ減らすことから始めましょう。

    コード

    フロントエンド・エンジニアが学ぶべきベストプラクティスはたくさんありますが、最適化の最短ルートで実施されるのは次の典型的な作業です。推奨事項は、コンサルタントによる監査やLighthouse(もちろんSpeedCurve)のような自動計測ツールからも得られます。

    私は、お客様のURLをチェックする際にPageSpeed Insightsを使って、提案をすることが好きです。Lighthouseのスコアと監査は、SpeedCurve製品にも含まれており、良い出発点となります。

    問題の範囲としては次です。

    • JavaScript
    • 「クリティカルパス」やレンダリングブロックの改善
    • ディレクティブを使用してアセットをプリロードするか、スクリプトを非同期にしてロードする

    多くの場合、焦点はフロントエンドエンジニアに向けられる傾向がありますが、開始時のレンダリング時間が通常よりも長くなったり、最初の読み込み時間が増加となる数値が表れた場合は、バックエンド側にも目を向けましょう。

    画像

    画像最適化は、パフォーマンスを大幅に向上させる手法の1つです。画像圧縮は進化し続けています。帯域幅を最小限に抑えながら豊富な機能を提供する新しいフォーマットも登場しています。場合によっては、これらの形式はブラウザ固有のものであるため、作業範囲が複雑になります。

    影響を与えるかどうかについては、自社管理か外部管理かにかかわらず、画像のパイプラインを理解しておくことは大切です。特に、大規模な製品カタログを扱うサイトや、ユーザー生成コンテンツが多くあるサイトでは、その傾向が顕著です。

    また、画像の最適化によるパフォーマンス向上は、すべての指標(メトリック)に反映されるわけではありません。しかし、帯域幅が不十分であったり、データプランが制限されているユーザーにとってはありがたいことです。画像に関するパフォーマンス予算(パフォーマンスバジェット)は、期間ではなくサイズとリクエスト数で設定するようにしてください。

    ネットワーク

    インターネットには、一貫性はありません。A地点からB地点に到達する仕組みは、回線を介するビット送信の複雑さを考えると、いまだに驚くばかりです。

    Akamai、Fastly、Cloudflare、Cloudfrontなどのコンテンツ・デリバリー・ネットワーク(CDN)の採用は、パフォーマンスに大きな影響を与えることがあります。

    CDNは、以前はバックエンドの時間に表れていたものですが、最近では、アセットデリバリー(画像、静的コンテンツ)やEdgeサーバーで利用する高度な最適化では、フロントエンド側にも大きな影響を与えている可能性があります。一方で改善ばかりではなく、これらのプラットフォームは、場合により事態を悪化させることもあります。

    サードパーティ

    嫌われるのが好きなんです。しかし、愛用しています。あらゆる場所で。

    サードパーティタグとは、コンテンツ充実策やリコメンドなどのサービス、広告を配信したりする自社ドメイン外の機能のことです。

    サードパーティへの不満は、サードパーティが自分のコントロールの範囲外にあると認識されることが多いからです。確かに、サードパーティがパフォーマンスに影響を与える場合、タグを削除したり、キルスイッチを入れる以外に、処理速度を上げる方法はありません。

    とはいえ、あなたはプロダクトマネジャーです。自分がコントロールできる範囲外のものに影響を与える達人です。彼らに責任を負わせ、彼らを維持するための戦略を立てることもできます。たとえば、これです。

    ベンダーマネジャーがいる場合は、その人と協力するか、責任者であるステークホルダーと協力して、サードパーティにパフォーマンス予算を設定するようにします。責任者と一緒に実行できるタグ予算を作成することもできます。予算は規模に関連するかもしれません。

    マーケティング部門が、新しい画像を追加する必要がある場合は、それを強制的に置き換えます。サードパーティを監査し、ゴーストスクリプトを排除します。

    新しいサードパーティを許可する前に、検証プロセスを実装して、パフォーマンスに関する基本のガイドラインを満たすことを確認します。私のお気に入りのツールはNic Jansmaが提供している3rdParty.ioです。

    パフォーマンス問題の原因が何であれ、問題に取り組む際には「チームとしてのアプローチをする」ことが重要です。誰か1人が原因でパフォーマンスが低下しているということはまずありません。また、1人のユーザーまたはグループがその分野のオーナーとなったとしても、ほかのユーザーとは関係なく解決できるということも稀です。パフォーマンス改善はチームスポーツなのです。

    パフォーマンスはどのように計測されますか?

    主に2つの方法があります。どちらもユーザーがサイトにアクセスした際に、ブラウザがどう反応するかを測定します。

    シンセティック(合成)モニタリング

    シンセティック=合成とは、本物ではありません。シンセティック・モニタリングとは、基本的に指示したこと(「Xの場所からXブラウザでホームページにアクセスしてください」)を実行し、パフォーマンスデータを積極的に収集するボットのことです。

    シンセティックの素晴らしさは、そのアクションが実行されたときに何が起こったかについて多くのデータ収集ができます。

    これには以下が含まれます。

    • 各リクエストの詳細を示すウォーターフォールチャート
    • レンダリング体験を視覚化するためのフィルムストリップやビデオ
    • アプリケーションの構成を見る際に、ベースライン

    シンセティックは、特に速度に大きな影響を与えるリクエスト(画像、JavaScript、CSS)の数やサイズを調べるときなど、時間経過に伴う状況分析に最適です

    しかし、シンセティック・モニタリングには、エンドユーザーという要素が欠けています。そこでRUMが注目されます。

    リアルユーザモニタリング(RUM)

    リアルユーザーの計測についてです。RUMとは、実際のエンドユーザーブラウザを訪れ、そこで計測されるパフォーマンス分析と考えてください。

    プロダクトマネジャーとして、あなたはすでに自社製品を外部構築することに注力していることとします。膨大な数のお客様と話し、フィードバックを得て、それを次の製品要件に反映させるのです。これにより、エキサイティングなロードマップを作成したり、製品やそのラインのビジョンを作成するときに、チーム全体で広く共感力が得られます。

    これが、RUMが必要な理由です。リアルユーザー。リアルな体験。RUMは、ウェブパフォーマンスを理解するための基礎であり、パフォーマンスを関係者に伝える際の重要な情報源となります。RUMがなければ、パフォーマンスを仕様要件として効果的に盛り込むことはできません。

    とはいえこれは難しい話です。実際、いまの時代は、RUMデータをプランニングに組み入れないのは、パフォーマンスに関する不正行為とも言えます。

    さまざまな指標(メトリック)の意味は?

    シンセティックでもRUMでも、各ツールは数多くのパフォーマンス・メトリクスを取得します。どのパフォーマンス・メトリクスに注目すべきかは、長年にわたる大変な道のりでした。その傾向は「すべてを測定しつくす」から「ユニコーン指標は注力」に変わっていきます。今はその中間です。しかし「どの指標(メトリック)を重視すべきか」は、いまだに苛立たしい問題です。

    メトリック(指標)は無数にありますが、すべてを理解する必要はありません。パフォーマンスを始めたばかりの方は、ユーザーのエクスペリエンスに最も近い指標に焦点を当ててください。これに正面から取り組んだTammyの素晴らしいガイドがあります。

    ここ数ヶ月、プロダクトマネジャーとの会話はCore Web Vitalsに集中しています。SEOの改善やGoogle Consoleに表示される数字に関する質問への対応にプレッシャーを感じているのであれば、これらの指標について理解しておきたいところです。幸いなことに、コアウエブバイタルについては多くの資料がありますので、ご覧ください。

    • コアウェブバイタルの追跡
    • Cumulative Layout Shift(CLS)の理解
    • First Input Delay(FID)の重要性とは?
    • Core Web Vitalsについてわかっていること(Simon Hearne著)

    パーセンタイルの理解とその使用方法

    さまざまなメトリック(指標)を理解した後は、各指標に対して、パーセンタイルを適用する方法を学び、実際のユーザーのいくつかのグループが、どのようにサイト体験しているかを理解することが重要です。

    これはヒストグラムです。

    ヒストグラムは、あなたのサイトを訪れた際に様々な経験をしたユーザーの分布を表します。

    パフォーマンスは分布であり、ひとつの数値ではありません。また一度だけ計測されるものでもありません。ヒストグラムは経験の連続性を表し、パフォーマンスの形とそれにどのように影響を与えたかを考えることができます。速くなると左に、遅くなると右にシフトします。

    数字を伝える必要性。どうすればいいのですか?

    数字で説明する必要があります。パーセンタイルは、0~100の母集団のセグメントを表します。統計学者でなくても、次のように考えてください。

    50パーセンタイル (中央値) :50パーセンタイル (中央値) を使うと、理解しやすく、コミュニケーションしやすくなります。必要に応じて、平均値と呼ぶこともできます。

    75パーセンタイルCore Web Vitalsなどの一部の一般的な指標では、75パーセンタイルがレポートに使用されます。

    95パーセンタイル:サイトがすでにほとんどのユーザーにとってかなり高速である場合は、ロングテールの高速化に注力することができます。ユーザーの5%は大したことがないように聞こえるかもしれませんが、月に1000万人の訪問者があるとすれば、そのうち50万人が本当にひどい体験をしているということになります。

    どのパーセンタイルに注目すべきかについては、それぞれにメリットがあり、間違った答えはありません。ただし、人口を表すために算術平均(従来の平均値)を使って母集団を表現している場合は除きます。この種の分布では、従来の平均値はあまりうまく機能しません。

    関係者にパフォーマンスを伝える方法

    関係者にパフォーマンスを伝える方法は、プロダクトマネジャーが直面する最大の課題の1つだと思います。私たちは何年もこの課題に取り組んできましたが、まだ解決していません。ここでは、コミュニケーションについて、いくつかの考え方をご紹介します。

    オーディエンスを知る

    新しい概念ではありません。機能横断的な仕事をする際には、新しい用語やコンセプトを導入して経営者と議論することになりますが、その前に、次を考えてみてください。

    シンプルであること

    多くの情報で相手を混乱させないようにしましょう。パフォーマンスKPIを中心にレポートを作成しているのであれば、それは素晴らしいことです。また、ユニコーン指標で調整ができているのならばそれもいいでしょう。ただし、あまり飾りすぎないようにしましょう。

    パーセンタイルのような用語は使わず、2つの数字のセットを提示するのは避けましょう。プロダクトマネジャーが陥りがちな間違いの1つに、RUM指標とシンセティック指標の両方を伝えようとすることです。これはダメです。

    繰り返しですが、可能な限りRUMを使用してください。シンセティックデータでは、ページウェイトやリクエスト数など、そのエリアを強調したり、サイト上のサードパーティの数を示したりすることができます。つまりシンセティックデータがRUMデータをうまく補完してくれることになります。

    パフォーマンスのイメージを描く

    シンセティックモニタリングツールの出番はここからです。パフォーマンスに疎いステークホルダーに説明するとき、フィルムストリップやビデオを使ってポイントを説明すると、非常に効果的です。またチームの素晴らしい仕事ぶりをアピールするのにも、動画でビフォー・アフターを見せるのが一番です。

    自分をベンチマークする

    もうひとつ便利なのが、ベンチマーキングです。チームは勝つことが好きで、負けることが嫌いです。ベンチマークを利用して自社サイトと競合サイトを比較することは非常に効果的です。これは、Core Web Vitalsの管理に関しても、特に当てはまります。競合他社の半数が自社よりもLCPタイムが早かった場合、SEOの検索結果にどのような影響があるでしょうか。

    難しいかもしれませんが、あなたが最下位であろうと競争相手が最下位であろうと、それはいつでも変化してしまいます。ベンチマークは、自分自身を向上させるため、あるいは他者を理解し学ぶために活用しましょう。ベンチマークを使用する方法については、「Industry Page Speed Benchmarks」をご覧ください

    サマリー

    サマリーは基本中の基本です。これを読むことで時間を有効に活用することができるでしょう。プロダクトマネジャーとして触れるあらゆるトピックと同様に、いつでも深く掘り下げることができます。

     


    ※この記事はSpeedCurve社の英文情報を元に、内容を分かりやすく編集、翻訳した記事です。

    Copyright © 2021 SpeedCurve Limited. All Rights Reserved.

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

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