SQL によるフロントエンド信頼性モニタリング
フロントエンドの信頼性は、単一のサイト全体のパフォーマンス スコア以上のものです。有用な調査には、個々のメトリック、その単位、安定したルート、フロントエンドのリリース、および回帰と通常の変動を区別するのに十分なサンプルが必要です。構造化されたブラウザ イベントにより、これらの境界が明確になり、同じ SQL がリリース レビュー、ダッシュボード、およびインシデント対応をサポートできるようになります。
境界付きブラウザ イベントを設計する
サポートされている測定ごとに 1 つのイベントを発行します。 metric_name, metric_value, metric_unit, route_template, release, threshold_version, passed、そして environment。次のようなルートを使用します /projects/:id、決して生の URL ではありません。境界付きデバイス クラスは、実際の決定を変更し、セグメントが十分なサンプルを受信する場合にのみ追加します。
クエリ文字列、DOM コンテンツ、フォーム値、Cookie、認証データ、または無制限のユーザー ID は収集しないでください。定義と製品ターゲットはコードのリリースとは関係なく変更される可能性があるため、しきい値バージョンを保持してください。
ルートとリリースを比較する
の コア ウェブ バイタル SQL レシピ LCP、INP、および CLS 測定をルートおよびリリースごとに 1 行にピボットします。サンプル数と通過サンプルの割合をメトリクス平均の横に保持し、決定論的な入力行を含み、 ブラウザ SQL プレイグラウンド.
結果を次の順序で使用します。
- サンプル量と観察窓が同等であることを確認します。
- ルートを見つけて、最も弱い通過サンプル レートでリリースします。
- 概要を原因とするのではなく、動いた個々のバイタルを検査します。
- リリースを以前のリリースと比較し、完全な時間バケットでの回復を確認します。
生産レポートでは、平均だけでなくパーセンタイルからも恩恵を受けることがよくあります。追加するときは、同じルート、リリース、メトリック、ユニット コントラクトを保持します。
リリースガードレールを構築する
ダッシュボードには、サンプル数、LCP、INP、CLS、およびしきい値のバージョンが表示されます。リリースのガードレールには、最小量の見直しと持続的な後退が必要です。 1 つのまばらなデバイスまたはルート セグメントが原因で展開がブロックされるべきではありません。
の フロントエンドパフォーマンスのユースケース インストルメンテーションのプロンプトとレビューのチェックリストを提供します。を使用します。 ブラウザ テレメトリ プロキシ ガイド Telemetry API キーをサーバー側に保持し、ホワイトリストに登録されたブラウザー契約を強制します。ブラウザエクスペリエンスをペアにする API 信頼性 SQL 遅いページがバックエンド ルートまたは依存関係に起因する可能性がある場合。