レンダリング・メトリックの使い方
目的:Speed Index、Start Render、 Time to First Interactiveなどのレンダリング・メトリックを理解してみましょう。
Steve Souders 2017年12月11日月曜日
「楽しいユーザーエクスペリエンス」というフレーズが好きです。 ユーザーに喜んでもらうためには、望んでいるものを速く見せる必要があります。重要なコンテンツは、ユーザーが不満を持つ前にダウンロードさせレンダリングさせることです。
ネットワークメトリックは数十年前からありますが、レンダリングメトリックは新しいものです。Speed Index、Start Render、 Time to First Interactive、これらはレンダリングメトリックの一部です。それはどういう意味ですか? どのように比較しますか?? どちらが最適ですか?
パフォーマンス指標の歴史
メトリック(指標)は、行動の状態を定量化します。パフォーマンス指標の場合、スピードとサイト構造の両面でウェブサイトの動作を把握しようとしています。
「構造」とは、HTTPリクエストの数、スタイルシートのサイズ、DOMの深さなど、サイト構築方法に関する統計を意味します。スピードとは、ウェブサイトのユーザーエクスペリエンスにおいて、いつ起こったかを捕捉するタイムベースの指標で追跡されます。Startrender、DOMインタラクティブ、Pageloadなど。構築指標」はスピード指標の変更原因を調べるのに便利です。
なぜレンダリング開始が遅くなったのですか?
あっ、ブロッキングスクリプト数が増えています!
構築指標は確立されていますが、タイムベースのパフォーマンス指標は、まだ新しく進化し続けています。 かつて、タイムベースのパフォーマンスメトリックはwindow.onloadでした(実際には、window.onloadの前に、パフォーマンス指標はHTML文書のためのHTTPリクエストの応答時間でした!)。
W3C Webパフォーマンスワーキンググループは、ナビゲーションタイミング、リソースタイミング、およびユーザータイミングの仕様をすべて変更しました。ナビゲーションのタイミングとリソースのタイミングは、メインページとページ内のすべてのリソースのDNSルックアップ、TCP接続、SSLネゴシエーションなどを測定します。
最も重要なNavigation Timingは、DOM InteractiveやDOM Completeのようなほかのマイルストーンと同様に、ページが読み込まれるタイミング(performance.timing navigationStart)などの仕様マイルストーンを提供します。 User Timingは定義済みのメトリックは含まれていませんが、代わりにperformance.markとperformance.measureを呼び出すだけで、ウェブサイト特有のマイルストーンを測るAPIを提供します。
パフォーマンス指標のギャップ
以前に述べた仕様で、 パフォーマンスを測定する能力は大幅に向上しました。それらは、実際に私たちがウェブパフォーマンスの重要な面を捕らえるのを手助けしません。2つの大きなギャップがあります。
Gap 1: ブラウザの主なスレッド
10年前のWebパフォーマンスのゲーティングファクターはネットワークでした。 現在の主なボトルネックはCPUです。 このシフト原因は、CSSやJavaScriptの増加だけでなく、モバイルユーザーの増加です。 過去7年間で、スクリプトの数は12から36に急増し、圧縮サイズは、HTTPアーカイブによる世界のトップ1000ウェブサイトでは、110Kから617Kに増加しました。
構築メトリックは、スクリプトとスタイルシートの数とサイズに関する情報を提供します。 しかし、これはJavaScriptがどのようにページに影響を与えているかの直接的な計測ではありません。 ウェブサイトにスクリプトが1つしかないと仮定すると、そのスクリプトの実行には3秒かかります。 別のWebサイトには4つのスクリプトがあるかもしれませんが、それぞれのスクリプトは0.1秒未満で実行されます。 スクリプト数は、JavaScriptがボトルネックであるかどうかの見積もりですが、実行時間に関する予測に基づいています。
各スクリプト、特にブロッキングスクリプトがブラウザーのメインスレッドで消費される時間を計測する方法があるといでしょう。 Chrome Dev Toolsにはこの情報があり、2016年に、Pat Meenanはピンクバーを使い、WebPageTestのウォーターフォールチャートを追加しました:
この例は、構築メトリックがどんな誤解を招くかを示しています。 上記のウォーターフォールの最初のスクリプトは最小なので、多くの人が最も速く実行すると思われるかもしれませんが、実際には実行にもっとも時間がかかっています。 ブラウザのメインスレッドのアクティビティに関するこの洞察は、JavaScriptの実行に限定されません。 WebPageTestは、レイアウト、ペイント、および読み込みに関する情報も提供します。
チームがCPUに集中できるように、SpeedCurveはWebPageTestからこの情報を抽出し、デフォルトのダッシュボードに表示します。
しかし、ブラウザのメインスレッドのボトルネックに関する洞察は、合成テストに限られています。 これらのメトリックがReal User Monitoring(RUM)でも利用できるように、CPU Timing仕様があれば素晴らしいでしょう。Long Tasks APIは、このギャップの対処に役立ちます。
WebPageTestには、レンダリングメトリック(およびパフォーマンス監視の他の多くの部分)のパイオニアが多数存在します。 レンダリングには次のようなものがあります。
- Speed Index は「ページの可視部分が表示される平均時間。単位はms」です。 スピードインデックスは特定のポイントインタイムではなく、代わりに集計統計であるため、これらの他の時間ベースのメトリックと比較すると意味がありません。
- Start Render 「ナビゲーションの開始から、白い部分がペインが開始されるまでの時間」である。
- Time to First Interactive (別名 Time to CPU Idle)は、「ページが最初に使用可能になると予想され、入力に応答する」ときです。 具体的には、First Contentful Paintの後にブラウザのメインスレッドが0.5秒以上ブロックされない、5秒の最初の期間です。 これはインタラクティブ性を測るもので、レンダリング指標以上のものであることに注意してください。
- Time to Consistently Interactive (別名, Time to Interactive) は、「ページが最初に使用可能になると予想され、すぐに入力に応答する」時間です。 具体的には、5秒間の最初のスパンで、ブラウザのメインスレッドは、1回目の内容のペイント後、2回以上の要求で50ms以上ブロックされません。 これはインタラクティブ性をキャプチャするだけで、レンダリングメトリック以上のものであることに注意してください。
- Visually Complete は、「表示が100%に達した最初の時間」です。
新しいPaint Timingの仕様は、2つの新しいメトリックが定義されています。 performance.getEntriesByType(“paint”):を使ってこれらの値を抽出できます。
- First Paintは「ブラウザが最初の操作の後にレンダリングした時間です。これはデフォルトの背景ペイントを除きますが、デフォルト以外の背景ペイントは含みます」
- First Contentful Paint は、「ブラウザが最初にテキスト、イメージ(背景イメージを含む)、白くないキャンバスまたはSVGをレンダリングしたとき」です。SVGとは、Scalable Vector Graphics(スケーラブル・ベクター・グラフィックス)の略で、JPEGやPNGのような画像(ビットマップデータ)ではなく、イラストレーターで扱うベクターデータです
First Contentful Paintの欠点を補うために、ChromeのLighthouseでは、プライマリコンテンツがユーザーに表示されるタイミングを計測しようとします。 この指標はChromeのトレースで確認できます。
- First Meaningful Paint は、「レイアウト上の最大のレイアウト変更が行われ、Webフォントが読み込まれた後のペイント」です。 (詳細はこちら)
SpeedCurveでは重要コンテンツがページに表示されたときを計測する新しいメトリックを作成しました。
- Hero Rendering Timesは、ビューポートで最大のイメージ、H1、および背景画像がレンダリングされるタイミングの組み合わせです。 コンポジットメトリックは、H1の時間と最大のIMG時間(最大IMGが存在しない場合は最大のバックグラウンドイメージ)の最大値を取ることによって計算されます。:max(h1、(最大値| bg_img))。
レンダリング・メトリックの評価
さまざまなレンダリングメトリックを評価するために、WebPageTestの世界WebサイトのTOP100をFilmstripに記録しました。評価ですが、よりインタラクティブ(そして面白く)にするために、レンダリングメトリックのピッカーページを作成しました。各メトリックに対応するスクリーンショットも表示されていますが、メトリック名は「優れたUX」と判断したものを選択するまで表示されません。つまり、最も連携するメトリックを追跡しています。(各フィルムストリップをクリックせずに全指標を表示したい場合は、下にスクロールして「すべて表示」をクリックしてください)。
“Xは最高のレンダリングメトリックです”と言いたいのですが、それはあなたが何に依存するかです。どのレンダリングメトリックが「良いUX」につながるレンダリングメトリックのピッキングの演習を体験できることを希望します。あなたのサイトでは、より速くコンテンツを取得するには(Start Render)。ページに多くのコンテンツを入れるときには(First Meaningful Paint, Speed Index)、重要なコンテンツが表示されるときには(Hero Rendering Times)に興味があるかもしれません。
どのレンダリング問題が最も重大かであるかに関わらず、これらのメトリックの評価には注意すべき基準がいくつかあります。
すべてのピクセルは同じ価値ですか?
優れたユーザーエクスペリエンスを提供する上で、レンダリングに重点を置くことは大切です。 SpeedCurveでは、ピクセルをただレンダリングするだけではなく、最も重要なピクセルをレンダリングすることが大切だと考えています。 ページのどの部分も同じ値ではありません。 より重要なデザイン要素 、例えば、call-to-action、Hero Imageなどがあります。 よいメトリックは、レンダリング時に最も重要なピクセルを計測できるはずです。
自動ですか? 作業が必要?
window.onloadは、最もよく使用されるパフォーマンス指標である理由は、すべてのブラウザにデフォルトで存在することです。ウェブサイトの所有者は、このメトリックを生成するために何かをする必要はありません。
一方、User Timingはチームにとって最も重要なメトリクスを与えますが、メトリクスを生成するためのコードの作成、プッシュ、メンテナンスが必要です。そのため世界のトップ50万 Webサイトの5%以下しか使用していないでしょう。他のすべてが共通なら、自動的に動作するメトリックが優先されます。
Synthetic or RUM?(合成テストか?リアルタイムユーザーモニタリングか?)
パフォーマンスメトリックは、シンセティック(合成テスト)か、またはReal User Monitoringを介して収集されます。 理想的にはメトリックが両方をサポートしてくれることです。 (注:RUMで収集できる技術は、シンセティック(合成)モニタリングが一般にJavaScriptにアクセスするため、同様にシンセティックでも役に立つと考えられます)。
次の表は、各メトリックを適切なマス目に分類しています。
作業必要 | 自動 | |
重要なピクセルを計測 | User Timing (両方)
Hero Element Timing (両方) |
Hero Rendering Times (syn) |
すべて同じピクセル | User Timing (両方) | Speed Index (syn)
Start Render (syn) Time to First Interactive (syn) Time to Consistently Interactive (syn) Visually Complete (syn) First Paint (both) First Contentful Paint (both) First Meaningful Paint (syn) |
私たちはHero Rendering Timesについて熱意をもってます。ヒューリスティックを使用して、重要なコンテンツ(H1、ヒーローイメージ、最大バックグラウンドイメージ)を見積もります。 ウェブサイトのオーナーが余分な作業をしなくても利用できるので、競合他社のウェブサイトを追跡することもできます。そして、「どのメトリックが良いUXに最も近いか」という主観的な結果では良い得点を得ます。 ただし、シンセティック(合成)モニタリングでのみで有効です。
RUMでは、有効なレンダリングメトリックはありません。 今のところ3つの選択肢があるだけです。First Paint, First Contentful Paint, User Timingです。我々のテストの結果では、First PaintとFirst Contentful Paintでは、実際の画面コンテンツにはうまくマッピングされません。
ユーザータイミングはRUMの3番目の選択肢です。 ユーザーのタイミングの良い点は、ページ内のクリティカルなコンテンツのレンダリング時間を測定するために使用できます。これはトリッキーな特殊テクニックを使用する必要があります。 さらに、First PaintとFirst Contentful Paintの場合と同様に、結果に同じようなデルタ遅延が発生する可能性があります。 (これはさらなる研究領域です。)
Hero Element Timingは、RUMレンダリングメトリックの4番目の候補ですが、初期提案の段階にあり、現在はどのブラウザでも利用できません。 また、このメトリックには以前にほかで説明したものと同じ、「デルタ遅延」が発生する可能性があります。
次はなに?
RUMのレンダリングメトリックには、やるべき作業があります。 First PaintおよびFirst Contentful Paint は、必ずしも「良いUX」(例、重要コンテンツ)に対応しません。 Hero Element Timingは、ブラウザがサポートすると、RUMの重要コンテンツを追跡するのに役に立ちます。
「意味のある」コンテンツ測定の課題は、さらなる研究領域です。 Pickerでの経験では、First Meaningful Paintはクリティカルなコンテンツがレンダリングされるポイントと、しばしば一致しません。 Hero Rendering Timesはクリティカルなコンテンツが画面に表示されたときを識別するのに優れています。しかし、欠陥がないわけではありません。 その計算は、Filmstripのスクリーンショット画像の解析に基づいています。回転するコンテンツやポップアップは難題です。同じくHero ImageとBack Ground Imageをオーバーレイする透明なH1の要素も同様です。Webサイトの所有者がコードを変更することなく、重要なコンテンツを計測するできることは、将来の仕事としてエキサイティングな目標です。
さらに長い道のりですが、 Long Tasks APIからRUMのCPU情報を取得するのが良い方法です。
これは、開発者がレンダリングメトリックが変更された理由を診断するのに役立ちます。特に場合はタイミング情報は、個々のスクリプトやスタイルシートに関連付けることができます。
このブログ記事では、レンダリングメトリックに重点を置き、インタラクティブな指標(Time to First InteractiveとTime to Consistently Interactive)に多くの時間を費やしていません。 これらのインタラクティビティ・メトリックは、レンダリングメトリックをベースラインに組み込むことが重要です。 現在、First Contentful Paintに依存していますが、他のレンダリングメトリックを考慮する必要があります。特にHero Rendering Timesは、私たちの研究ではうまくいっていました。
この記事へのコメントはありません。