フロントエンドパフォーマンス2021：計画とメトリクス

このガイドは、フロントエンドのパフォーマンスモニタリング、セッションの再生、および製品分析を組み合わせて、より良いカスタマーエクスペリエンスを構築するのに役立つ、LogRocketの友人から親切にサポートされています。 LogRocketは、主要なメトリックを追跡します。 DOM完了、最初のバイトまでの時間、最初の入力遅延、クライアントのCPUとメモリの使用量。 今すぐLogRocketの無料トライアルを入手してください。

目次

1. 準備：計画と指標
   パフォーマンス文化、コアWebバイタル、パフォーマンスプロファイル、CrUX、Lighthouse、FID、TTI、CLS、デバイス。
2. 現実的な目標の設定
   パフォーマンスバジェット、パフォーマンス目標、RAILフレームワーク、170KB / 30KBバジェット。
3. 環境の定義
   フレームワーク、ベースラインパフォーマンスコスト、Webpack、依存関係、CDN、フロントエンドアーキテクチャ、CSR、SSR、CSR + SSR、静的レンダリング、事前レンダリング、PRPLパターンの選択。
4. 資産の最適化
   Brotli、AVIF、WebP、レスポンシブ画像、AV1、アダプティブメディアローディング、ビデオ圧縮、Webフォント、Googleフォント。
5. ビルドの最適化
   JavaScriptモジュール、モジュール/モジュールなしパターン、ツリーシェイク、コード分割、スコープホイスト、Webpack、ディファレンシャルサービング、Webワーカー、WebAssembly、JavaScriptバンドル、React、SPA、部分的なハイドレーション、相互作用のインポート、サードパーティ、キャッシュ。
6. 配信の最適化
   遅延読み込み、交差オブザーバー、レンダリングとデコードの延期、重要なCSS、ストリーミング、リソースヒント、レイアウトシフト、サービスワーカー。
7. ネットワーキング、HTTP / 2、HTTP / 3
   OCSPステープリング、EV / DV証明書、パッケージング、IPv6、QUIC、HTTP / 3。
8. テストとモニタリング
   監査ワークフロー、プロキシブラウザ、404ページ、GDPR Cookie同意プロンプト、パフォーマンス診断CSS、アクセシビリティ。
9. クイックウィン
10. 1ページのすべて
11. チェックリストをダウンロードする（PDF、Apple Pages、MS Word）
12. 次のガイドを見逃さないように、メールマガジンを購読してください。

準備：計画と指標

マイクロ最適化はパフォーマンスを軌道に乗せるのに最適ですが、明確に定義された目標を念頭に置くことが重要です。これは、プロセス全体で行われる決定に影響を与える測定可能な目標です。 いくつかの異なるモデルがあり、以下で説明するモデルはかなり意見が分かれています。早い段階で独自の優先順位を設定してください。

1. パフォーマンス文化を確立します。
   多くの組織では、フロントエンド開発者は、根本的な一般的な問題が何であるか、およびそれらを修正するためにどの戦略を使用する必要があるかを正確に知っています。 ただし、パフォーマンスカルチャーの確立された承認がない限り、各決定は部門の戦場になり、組織をサイロに分割します。 ビジネスの利害関係者の賛同が必要であり、それを取得するには、ケーススタディ、または速度（特に、後で詳しく説明するコアWebバイタル）がメトリックと主要業績評価指標にどのように役立つかについての概念実証を確立する必要があります。 （ KPI ）彼らは気にします。

   たとえば、パフォーマンスをより具体的にするために、コンバージョン率とアプリケーションの負荷までの時間の相関関係、およびレンダリングパフォーマンスを示すことで、収益パフォーマンスへの影響を明らかにすることができます。 または、検索ボットのクロール率（PDF、27〜50ページ）。

   開発/設計チームとビジネス/マーケティングチームの間に強力な連携がなければ、パフォーマンスは長期的に維持されません。 カスタマーサービスとセールスチームに寄せられる一般的な苦情を調査し​​、高いバウンス率とコンバージョンの低下に関する分析を調査します。 パフォーマンスの向上がこれらの一般的な問題のいくつかを軽減するのにどのように役立つかを探ります。 話している利害関係者のグループに応じて、議論を調整します。

   モバイルとデスクトップの両方で（たとえば、Google Analyticsを使用して）パフォーマンス実験を実行し、結果を測定します。 これは、実際のデータを使用して会社に合わせたケーススタディを構築するのに役立ちます。 さらに、WPO Statsで公開されたケーススタディと実験のデータを使用すると、パフォーマンスが重要である理由、およびパフォーマンスがユーザーエクスペリエンスとビジネスメトリックにどのような影響を与えるかについて、ビジネスの感度を高めるのに役立ちます。 ただし、パフォーマンスだけが重要であると述べるだけでは不十分です。測定可能で追跡可能な目標を設定し、それらを長期にわたって観察する必要もあります。

   そこに着く方法？ 長期的なパフォーマンスの構築に関する彼女の講演で、Allison McKnightは、Etsyでのパフォーマンス文化の確立にどのように貢献したかについての包括的なケーススタディを共有しています（スライド）。 最近では、タミー・エヴァーツが、小規模組織と大規模組織の両方で非常に効果的なパフォーマンスチームの習慣について話しました。

   組織でこれらの会話をしている間、UXがさまざまなエクスペリエンスであるように、Webパフォーマンスは分散であることに留意することが重要です。 Karolina Szczurが指摘したように、「単一の数値が目指すべき評価を提供できると期待することは、欠陥のある仮定です」。 したがって、パフォーマンスの目標は、きめ細かく、追跡可能で、具体的である必要があります。

1. 目標：最速の競合他社よりも少なくとも20％速くなります。
   心理学の調査によると、自分のWebサイトが競合他社のWebサイトよりも高速であるとユーザーに感じてもらいたい場合は、少なくとも20％高速である必要があります。 主な競合他社を調査し、モバイルとデスクトップでのパフォーマンスに関する指標を収集し、競合他社を上回るのに役立つしきい値を設定します。 ただし、正確な結果と目標を得るには、まず分析を調べて、ユーザーのエクスペリエンスの全体像を把握するようにしてください。 次に、90パーセンタイルのテストの経験を模倣できます。

   競合他社のパフォーマンスの第一印象を良くするために、Chrome UXレポート（ CrUX 、既製のRUMデータセット、Ilya Grigorikによるビデオ紹介、Rick Viscomiによる詳細ガイド）、またはRUM監視ツールであるTreoを使用できます。 ChromeUXレポートを利用しています。 データはChromeブラウザのユーザーから収集されるため、レポートはChrome固有のものになりますが、さまざまな訪問者にパフォーマンス、最も重要なのはCore WebVitalsスコアをかなり完全に分散させることができます。 新しいCrUXデータセットは、毎月第2火曜日にリリースされることに注意してください。

   または、次を使用することもできます。

   • AddyOsmaniのChromeUXレポート比較ツール、
   • スピードスコアカード（収益への影響の見積もりも提供します）、
   • 実際のユーザーエクスペリエンステストの比較または
   • SiteSpeed CI（合成テストに基づく）。

   注：Page SpeedInsightsまたはPageSpeed Insights APIを使用している場合（非推奨ではありません！）、集計だけでなく、特定のページのCrUXパフォーマンスデータを取得できます。 このデータは、「ランディングページ」や「商品リスト」などのアセットのパフォーマンス目標を設定するのに非常に役立ちます。 また、CIを使用して予算をテストしている場合、ターゲットの設定にCrUXを使用した場合は、テストした環境がCrUXと一致することを確認する必要があります（ Patrick Meenanに感謝します）。

   速度の優先順位付けの背後にある理由を示すために何らかの支援が必要な場合、またはパフォーマンスの低下に伴うコンバージョン率の低下またはバウンス率の増加を視覚化したい場合、あるいは組織内のRUMソリューションを提唱する必要がある場合はSergey Chernyshevは、UX Speed Calculatorを構築しました。これは、データをシミュレートして視覚化し、ポイントを推進するのに役立つオープンソースツールです。

   

   

   CrUXからのデータを、速度低下、盲点、非効率性が存在する場所で、競合他社やプロジェクトのために、すでに迅速に解決する必要のある他のデータと組み合わせて、もう少し深く掘り下げたい場合があります。 彼の仕事では、ハリー・ロバーツはサイトスピード地形スプレッドシートを使用しており、これを使用して主要なページタイプごとにパフォーマンスを分類し、それらの間でさまざまな主要なメトリックがどのようにあるかを追跡しています。 スプレッドシートは、Googleスプレッドシート、Excel、OpenOfficeドキュメント、またはCSVとしてダウンロードできます。

   

   また、最後までやりたい場合は、サイトのすべてのページで（Lightouse Paradeを介して）Lighthouseパフォーマンス監査を実行し、出力をCSVとして保存できます。 これは、競合他社のどの特定のページ（またはページの種類）のパフォーマンスが悪いか良いか、そして何に集中したいかを特定するのに役立ちます。 （自分のサイトの場合は、分析エンドポイントにデータを送信する方がおそらく良いでしょう！）

   

   データを収集し、スプレッドシートを設定し、20％削減し、この方法で目標（パフォーマンス予算）を設定します。 これで、テストするための測定可能なものができました。 予算を念頭に置いて、対話するまでの時間を短縮するために最小限のペイロードだけを出荷しようとしている場合は、合理的な道を進んでいます。

   始めるためのリソースが必要ですか？

   • Addy Osmaniは、パフォーマンスの予算編成を開始する方法、新機能の影響を定量化する方法、および予算を超過した場合にどこから開始するかについて、非常に詳細な記事を書いています。
   • パフォーマンスバジェットを使用して設計にアプローチする方法に関するLaraHoganのガイドは、設計者に役立つ指針を提供します。
   • ハリーロバーツは、リクエストマップを使用して、パフォーマンスに対するサードパーティのスクリプトの影響を表示するGoogleスプレッドシートの設定に関するガイドを公開しました。
   • JonathanFieldingのPerformanceBudget Calculator、Katie Hempeniusのperf-budget-calculator、およびBrowser Caloriesは、予算の作成に役立ちます（Karolina Szczurの頭を上げてくれてありがとう）。
   • 多くの企業では、パフォーマンスの予算は野心的なものではなく、実際的なものである必要があり、特定のポイントを超えないようにするための保持の兆候として機能します。 その場合、過去2週間で最悪のデータポイントをしきい値として選択し、そこから取得することができます。 パフォーマンスバジェットは、それを達成するための戦略を実践的に示しています。
   • また、ビルドサイズを報告するグラフを使用してダッシュボードを設定することにより、パフォーマンスバジェットと現在のパフォーマンスの両方を表示します。 それを実現できるツールはたくさんあります。SiteSpeed.ioダッシュボード（オープンソース）、SpeedCurve、Calibreはそのほんの一部であり、perf.rocksでさらに多くのツールを見つけることができます。

   

   予算を設定したら、Webpack Performance HintsとBundlesize、Lighthouse CI、PWMetrics、またはSitespeed CIを使用してビルドプロセスに組み込み、プルリクエストに予算を適用し、PRコメントでスコア履歴を提供します。

   チーム全体にパフォーマンスバジェットを公開するには、Lightwalletを介してLighthouseにパフォーマンスバジェットを統合するか、LHCIアクションを使用してGithubアクションをすばやく統合します。 また、カスタムが必要な場合は、エンドポイントのAPIであるwebpagetest-charts-apiを使用して、WebPagetestの結果からグラフを作成できます。

   ただし、パフォーマンスの認識は、パフォーマンスの予算だけから得られるべきではありません。 Pinterestと同じように、依存関係が多く、バンドルを肥大化させることがわかっているファイルやディレクトリからのインポートを禁止するカスタムeslintルールを作成できます。 チーム全体で共有できる「安全な」パッケージのリストを設定します。

   また、ビジネスにとって最も有益な重要な顧客タスクについて考えてください。 重要なアクションの許容可能な時間しきい値を調査、議論、定義し、組織全体が承認した「UX対応」のユーザータイミングマークを確立します。 多くの場合、ユーザージャーニーは多くの異なる部門の作業に影響を与えるため、許容可能なタイミングに関する調整は、今後のパフォーマンスに関する議論をサポートまたは防止するのに役立ちます。 追加されたリソースと機能の追加コストが表示され、理解されていることを確認してください。

   構築中の製品の新機能からリファクタリング、新しいグローバルオーディエンスへのリーチに至るまで、パフォーマンスへの取り組みを他の技術イニシアチブと連携させます。 したがって、さらなる開発についての会話が行われるたびに、パフォーマンスもその会話の一部になります。 コードベースが新しい場合、またはリファクタリングされている場合は、パフォーマンスの目標を達成するのがはるかに簡単です。

   また、Patrick Meenanが示唆したように、設計プロセス中にロードシーケンスとトレードオフを計画することは価値があります。 どの部分がより重要であるかを早期に優先し、それらが表示される順序を定義すると、何が遅れるかもわかります。 理想的には、その順序はCSSとJavaScriptのインポートの順序も反映するため、ビルドプロセス中のそれらの処理が容易になります。 また、ページがロードされている間（たとえば、Webフォントがまだロードされていないとき）の「中間」状態でのビジュアルエクスペリエンスを検討してください。

   組織で強力なパフォーマンス文化を確立したら、時間の経過とともに優先順位を維持するために、以前の自分よりも20％速くなることを目指します（ Guy Podjarnyに感謝します）。 ただし、ボットのトラフィックと季節性の影響に加えて、顧客のさまざまなタイプと使用行動（Tobias Baldaufはケイデンスとコホートと呼んでいます）を考慮してください。

   計画、計画、計画。 早い段階でいくつかの迅速な「手に負えない果物」の最適化に取り掛かるのは魅力的かもしれません—そしてそれは迅速な勝利のための良い戦略かもしれません—しかし、現実的な会社を計画して設定することなしにパフォーマンスを優先することは非常に難しいでしょう-調整されたパフォーマンス目標。

1. 適切な指標を選択してください。
   すべてのメトリックが等しく重要であるわけではありません。 アプリケーションにとって最も重要なメトリックを調べます。通常、インターフェイスの最も重要なピクセルのレンダリングを開始できる速度と、レンダリングされたピクセルに入力応答性を提供できる速度によって定義されます。 この知識は、継続的な取り組みのための最良の最適化目標を提供します。 結局のところ、エクスペリエンスを定義するのはロードイベントやサーバーの応答時間ではなく、インターフェイスがいかにスッキリしているのかという認識です。

   どういう意味ですか？ （たとえば、 onLoadやDOMContentLoadedのタイミングを介して）ページ全体の読み込み時間に焦点を合わせるのではなく、顧客が認識しているようにページの読み込みを優先します。 これは、わずかに異なる一連のメトリックに焦点を当てることを意味します。 実際、適切なメトリックを選択することは、明らかな勝者がいないプロセスです。

   TimKadlecの調査と彼の講演でのMarcosIglesiasのメモに基づいて、従来のメトリックはいくつかのセットにグループ化できます。 通常、パフォーマンスの全体像を把握するには、それらすべてが必要です。特定のケースでは、それらの一部が他よりも重要になります。

   • 数量ベースのメトリックは、リクエストの数、重み、およびパフォーマンススコアを測定します。 アラームを鳴らしたり、時間の経過とともに変化を監視したりするのには適していますが、ユーザーエクスペリエンスを理解するのにはあまり適していません。
   • マイルストーンメトリックは、読み込みプロセスの存続期間中の状態を使用します。たとえば、最初のバイトまでの時間やインタラクティブまでの時間などです。 ユーザーエクスペリエンスとモニタリングを説明するのには適していますが、マイルストーン間で何が起こっているのかを知るのにはあまり適していません。
   • レンダリングメトリックは、コンテンツのレンダリング速度の見積もりを提供します（たとえば、レンダリング開始時間、速度インデックス）。 レンダリングパフォーマンスの測定と調整には適していますが、重要なコンテンツが表示されて操作できるタイミングの測定にはあまり適していません。
   • カスタムメトリックは、ユーザーの特定のカスタムイベントを測定します。たとえば、Twitterの最初のツイートまでの時間やPinterestのPinnerWaitTimeなどです。 ユーザーエクスペリエンスを正確に説明するのには適していますが、指標をスケーリングしたり、競合他社と比較したりするのにはあまり適していません。

   全体像を完成させるために、私たちは通常、これらすべてのグループの中で有用な指標を探します。 通常、最も具体的で関連性のあるものは次のとおりです。

   • インタラクティブまでの時間（TTI）
     レイアウトが安定し、主要なWebフォントが表示され、ユーザー入力を処理するのに十分なメインスレッドが利用可能になるポイント（基本的には、ユーザーがUIを操作できる時間マーク）。 ユーザーがラグなしでサイトを使用するためにどれだけの待機を経験する必要があるかを理解するための主要なメトリック。 Boris Schapiraは、TTIを確実に測定する方法に関する詳細な投稿を書いています。
   • First Input Delay （FID） 、または入力応答性
     ユーザーが最初にサイトを操作してから、ブラウザーが実際にその操作に応答できるようになるまでの時間。 TTIを非常によく補完し、画像の欠落している部分、つまりユーザーが実際にサイトを操作したときに何が起こるかを説明します。 RUMメトリックとしてのみ意図されています。 ブラウザでFIDを測定するためのJavaScriptライブラリがあります。
   • 最大のコンテンツフルペイント（LCP）
     ページの重要なコンテンツが読み込まれた可能性が高い、ページの読み込みタイムラインのポイントをマークします。 ページの最も重要な要素は、ユーザーのビューポートに表示される最大の要素であると想定されています。 要素が折り目の上と下の両方にレンダリングされる場合、表示されている部分のみが関連性があると見なされます。
   • 合計ブロッキング時間（ TBT ）
     ページが確実にインタラクティブになる前に、ページがどの程度非インタラクティブであるかを定量化するのに役立つメトリック（つまり、メインスレッドに50ミリ秒を超えるタスク（長いタスク）が少なくとも5秒間実行されていない）。 このメトリックは、最初のペイントから、入力の応答性を妨げるのに十分な時間メインスレッドがブロックされたInteractiveまでの時間（TTI）までの合計時間を測定します。 したがって、低いTBTが良好なパフォーマンスの良い指標であることは不思議ではありません。 （ありがとう、Artem、Phil）
   • 累積レイアウトシフト（ CLS ）
     このメトリックは、ユーザーがサイトにアクセスするときに予期しないレイアウトシフト（リフロー）を経験する頻度を強調しています。 不安定な要素と、それらが全体的なエクスペリエンスに与える影響を調べます。 スコアが低いほど良いです。
   • スピードインデックス
     ページコンテンツが視覚的に入力される速度を測定します。 スコアが低いほど良いです。 速度指数スコアは視覚的な進行速度に基づいて計算されますが、これは単なる計算値です。 また、ビューポートサイズにも影響されるため、ターゲットオーディエンスに一致するさまざまなテスト構成を定義する必要があります。 LCPがより適切なメトリックになるにつれて、重要性が低下していることに注意してください（ Boris、Artemに感謝します）。
   • 費やしたCPU時間
     メインスレッドがブロックされ、ペイント、レンダリング、スクリプト作成、および読み込みに取り組んでいる頻度と期間を示すメトリック。 CPU時間が長いことは、ユーザーエクスペリエンスが不安定であることを明確に示しています。つまり、ユーザーがアクションと応答の間に顕著な遅延を経験した場合です。 WebPageTestを使用すると、[Chrome]タブで[Capture Dev Tools Timeline]を選択して、WebPageTestを使用する任意のデバイスで実行されるメインスレッドの内訳を表示できます。
   • コンポーネントレベルのCPUコスト
     費やしたCPU時間と同様に、Stoyan Stefanovによって提案されたこのメトリックは、JavaScriptがCPUに与える影響を調査します。 アイデアは、コンポーネントごとのCPU命令数を使用して、全体的なエクスペリエンスへの影響を個別に理解することです。 PuppeteerとChromeを使用して実装できます。
   • FrustrationIndex
     上記の多くのメトリクスは特定のイベントがいつ発生するかを説明していますが、Tim VereeckeのFrustrationIndexは、メトリクスを個別に見るのではなく、メトリクス間のギャップを調べます。 タイトルが表示され、最初のコンテンツが表示され、視覚的に準備ができており、ページが準備ができているなど、エンドユーザーが認識した主要なマイルストーンを確認し、ページの読み込み中のフラストレーションのレベルを示すスコアを計算します。 ギャップが大きいほど、ユーザーがイライラする可能性が高くなります。 ユーザーエクスペリエンスに適したKPIになる可能性があります。 Timは、FrustrationIndexとその仕組みに関する詳細な投稿を公開しています。
   • 広告の重量への影響
     あなたのサイトが広告によって生み出された収入に依存しているなら、広告関連のコードの重みを追跡することは役に立ちます。 Paddy Gantiのスクリプトは2つのURL（1つは通常のURL、もう1つは広告をブロックする）を作成し、WebPageTestを介してビデオ比較の生成を促し、デルタを報告します。
   • 偏差メトリック
     ウィキペディアのエンジニアが指摘しているように、結果にどの程度の分散が存在するかというデータは、機器の信頼性、および偏差とアウトラーにどれだけ注意を払う必要があるかを示します。 大きな変動は、セットアップで必要な調整の指標です。 また、サードパーティのスクリプトが大幅な変動を引き起こしているなどの理由で、特定のページを確実に測定することがより困難であるかどうかを理解するのにも役立ちます。 また、新しいブラウザバージョンが公開されたときのパフォーマンスの向上を理解するために、ブラウザのバージョンを追跡することもお勧めします。
   • カスタムメトリック
     カスタムメトリックは、ビジネスニーズとカスタマーエクスペリエンスによって定義されます。 重要なピクセル、重要なスクリプト、必要なCSS、および関連するアセットを特定し、それらがユーザーに配信されるまでの時間を測定する必要があります。 その場合は、Hero Rendering Timesを監視するか、Performance APIを使用して、ビジネスにとって重要なイベントの特定のタイムスタンプをマークできます。 また、テストの最後に任意のJavaScriptを実行することで、WebPagetestを使用してカスタムメトリックを収集できます。

   First Meaningful Paint （FMP）は、上記の概要には表示されないことに注意してください。 これは、サーバーがデータを出力する速度についての洞察を提供するために使用されていました。 長いFMPは通常、JavaScriptがメインスレッドをブロックしていることを示していますが、バックエンド/サーバーの問題にも関連している可能性があります。 ただし、このメトリックは、約20％のケースで正確ではないように見えるため、最近非推奨になりました。 これは、より信頼性が高く、推論が容易なLCPに効果的に置き換えられました。 Lighthouseではサポートされなくなりました。 安全なページにいることを確認するために、最新のユーザー中心のパフォーマンスメトリックと推奨事項を再確認してください（ありがとう、Patrick Meenan ）。

   

   Steve Soudersは、これらの指標の多くについて詳細に説明しています。 Time-To-Interactiveは、いわゆるラボ環境で自動監査を実行することによって測定されますが、First Input Delayは実際のユーザーエクスペリエンスを表し、実際のユーザーは顕著な遅延を経験していることに注意してください。 一般に、常に両方を測定して追跡することをお勧めします。

   アプリケーションのコンテキストに応じて、推奨されるメトリックは異なる場合があります。たとえば、Netflix TV UIの場合、キー入力の応答性、メモリ使用量、TTIがより重要であり、Wikipediaの場合、最初/最後の視覚的変更とCPU時間の消費メトリックがより重要です。

   注：FIDとTTIはどちらも、スクロール動作を考慮していません。 スクロールはメインスレッドから外れているため、独立して発生する可能性があります。そのため、多くのコンテンツ消費サイトでは、これらのメトリックはそれほど重要ではない可能性があります（ありがとう、Patrick！ ）。

1. Core WebVitalsを測定して最適化します。
   長い間、パフォーマンスメトリックは非常に技術的であり、サーバーの応答速度とブラウザの読み込み速度のエンジニアリングビューに焦点を当てていました。 指標は何年にもわたって変化しており、サーバーのタイミングではなく、実際のユーザーエクスペリエンスをキャプチャする方法を見つけようとしています。 2020年5月、GoogleはCore Web Vitalsを発表しました。これは、ユーザーに焦点を当てた新しいパフォーマンス指標のセットであり、それぞれがユーザーエクスペリエンスの異なる側面を表しています。

   それぞれについて、Googleは許容可能な速度目標の範囲を推奨しています。 この評価に合格するには、すべてのページビューの少なくとも75％が適切な範囲を超えている必要があります。 これらの指標はすぐに注目を集め、2021年5月にコアウェブバイタルがGoogle検索のランキングシグナルになり（ページエクスペリエンスランキングアルゴリズムの更新）、多くの企業がパフォーマンススコアに注目しています。

   これらの指標を念頭に置いてエクスペリエンスを最適化するための便利なテクニックとツールとともに、各コアWebバイタルを1つずつ分解してみましょう。 （この記事の一般的なアドバイスに従うことで、Core Web Vitalsのスコアが向上することに注意してください。）

   • 最大のコンテンツフルペイント（ LCP ）<2.5秒。
     ページの読み込みを測定し、ビューポート内に表示される最大の画像またはテキストブロックのレンダリング時間を報告します。 したがって、LCPは、サーバーの応答時間の遅延、CSSのブロック、実行中のJavaScript（ファーストパーティまたはサードパーティ）、Webフォントの読み込み、高価なレンダリングまたはペイント操作、遅延など、重要な情報のレンダリングを延期するすべての影響を受けます。 -ロードされた画像、スケルトン画面、またはクライアント側のレンダリング。
     
     良い経験のために、LCPはページが最初にロードを開始したときから2.5秒以内に発生するはずです。 つまり、ページの最初に表示される部分をできるだけ早くレンダリングする必要があります。 そのためには、テンプレートごとに調整された重要なCSSが必要になり、 <head>の順序を調整し、重要なアセットをプリフェッチします（後で説明します）。

     LCPスコアが低い主な理由は、通常、画像です。 十分に最適化されたサーバーでホストされ、クライアント側のレンダリングなしですべて静的で、専用の画像CDNからの画像を使用して、Fast 3Gで2.5秒未満でLCPを配信するには、理論上の最大画像サイズが約144KBにすぎないことを意味します。 そのため、レスポンシブ画像が重要であり、重要な画像を早期にプリロードします（ preloadを使用）。

     クイックヒント：ページ上でLCPと見なされるものを見つけるには、DevToolsで、パフォーマンスパネルの[タイミング]の下にあるLCPバッジにカーソルを合わせることができます（ありがとう、Tim Kadlec ！）。

   • 最初の入力遅延（ FID ）<100ms。
     UIの応答性を測定します。つまり、ブラウザがタップやクリックなどの個別のユーザー入力イベントに反応する前に、他のタスクでビジー状態だった時間を測定します。 これは、特にページのロード中にメインスレッドがビジーであることに起因する遅延をキャプチャするように設計されています。
     
     目標は、すべてのインタラクションで50〜100ミリ秒以内にとどまることです。 そこに到達するには、長いタスクを特定し（メインスレッドを50ミリ秒以上ブロックする）、それらを分割し、バンドルを複数のチャンクにコード分割し、JavaScriptの実行時間を短縮し、データフェッチを最適化し、サードパーティのスクリプト実行を延期する必要があります、JavaScriptをWebワーカーのバックグラウンドスレッドに移動し、プログレッシブハイドレーションを使用してSPAのリハイドレーションコストを削減します。

     クイックヒント：一般に、より良いFIDスコアを取得するための信頼できる戦略は、大きなバンドルを小さなバンドルに分割し、ユーザーが必要なときに必要なものを提供することでメインスレッドの作業を最小限に抑えることです。これにより、ユーザーの操作が遅れることはありません。 。 これについては、以下で詳しく説明します。

   • 累積レイアウトシフト（ CLS ）<0.1。
     UIの視覚的な安定性を測定して、スムーズで自然な相互作用を保証します。つまり、ページの存続期間中に発生するすべての予期しないレイアウトシフトのすべての個々のレイアウトシフトスコアの合計です。 個々のレイアウトシフトは、すでに表示されている要素がページ上の位置を変更するたびに発生します。 コンテンツのサイズと移動距離に基づいてスコアが付けられます。
     
     したがって、シフトが表示されるたびに（たとえば、フォールバックフォントとWebフォントのフォントメトリックが異なる場合、広告、埋め込み、iframeが遅れる場合、画像/動画のサイズが予約されていない場合、CSSが遅れて再描画を強制する場合、または変更が挿入される場合）後期JavaScript—CLSスコアに影響を与えます。 優れたエクスペリエンスの推奨値は、CLS <0.1です。

   Core Web Vitalsは、予測可能な年間サイクルで、時間の経過とともに進化することになっていることに注意してください。 初年度のアップデートでは、First ContentfulPaintがCoreWeb Vitalsに昇格し、FIDしきい値が低くなり、シングルページアプリケーションのサポートが向上することを期待している可能性があります。 また、セキュリティ、プライバシー、およびアクセシビリティ（！）の考慮事項とともに、負荷が増加した後のユーザー入力への応答が表示される場合があります。

   Core Web Vitalsに関連して、調べる価値のある有用なリソースや記事がたくさんあります。

   • Web Vitals Leaderboardを使用すると、モバイル、タブレット、デスクトップ、および3Gと4Gでの競合とスコアを比較できます。
   • Core SERP Vitalsは、Google検索結果にCrUXのCore WebVitalsを表示するChrome拡張機能です。
   • シンプルなGIF（コマンドラインからも利用可能）でCLSを視覚化するレイアウトシフトGIFジェネレーター。
   • web-vitalsライブラリは、Core Web Vitalsを収集して、Google Analytics、Google Tag Manager、またはその他の分析エンドポイントに送信できます。
   • WebPageTestを使用したWebVitalsの分析では、PatrickMeenanがWebPageTestがコアWebVitalsに関するデータを公開する方法を調査します。
   • Core Web Vitalsを使用した最適化、Addy Osmaniによる50分のビデオで、eコマースのケーススタディでCore WebVitalsを改善する方法を紹介しています。
   • 実際の累積レイアウトシフトと実世界の累積レイアウトシフトは、Nic Jansmaによる包括的な記事であり、CLSに関するほとんどすべてと、バウンス率、セッション時間、レイジクリックなどの主要な指標との相関関係について説明しています。
   • JavaScriptで要求/呼び出されたときに、プロパティまたはメソッドの概要を含むリフローを強制するもの。これにより、ブラウザーがスタイルとレイアウトを同期的に計算します。
   • CSSトリガーは、どのCSSプロパティがレイアウト、ペイント、コンポジットをトリガーするかを示します。
   • レイアウトの不安定性の修正は、WebPageTestを使用してレイアウトの不安定性の問題を特定して修正するためのウォークスルーです。
   • 累積レイアウトシフト、レイアウト不安定性メトリック、CLSに関するBoris Schapiraによる別の非常に詳細なガイド、計算方法、測定方法、および最適化方法。
   • コアWebバイタルを改善する方法、各メトリック（FCP、TTI、TBTなどの他のWebバイタルを含む）の発生時期と測定方法に関するSimonHearneによる詳細ガイド。

   では、Core Web Vitalsは従うべき究極の指標ですか？ 完全ではありません。 それらは、Cloudflare、Treo、SpeedCurve、Calibre、WebPageTest（すでにフィルムストリップビューにあります）、Newrelic、Shopify、Next.js、すべてのGoogleツール（PageSpeed Insights、Lighthouse + CI、Search）を含むほとんどのRUMソリューションとプラットフォームで実際に公開されていますコンソールなど）および他の多く。

   ただし、Katie Sylor-Millerが説明しているように、Core Web Vitalsの主な問題のいくつかは、クロスブラウザーのサポートがないことです。ユーザーエクスペリエンスのライフサイクル全体を実際に測定しているわけではありません。さらに、FIDの変化と相関関係を関連付けることは困難です。ビジネス成果のあるCLS。

   Core Web Vitalsの進化を期待する必要があるため、パフォーマンスの観点から自分の立場をよりよく理解するために、常にWebVitalsをカスタム調整されたメトリックと組み合わせるのが合理的であるように思われます。

2. オーディエンスを代表するデバイスでデータを収集します。
   正確なデータを収集するには、テストするデバイスを徹底的に選択する必要があります。 ほとんどの企業では、これは分析を調べ、最も一般的なデバイスタイプに基づいてユーザープロファイルを作成することを意味します。 しかし、多くの場合、分析だけでは全体像を把握することはできません。 ターゲットオーディエンスのかなりの部分が、エクスペリエンスが遅すぎるという理由だけでサイトを放棄している（そして戻ってこない）可能性があり、その理由で、デバイスが分析で最も人気のあるデバイスとして表示される可能性は低いです。 したがって、ターゲットグループ内の一般的なデバイスについてさらに調査を行うことをお勧めします。

   IDCによると、2020年には世界的に、出荷されたすべての携帯電話の84.8％がAndroidデバイスです。 平均的な消費者は2年ごとに電話をアップグレードし、米国では電話の交換サイクルは33か月です。 世界中で最も売れている平均的な電話の価格は200ドル未満です。

   したがって、代表的なデバイスは、少なくとも24か月経過し、200ドル以下のコストで、低速の3G、400msのRTT、400kbpsの転送で動作するAndroidデバイスですが、少し悲観的です。 もちろん、これはあなたの会社にとっては非常に異なるかもしれませんが、それはそこにいる大多数の顧客の十分に近い近似です。 実際、ターゲット市場の現在のAmazonベストセラーを調べるのは良い考えかもしれません。 （ポインターをくれたTim Kadlec、Henri Helvetica、Alex Russellに感謝します！ ）

   

   その場合、どのテストデバイスを選択しますか？ 上で概説したプロファイルによく適合するもの。 少し古いMotoG4 / G5 Plus、ミッドレンジのSamsungデバイス（Galaxy A50、S8）、Nexus 5X、Xiaomi Mi A3、Xiaomi RedmiNoteなどの優れた中道デバイスを選択することをお勧めします7とAlcatel1XやCubotX19のような遅いデバイス、おそらくオープンデバイスラボ。 低速のサーマルスロットルデバイスでテストする場合は、Nexus4を入手することもできます。価格は約100ドルです。

   また、各デバイスで使用されているチップセットを確認し、 1つのチップセットを過剰に表現しないでください。数世代のSnapdragonとApple、およびローエンドのRockchip、Mediatekで十分です（ありがとう、Patrick！） 。

   手元にデバイスがない場合は、スロットルされたCPU（5倍の速度低下）を使用してスロットルされた3Gネットワ​​ーク（たとえば、300ms RTT、1.6 Mbpsダウン、0.8 Mbpsアップ）でテストすることにより、デスクトップでモバイルエクスペリエンスをエミュレートします。 最終的には、通常の3G、低速4G（たとえば、170ms RTT、9 Mbpsダウン、9Mbpsアップ）、およびWi-Fiに切り替えます。 パフォーマンスへの影響をより明確にするために、火曜日に2Gを導入したり、オフィスにスロットルされた3G / 4Gネットワ​​ークをセットアップしてテストを高速化することもできます。

   モバイルデバイスでは、デスクトップマシンと比較して4倍から5倍の速度低下が予想されることに注意してください。 モバイルデバイスには、さまざまなGPU、CPU、メモリ、およびさまざまなバッテリー特性があります。 そのため、平均的なデバイスのプロファイルを適切に作成し、そのようなデバイスで常にテストすることが重要です。



幸いなことに、データの収集を自動化し、これらの指標に従ってWebサイトのパフォーマンスを経時的に測定するのに役立つ多くの優れたオプションがあります。 優れたパフォーマンスの全体像は、一連のパフォーマンスメトリック、ラボデータ、およびフィールドデータをカバーしていることに注意してください。

• 合成テストツールは、事前定義されたデバイスとネットワーク設定（ Lighthouse 、 Calibre 、 WebPageTestなど）を使用して、再現可能な環境でラボデータを収集します。
• Real User Monitoring （ RUM ）ツールは、ユーザーの操作を継続的に評価し、フィールドデータを収集します（例： SpeedCurve 、 New Relic —ツールは総合的なテストも提供します）。

前者は、製品での作業中にパフォーマンスの問題を特定、切り分け、修正するのに役立つため、開発中に特に役立ちます。 後者は、ユーザーが実際にサイトにアクセスしたときに、ライブで発生しているパフォーマンスのボトルネックを理解するのに役立つため、長期的なメンテナンスに役立ちます。

ナビゲーションタイミング、リソースタイミング、ペイントタイミング、ロングタスクなどの組み込みのRUM APIを利用することで、合成テストツールとRUMを組み合わせて、アプリケーションのパフォーマンスの全体像を把握できます。 Calibre、Treo、SpeedCurve、mPulse、Boomerang、Sitespeed.ioを使用できます。これらはすべて、パフォーマンス監視に最適なオプションです。 さらに、Server Timingヘッダーを使用すると、バックエンドとフロントエンドのパフォーマンスをすべて1か所で監視することもできます。

注：たとえば、DevToolsは実装方法が原因でHTTP / 2プッシュとのやり取りに問題があるため、ブラウザーの外部でネットワークレベルのスロットルを選択する方が常に安全です（ありがとう、Yoav、Patrick ！）。 Mac OSの場合、Network Link Conditioner、Windows Windows Traffic Shaper、Linux netem、およびFreeBSDdummynetを使用できます。

Lighthouseでテストする可能性が高いため、次のことができることに注意してください。

• Lighthouse CIを使用して、Lighthouseスコアを経時的に追跡します（非常に印象的です）。
• GitHub ActionsでLighthouseを実行して、すべてのPRと一緒にLighthouseレポートを取得します。
• サイトのすべてのページで（Lightouse Paradeを介して）Lighthouseパフォーマンス監査を実行し、出力をCSVとして保存します。
• 詳細を調べる必要がある場合は、Lighthouse ScoresCalculatorとLighthouseメトリックウェイトを使用してください。
• LighthouseはFirefoxでも利用できますが、内部ではPageSpeed Insights APIを使用し、ヘッドレスChrome79ユーザーエージェントに基づいてレポートを生成します。

1. テスト用に「クリーン」プロファイルと「顧客」プロファイルを設定します。
   パッシブモニタリングツールでテストを実行している間は、ウイルス対策とバックグラウンドCPUタスクをオフにし、バックグラウンド帯域幅転送を削除し、ブラウザ拡張機能を使用せずにクリーンなユーザープロファイルでテストして、結果の偏りを回避するのが一般的な戦略です（FirefoxおよびChrome）。

   

   ただし、顧客が頻繁に使用するブラウザ拡張機能を調べて、専用の「顧客」プロファイルでテストすることもお勧めします。 実際、一部の拡張機能はアプリケーションのパフォーマンスに大きな影響を与える可能性があり（2020 Chrome拡張機能パフォーマンスレポート）、ユーザーがそれらを頻繁に使用する場合は、事前に説明することをお勧めします。 したがって、「クリーンな」プロファイルの結果だけでは楽観的すぎて、実際のシナリオではつぶれる可能性があります。

2. パフォーマンスの目標を同僚と共有します。
   今後の誤解を避けるために、パフォーマンスの目標がチームのすべてのメンバーによく知られていることを確認してください。 設計、マーケティング、またはその間のすべての決定にはパフォーマンスへの影響があり、チーム全体に責任と所有権を分散させることで、後でパフォーマンスに焦点を当てた決定を合理化できます。 パフォーマンスバジェットおよび初期に定義された優先順位に対して設計上の決定をマップします。

目次

1. 準備：計画と指標
2. 現実的な目標の設定
3. 環境の定義
4. 資産の最適化
5. ビルドの最適化
6. 配信の最適化
7. ネットワーキング、HTTP / 2、HTTP / 3
8. テストとモニタリング
9. クイックウィン
10. 1ページのすべて
11. チェックリストをダウンロードする（PDF、Apple Pages、MS Word）
12. 次のガイドを見逃さないように、メールマガジンを購読してください。