Performance タブは、実際のユーザーがどのくらいの速さでページを読み込んでいるかを示します。すでにインストール済みの同じトラッキングスクリプトからタイミングデータを収集するため、追加の設定は不要で、数字は人工的なラボテストではなく、ユーザーが実際に経験した内容を反映しています。

Performance タブを開く
Domains からウェブサイトのダッシュボードを開き、サイドバーで Performance タブを選択します (Behavior グループの下)。直接的な URL は app.zenovay.com/domains/{あなたのサイト}?tab=performance です。
タブの上部には、以下のすべてに適用される 3 つのコントロールがあります:
- パーセンタイル (p75、p90、p95、p99):値がどのような訪問者層を示しているか。p75 は Core Web Vitals の標準、p95 および p99 は最も遅い層を表示します。
- デバイス:すべてのデバイス、デスクトップ、またはモバイルでフィルタリング。
- 期間:24h、7d、30d、または 90d。
測定内容
Zenovay は各ページビューのフィールド タイミングデータ (リアルユーザーモニタリング) をキャプチャします:
| メトリック | 測定内容 | 「良い」の閾値 |
|---|---|---|
| LCP | メインコンテンツがレンダリングされるまでの Largest Contentful Paint | < 2.5s |
| INP | ユーザー入力への応答性を示す Interaction to Next Paint | < 200ms |
| CLS | ビジュアル安定性を示す Cumulative Layout Shift | < 0.1 |
| FCP | 最初のコンテンツが表示されるまでの First Contentful Paint | < 1.8s |
| TTFB | サーバー応答時間の Time to First Byte | < 800ms |
LCP、INP、CLS は 3 つの Core Web Vitals です。FCP と TTFB は、LCP が低い理由を説明するのに役立つ補助的な診断メトリックです。
情報
パフォーマンスメトリックは実際のアクセスからサンプリングされるため、数字が安定するまでには適切な量のトラフィックが必要です。新しいサイトまたはトラフィックが非常に低いサイトは、十分なサンプルが集まるまで「データ収集中」の状態が表示される場合があります。
ダッシュボードの読み方
メトリック タイルとメイン グラフ
上部には、各メトリックのタイルが選択したパーセンタイルでの値を良好/要改善/不良のバンドと共に表示します。タイルを選択して、それをアクティブメトリックにすると、下のメインパネルが選択した期間にわたるそのメトリックのトレンドをプロット表示し、改善していくか悪化していくかを確認できます。
ルート別の内訳
routes の内訳にはページとそのメトリック値が列挙され、どのページが遅いかを特定できます。最も問題のあるページを見つけるためにソートしてスキャンして、ビジネスで最も重要なページを掘り下げます (チェックアウトページやサインアップページは、不明瞭なアーカイブページより重要です)。
国別の内訳とマップ
countries の内訳と 地理マップ は、訪問者の場所別に同じメトリックを表示します。遅いスコアが実際のバックエンド問題か単なる距離かを判断する最速の方法です。北米が速くても Asia Pacific が遅い場合、CDN またはエッジキャッシングが通常は解決策です。
TTFB フェーズ
データが利用可能な場合、TTFB ウォーターフォール は Time to First Byte をネットワークフェーズ (DNS、接続、サーバー、転送) に分解し、サーバー応答時間の使い方を確認できます。このフェーズの内訳は今後的に収集されるため、新しいデータが時間とともに入力されます。ページのフェーズデータが存在するまで、パネルは部分的なバーではなく「収集中」状態を表示します。
問題のある要素
各ルートについて、Zenovay は低いメトリックの原因となった要素を特定できます。例えば、Largest Contentful Paint をトリガーした特定の画像や、レイアウト変更の原因となった要素です。TTFB フェーズと同様に、要素属性は今後的に収集されるため、十分な新しいサンプルが収集されたら表示されます。
何を修正するかを判断する
実用的なループ:
- パーセンタイル を p75 に設定して Core Web Vitals 標準に合わせます (遅い層を調査するには p95 / p99 を使用)。
- タイルで失敗しているメトリックを選択します。
- routes の内訳を開いて、どのページが原因かを確認します。
- countries の内訳をチェックして、地理的要因を排除します。
- TTFB が高い場合、問題は通常サーバー側です (遅いクエリ、キャッシュ がない、または CDN が解決できる距離)。LCP が高いが TTFB が良い場合、問題は通常ページ自体にあります (大きな画像、レンダリングをブロックする CSS/JS)。
各メトリックの詳細な説明と改善方法については、Core Web Vitals を参照してください。
デバイス間での比較
モバイルとデスクトップはほぼ常に異なるストーリーを示します。スマートフォンは CPU が遅く、ネットワークがより可変的だからです。Device フィルタを使用して各セグメントを個別に確認するか、Performance by Device を読んで、フォーカスされたチュートリアルを参照してください。
リグレッションについて通知を受け取る
タブを手動で確認する代わりに、メトリックがしきい値を超えたときに通知するアラートを設定できます。Performance Alerts を参照して設定してください。
トラブルシューティング
データなし、または「データ収集中」
確認:
- トラッキングスクリプトがインストールされており、予期されたページで読み込まれている (ブラウザのネットワークタブで確認)。
- サイトには十分なトラフィックがある。パフォーマンスメトリックは、入力するために実際のアクセスが必要です。
- 広告ブロッカーまたはコンテンツブロッカーが一部の訪問者のスクリプト実行を妨げていない。
Lighthouse の実行と数字が異なる
これは予想されることです。Zenovay は、多くのデバイスとネットワークからの実際の訪問者からの フィールドデータ を報告します。Lighthouse は、シミュレートされた 1 つのデバイスでの単一の ラボ 実行を報告します。異なることを測定し、正確に一致することはまれです。フィールドデータは、実際のユーザーが経験した内容を反映しています。
高分散
特にモバイルトラフィック、グローバルに分散したオーディエンス、またはピークトラフィック期間では、ある程度のばらつきが通常です。平均ではなくパーセンタイル (p75 / p95) を使用して、分布を正直に読んでください。