機能の実裝を正當化するためのグローバルブラウザーの使用統(tǒng)計のみに焦點を當てることは誤解を招きます。本當に重要なのは、特定のWebサイトでのブラウザの使用法であり、大幅に異なる場合があります。この原則は、単に古いブラウザと互換性のない機能を避けるだけでなく、単に拡張されています。これは、サイトの成功に直接関連するメトリックに優(yōu)先順位を付けることです。

サイト固有のパフォーマンス追跡のこの概念は、最近私の頭に浮かびました。レガシーブラウザーのサポートのために、CSSグリッドを避けることだけではありません。それは、あなたのユーザーに本當に影響を與えるメトリックを測定することです。

パフォーマンステストは、多くの場合、合成テストに依存しています。このテストでは、自動ブラウザがサイトをロードし、資産サイズ、負荷時間、リクエストカウントなどのメトリックを記録します。便利ですが、このデータは実際のユーザーエクスペリエンスを反映していません。 JavaScriptのバンドルサイズ、最大のコンテンツフルペイント（LCP）、およびLighthouseスコアに取りつかれていますが、これらはユーザー認識の直接的な測定ではなく、プロキシです。

Google Analyticsのような典型的なWebサイト分析を検討してください。ページの人気、セッション期間、トラフィックソースに関するデータを提供している間、この情報は非常に一般的なままです。

本當に洞察力に富んだ分析には、よりターゲットを絞ったアプローチが必要です。自問してみてください：サイトのパフォーマンスの特定の側(cè)面は重要ですか？機能Xはどのくらいの頻度で使用されますか？毎週いくつのファイルがアップロードされますか？いくつのメッセージが送信されますか？星ボタンはどのくらいの頻度でクリックされますか？これらの質(zhì)問は、このデータをキャプチャして報告するカスタムJavaScriptの必要性を強調(diào)しています。一般的な分析ツールでは十分ではありません。積極的な開発が必要です。

この原則は、パフォーマンスツールにも當てはまります。一般的な合成テストのみに依存する代わりに、実際のユーザー監(jiān)視（RAM）を採用します。実際のデバイスで実際のユーザーを追跡し、非常に貴重な洞察を得ます。このアプローチは、焦點を絞った分析のロジックと完全に一致し、重要なデータのロックを解除します。

たとえば、SEOに影響を與える重要なGoogle Webコアの重要なSEOには、JavaScriptベースのデータ収集が必要です。同様に、LCPは、より意味のあるメトリックでの巧妙な試みですが、依然として推定を伴います。 Googleは幅広い適用性について仮定を立てる必要がありますが、サイトの重要な要素を特定して、レンダリング時間を直接追跡できます。たとえば、SpeedCurveのヒーローレンダリング時間を使用してください。

<main elementtiming="article"></main>

これは、一般的な數(shù)字だけでなく、サイトにとって重要なことを直接測定します。

さらに、FIDは価値がありますが、ユーザータイミング（W3C標準）を使用して、重要なサイトアクションをマークするJavaScriptイベントをトリガーすることを検討してください。たとえば、Codepenのようなプラットフォームでは、エディターの準備を追跡できます。

 editors.init（）;
performance.mark（ "編集者が初期化されます。"）;

この積極的な分析へのアプローチは、標準的な方法を上回ります。 JavaScriptのサイズを200kBに制限するパフォーマンス予算は役立ちますが、1.1秒以內(nèi)にコア機能がロードされることを保証する予算（1.4秒遅い速度ではなく）がはるかにインパクトがあります。

1これは、3つのWeb Core VitalsのSpeedCurveチャートを作成するには、FIDデータを含めるためにラムソリューションであるLuxが必要だからです。頭字語の過負荷についてお詫びします！

以上が重要な分析の詳細內(nèi)容です。詳細については、PHP 中國語 Web サイトの他の関連記事を參照してください。