Web Performance Budget: 設定、計算、適用する方法

公開: 2023-03-09

Web パフォーマンスの最適化は、何度も行ったり来たりして、難しい場合があります。

訪問者の要求が非常に大きくなり、なんと 53% もの訪問者が 3 秒以内に読み込まれない Web サイトを放棄してしまうため、オンライン ビジネスの所有者は、90 以上のスピード スコアだけに頼ってコンバージョン率を上げ続けることはできません。

Web パフォーマンスの予算を入力してください。Web サイトを成功に導くための最も過小評価されている戦略です。

次の行では、以下について説明します。

  • Web パフォーマンスの予算とは?
  • Web パフォーマンス バジェットの利点は何ですか?
  • パフォーマンス バジェットの指標の選択
  • 完全に開発された Web サイトの指標に優先順位を付ける
  • Web パフォーマンスの予算を設定する方法
  • ウェブのパフォーマンスを監視し、それに応じて予算を調整します

Web 開発者、デザイナー、ビジネス オーナーのいずれであっても、このガイドは Web サイトのパフォーマンスを次のレベルに引き上げるのに役立ちます。

始めましょう！

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

Web パフォーマンス バジェットは、Web サイトが最適な速度と効率を維持するために維持する必要がある事前定義された一連の制限です。 これらの制限には次のものがあります。

  • ハード リソース キャッピング
  • 総ページ重量の目標
  • HTTP リクエストの総数
  • モバイル ネットワークでのページの最小読み込み時間
  • Core Web Vitals 指標 (LCP など)のしきい値

パフォーマンス バジェットを設定して監視することで、ビジネス オーナー、UX デザイナー、および開発者は、相互のパフォーマンス目標に同意して取り組むことができます。 このように、すべてのコラボレーションの取り組みは、優れたユーザー エクスペリエンスとさらに優れたビジネス指標を目指しています。

NitroPack で Core Web Vitals を自動的に改善 →

Web パフォーマンス バジェットの利点は何ですか?

Web パフォーマンス バジェットが非常に効果的である理由は、サイトをリグレッションから保護する (またはリグレッションをより効果的に検出するのに役立つ) ためです。 やがてパフォーマンスの低下に気付き始めた場合は、手順をたどり、テストを実行し、トラブルシューティングをはるかに迅速に行うことができます。

さらに、Web リソースの使用制限を設定します。

  • チームがテクノロジー、さまざまなアプローチ、フレームワーク、および機能を比較および評価できるようにします
  • リソース支出の傾向を予測し、より良い計画に役立てるために使用できます (つまり、通常よりもはるかに早く予算を費やす月について)。
  • また、開発および UX デザインの弱点を示唆することもできます (つまり、大きなライブラリや Web フォントの代替手段を見つけること)。

️ パフォーマンス バジェットは拡張可能なものと見なされるべきではなく、ユーザー エクスペリエンスと引き換えに費やされる「お金」と見なされるべきです。 他の予算と同じように、目標は制限内に収まるように最善を尽くし、制限を増やすことに依存しないことです。 長期的には、これによりより多くのリソースが節約され、ユーザー エクスペリエンスの向上に向けてより合理化されたプロセスが確立されます。

しかし、どこから始めるかをどのように決定しますか?

まず、Web パフォーマンス バジェットで対象とすることができる指標の種類をよりよく理解する必要があります。


パフォーマンス バジェットの指標の選択

これらの指標は、予算とサイトのパフォーマンスの向上がどれほど効果的かを測定するための目標と考えてください。

Web パフォーマンスの予算編成に使用される指標の種類は次のとおりです。

  • ルールベース
  • 時間ベース
  • 数量ベース
  • カスタム

1. ルールベースの指標

これらは、WebPageTest、Lighthouse、Google PageSpeed Insights など、すべての一般的なツールで見られるサイト パフォーマンス スコアのまとめです。

NitroPack パフォーマンス スコア

全体的なスコアは、時間ベースの指標と数量ベースの指標の両方に基づいています (詳細については後で説明します)。

一般的なパフォーマンスと速度を追跡するのに優れているだけでなく、レポートの結果は、最初の予算の確固たるガイドラインになります。 より具体的なカスタム指標に進む前に、それらを使用して、何を目指しているかをよりよく理解してください。

ヒント: Lighthouse および Google PageSpeed Insights レポートで改善のためのヒントと推奨事項を確認することを忘れないでください。


2. 時間ベースの指標

マイルストーン メトリックとも呼ばれ、ページの読み込み速度と、読み込み中に正確に何が起こるかを評価するために使用されます。 レポートでは、これらは Core Web Vitals と呼ばれるユーザー パフォーマンスの指標です。

PSI Core Web Vitals 評価

Speed Index や負荷イベントとは異なり、Core Web Vitals は、時間ベースのしきい値の形で実際のユーザーが Web サイトをどのように体験しているかを包括的に理解するのに役立ちます。

以下は、パフォーマンス バジェットに追加する最も重要なマイルストーン メトリックです。

最初のコンテンツ ペイント (FCP)
 FCP は、ブラウザーが DOM ツリーからコンテンツ (画像、テキストなど) の最初のビットを表示するのにかかる時間を測定します。これがページの読み込みの開始になります。

最初のコンテンツ ペイントのしきい値


対話までの時間 (TTI)
 TTI は、ページが完全にインタラクティブになり、ユーザー入力に応答するまでにかかる時間を測定することに専念しています。

注: 2023 年 2 月の最新の Lighthouse 10 アップデートの時点で、Time to Interactive は正式に削除されました。 10% だった TTI のスコアの重みは現在、Cumulative Layout Shift (CLS) に転送され、全体的なパフォーマンス スコアの重みが 25% に増加しています。


ただし、これは、たとえば Google PageSpeed Insights のパフォーマンス レポートから TTI が削除されるという意味ではありません。 しかし、それが予算に追加する価値がある指標であるかどうかを検討する必要があるかもしれない明確なヒントです。


最大コンテンツ ペイント (LCP)
 LCP は、ページが最大のテキストまたは画像要素をレンダリングするのにかかる時間を測定します。 これはユーザー中心であり、結局のところ Google に好まれているため、パフォーマンス バジェットで使用するのに最適な指標です。

コンテンツフル ペイントの最大しきい値


最初の入力遅延 (FID)
 FID は、ページがリンクのクリックやボタンのタップなどのユーザー インタラクションに応答するのにかかる時間を測定します。ユーザーの入力に応答するために、ページが関連するスクリプトと情報を読み込む準備ができているかどうかを把握します。

最初の入力遅延しきい値


総ブロッキング時間 (TBT)
 前述のように、TBT は TTI に関連していますが、LCP と組み合わせると、ユーザーが Web サイトをどのように認識しているかをより正確に把握できます。 TBT は、Web ページがブロックされ、ユーザーが Web ページを操作できなくなった時間を測定します。

合計ブロッキング時間のしきい値


3. 数量ベース

ウェブサイト開発の開始時に導入しやすい数量ベースの指標は、サイトが最適なパフォーマンスを得るために使用するリソースの数に直接リンクします。

制限を設定する最も一般的なリソースは次のとおりです。

  • 言語とスタイルのサイズ (HTML と CSS)
  • メディア コンテンツのサイズ (画像、動画)
  • フォントサイズ
  • スクリプトサイズ
  • ページの総重量
  • HTTP リクエストの総数

数量ベースの指標

新しいプロジェクトの開始時にこれらの指標がより有益である理由は、重いイメージやスクリプトがパフォーマンスに与える影響をチームが判断するのに役立つからです。 ただし、サイトの速度の問題に苦しんでいる場合は、いくつかの数量ベースの指標を導入すると、削除 (または置換) するページ要素をより簡単に選択できるようになります。

ご存知ですか: デスクトップのページ重量の中央値は 10 年間で 221% 増加し、モバイルではなんと 594% も増加しました。 この進行中の傾向は、Web パフォーマンスの弱点と、サイト所有者が予算内でページの重みを優先して最適化する機会を明らかにしています。

ページ重量の中央値

4. カスタム指標

Twitter などのチームは、「最初のツイートまでの時間」などのカスタム指標を設定しています。 もう 1 つの一般的なカスタム指標は、「Time to Hero Element」です。 Web サイトで最も重要なインタラクションが何であるか、およびそれがビジネスにどの程度固有であるかに応じて、Web パフォーマンス予算で追跡することを検討することをお勧めします。

ヒント: 予算内で追跡することを決定した指標は、ユーザーが Web サイトをどのように体験するかに直接関係している必要があります。 たとえば、テキスト コンテンツが支配的な発行 Web サイトを所有している場合、ビデオ サイズの最大値を追加しても意味がありません。 代わりに、LCP、最大 Web フォント サイズ、「H1 タイトルの読み込み時間」などのカスタム メトリックなどのメトリックに焦点を当てることができます。

NitroPack で 90 以上のスピード スコアを達成し、Core Web Vitals に合格 →

完全に開発された Web サイトの指標に優先順位を付ける

本番環境の Web サイトでパフォーマンス予算のしきい値を決定するのは難しい場合があります。

最善の方法は、現在の状況から始めることです。 あなたの主なタスクは、後退を防ぎ、将来の目標を1つずつ調整することです.

大きなパフォーマンスの問題が見つかった場合は、最適化を実装した後、Web サイトへのより大きな変更を検討し、予算をさらに引き下げる必要がある場合があります。

現在の地位を評価する方法、何を目指すべきか、Web パフォーマンス指標を改善する方法については、以下をお読みください。


Web パフォーマンスの予算を設定する方法

すべてのウェブサイトには競争力にとって重要なさまざまな要件があるため、最初のタスクは、それらがウェブ パフォーマンス、より具体的にはユーザー エクスペリエンスとどのように関係しているかを理解することです。


1.競合他社を調査する

速度とユーザー エクスペリエンスの点で類似の Web サイトがどのように機能するかを観察すると、次のことが役立ちます。

  • 彼らが得意なことを理解する
  • それらを超えることができる領域を特定する
  • より現実的なパフォーマンス目標と予算制限を構築する

競争を追い越すことは、一度きりのプッシュではなく、継続的なプロセスと考えてください。 これが、サイトの機能を危険にさらすことなく競争上の優位性を得る可能性を比較検討する必要がある理由です。

あなたのウェブサイトに似たウェブサイトを見つけるには、いくつかの方法があります。

  • related:"keyword"で Google で検索
  • SimilarWeb などのサービスを使用します (無料版は制限がありますが、最初のリストを作成するのに便利です)。

Google検索

確実な競合分析を行うために、少なくとも 10 の類似した Web サイトを見つけてください。

Google PageSpeed Insights などのパフォーマンス計算ツールを使用して、競合他社のターゲット ページ (ホーム、製品、機能、ブログなど) を実行します。

Guardian Core Web Vitals レポート

ガーディアンのパフォーマンススコア

次に、競合他社のすべてのパフォーマンス メトリック値をグラフに一覧表示することができます。

WebPageTest や Google PageSpeed Insights などのツールを使用して、BBC がデスクトップ上の The Guarding や Daily Mail と比較する方法を示すサンプル チャートを作成しました。

グラフの例

*免責事項: 上記のグラフの例にある指標の組み合わせは、Web サイトの種類、競合他社、およびこの業界でそのような企業が目指す可能性のある優先事項に基づいて選択されています。 すべてのケースは具体的であり、これらのメトリックは、確固たる理由なしに複製されるべきではありません。

デイリー メールが同じ調査を行った場合、スピード インデックスのギャップを埋めるために、予算に合わせてスピード関連および数量ベースの指標をすべて計画する必要があります。

競合他社に対する顕著な変化については、予算を設定するときにいつでも 20% ルールを参照できます (つまり、競合他社よりも 20% 優れた値が必要です)。

競合他社に追いつくことができなくても、それはあなたの努力が訪問者の全体的なユーザー エクスペリエンスを改善していないという意味ではないことに注意してください。 1 秒ごとに読み込み時間が短縮されるということは、デスクトップでのコンバージョン率が 7%、モバイルで最大 27% 増加することを意味します。


2. Web パフォーマンスのベースラインを作成する

信頼できる基準点を作成するには、WebPageTest や Lighthouse などのツールを使用して、比較的安定した測定を行います。 ブラウザの組み込みツールでテストする前に、ブラウザのキャッシュをクリアすることを忘れないでください。 Clear Cache Chrome 拡張機能を使用して、プロセスを高速化します。

すべての Web ページに対して監査を実行する必要はありません。 最も多くのトラフィックを引き付けることがわかっている (または予測される) 最も重要なものから始めます。

リストを完成させるのに役立つプロンプトの例を次に示します。

  • ページの重量をできるだけ小さく維持するために、Web サイトにアップロードする画像の最大サイズ (圧縮前または圧縮後)
  • 各ページの最大合計ページ重量
  • ページごとに許可される HTTP リクエストの総数
  • 特定のスピード インデックスを達成するためのしきい値
  • JavaScript、CSS、Web フォントなどのセグメント化されたスクリプトの制限
  • 合計読み込み時間は X 秒 (またはミリ秒) 以下です
  • Google フォント、ローカル フォント、またはシステム フォント (より良い結果を得るためにそれらを最適化する方法をお読みください)

️ Strategy Analyticsによると、モバイル ユーザーの総数の 46% が 2G または 3G を使用しています。 より低速なネットワーク (3G など) で Web ページをテストして、人々が Web サイトをどのように体験するかについてより現実的な概要を把握してください。


3. パフォーマンス予算を計算して設定する (+ 例)

パフォーマンスの予算を立てるために優先したページの種類によって、指標の値は異なります。

以下に、開始できるいくつかの例を示します。

  • ページの読み込み時間は 3 秒未満
  • 170KB 未満のクリティカル パス リソース (圧縮/縮小)
  • Lighthouse スコアが 80 を超える

予算を無料で設定できる優れたツールは、Performance Budget Calculator です。 アセットまたは CWV ベースの予算を選択して、設定するメトリック値を指定し、Google Lighthouse で使用できる形式でダウンロードします。

より管理しやすい上限から始めることをお勧めします。 初期予算は「現在のベースラインより 20% 速く」なる可能性があります。 最適化する際に、「上位の競合他社よりも 20% 速い」などのより厳しいしきい値を目指すことができます。

BBCのパフォーマンスバジェット


4. パフォーマンス バジェットを実装する

この手順はより技術的なものになることに注意してください。適切な構成については、開発者に依頼することをお勧めします。

Google Lighthouse は、Lighthouse v5+ のコマンドライン バージョンで利用可能な機能 LightWallet を介してパフォーマンス バジェットをサポートします。

予算を作成するには、DebugBear による次の例に従って、budget.json という名前のファイルと JSON を開く必要があります。

[
 {
 "タイミング": [
 {
 "metric": "first-contentful-paint",
 "予算": 1500
 }、
 {
 "metric": "largest-contentful-paint",
 「予算」：5000
 }
 ]、
 "resourceSizes": [
 {
 "resourceType": "合計",
 "予算": 2000
 }
 ]、
 "resourceCounts": [
 {
 "resourceType": "フォント",
 「予算」：5
 }、
 {
 "resourceType": "合計",
 「予算」：100
 }
 ]
 }
 ]

もちろん、パフォーマンス バジェットを決定したメトリックと値に置き換える必要があります。

Lighthouse を実行して予算を渡します。 その後、ライトハウスのパフォーマンス セクションの下部に、予算を設定した各指標の値が表示されます。 予算のしきい値を超えると、通知が届きます。

Lighthouse ウォレットのパフォーマンス バジェット

ビルド プロセスに Web パフォーマンス バジェットを追加するために、いくつかのオープンソース ツールを確認できます。

  • Webpack (パフォーマンス機能)
  • バンドルサイズ
  • 灯台CI

ウェブのパフォーマンスを監視し、それに応じて予算を調整します

少なくとも月に 1 回 (またはしきい値を超えたという通知を受け取るたびに) パフォーマンス レポートを再確認することの重要性はいくら強調してもしすぎることはありません。

予算を抑え、ユーザー エクスペリエンスを犠牲にしないようにするために、次のことができます。

  • 既存の Web サイト インフラストラクチャ、機能、および開発の決定を最適化する
  • 良いことよりも悪いことをする既存のプラグインやサイトの機能を無効にする (または置き換える)
  • 新しい機能 (またはサードパーティのソリューション) をまったく追加しないことを決定する

️ 適用する各サイト パフォーマンスの最適化は、Core Web Vitals の結果に登録されるまでに少なくとも 28 日間必要です。


パフォーマンス バジェットを超えるとどうなりますか?
 予算はボトルネックになることを意図したものではなく、パフォーマンスやユーザー エクスペリエンスの問題を防ぐためにアクションが必要であることを示しています。

パフォーマンスの予算を超えた場合はいつでも、あなたとあなたのチームは次のことを決定できます。

  • 簡単な修正を適用する (つまり、ある種のリソース最適化)
  • 新しい開発の初期段階に戻る (つまり、重要ではないサードパーティのスクリプトを削除する)
  • そのままにしておきますが、将来の最適化を別の場所でスケジュールします
  • パフォーマンスがわずかに低下する代わりに、予算を増やしてください

どのようなアプローチをとろうとも、パフォーマンスの向上について継続的に考え、レポート、分析、計算に基づいて意識的な意思決定を行うことが最終的な目標です。

少なくとも 4 つの最適化プラグインを NitroPack に置き換えます – 35 以上の強力な機能を備えた軽量ソリューション →


それを奪う

Web パフォーマンスの予算には、デザイナー、開発者、マーケティング担当者、および利害関係者による長期的な取り組みが必要であり、優れたユーザー エクスペリエンスが優先されます。

これは、ウェブサイトを開発する初期段階でも、オンライン ビジネスの成長段階でも重要です。 適切に設定して最適化することで、Web パフォーマンス バジェットはより良い意思決定、ベンチマーク、そして最終的にはビジネス KPI を可能にします。