Skip to main content

第17章:Performance Monitoring導入(遅いを“見える化”)⚡👀

この章はひとことで言うと、「遅い」を“気合い”じゃなく“証拠”で語れるようになる回です🕵️‍♂️📊 Analyticsが「使われ方(行動)」を見るなら、Performance Monitoringは「速さ(体感)」を見る感じです🏃‍♀️💨


この章でできるようになること ✅✨

  • Web(React)に Performance Monitoring を入れて、計測をスタートできる🎛️
  • Consoleで 「ページが遅い」「通信が遅い」 を見つける入口が作れる👀
  • 「データ出ない…」のありがち原因を潰せる🧯

1) Performance Monitoring って何がうれしいの?🙂📈

Speed vs User Feeling

ユーザー目線だと、アプリの評価ってだいたいこれです👇

  • 速い→「気持ちいい」😆
  • 遅い→「不安」「離脱」😇💔

Performance Monitoringは、ページ表示や通信の遅さを自動で集めて、Firebase Consoleに並べてくれます。 Web向けの導入手順と、最初に見るべき場所が公式にまとまっています。(Firebase)


2) Webだと「何が」測れるの?🔍🌐

2-1. ページ読み込み(Page load)🖼️⏱️

Web Vitals Trio

Webでは、いわゆる “Web Vitals” 系も見えます(LCP / INP / CLS など)📏✨ 加えて、First Paint / First Contentful Paint / DOM系イベント みたいな「読み込みの節目」も見えます。(Firebase)

ざっくり覚え方(超ざっくりでOK)👇

  • LCP:メインの表示が終わるまで(体感の“重さ”)🧱
  • INP:操作に対する反応の良さ(“もっさり”検知)🕹️
  • CLS:レイアウトがガタガタ動く(“画面が揺れる”)🫨

2-2. 通信(HTTP/S network request)📡⏱️

Network Metrics

通信は「遅い?」を レスポンスタイム として追えます。 サイズも出ますが、Webではブラウザの制約があって、クロスオリジンやキャッシュなど条件によっては payload size が 0 になることもあります(仕様上そうなることがある)。(Firebase)


3) まずは導入しよう(React/TypeScript)🧩🧑‍💻

3-1. 重要ポイント(つまずき予防)🧯

  • WebでPerformance Monitoringを使うには、Firebase Consoleで Webアプリとして登録されている必要があります。
  • 既存アプリに後付けするなら、Firebase config に appId が入っていることが大事です。(Firebase)
  • それと、現時点で Web向けPerformance SDKは beta です(互換性が変わる可能性があるよ、という扱い)。(Firebase)

3-2. コード(最小構成)✍️

React Performance Setup

Firebase初期化があるプロジェクト前提で、Performanceを追加します。

src/firebase.ts(例)

import { initializeApp } from "firebase/app";
import { getPerformance } from "firebase/performance";

const firebaseConfig = {
// ✅ ここに appId が入っているか要チェック!
// apiKey, authDomain, projectId, appId, ...
};

export const app = initializeApp(firebaseConfig);

// ✅ これだけで “計測開始” の入口ができる
export const perf = getPerformance(app);

src/main.tsx(例:読み込み時に firebase.ts が評価されるように)

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";

// これを import しておくと、Performance の初期化が走る
import "./firebase";

ReactDOM.createRoot(document.getElementById("root")!).render(
<React.StrictMode>
<App />
</React.StrictMode>
);

公式も getPerformance(app) の形(modular API)を案内しています。(Firebase)


4) 「First Input Delay(FID)」だけ注意⚠️🖱️

Webの一部指標(FID)は、polyfillが必要と案内されています。 ただし、これは 他の指標(LCP/INP/CLS等)を見るだけなら必須じゃないです。(Firebase)

さらに、FID polyfill の参照先が 別ライブラリ(Web Vitals系)に移動している流れもあります。(GitHub)

この章の結論:

  • まずは polyfill無しで導入 → データが出る状態を作る🧱
  • 「FIDも見たい!」となったら、公式の案内に沿って追加🧩(次の章で深掘りしてもOK)

5) 最初のデータを“出す”コツ(ここ超重要)🔥

The 10 Second Rule

導入しただけだと「静か」なので、わざとイベントを発生させます😆

やること👇

  1. ローカルでアプリを起動(開発サーバ)🚀

  2. 画面をいろいろ開く(サブページ遷移、操作、通信)🖱️📡

  3. ページを開いた後、最低10秒はタブを開いたままにする⏳

    • SDKが 約10秒ごとにまとめて送るため、すぐ閉じると送信前で終わることがあります。(Firebase)
  4. Firebase Console の Performance ダッシュボードへ行く(数分待つ)👀(Firebase)


6) 「本当に送れてる?」を秒速で確認する方法⚡🧪

Chrome DevTools などの Network を開いて、数秒後に firebaselogging.googleapis.com への通信が見えたら「送れてる」サインです✅(Firebase)


7) Consoleで“最初に見る”場所👀📊

Console Filtering

Performance MonitoringのConsoleでは、だいたい次を見ます👇

  • Metric dashboard(メトリクスのカード)
  • Traces table(トレース一覧)
  • フィルタ(属性で絞り込み)

特に便利なのがフィルタで、例えば👇

  • Page URLで「このページだけ」
  • Effective connection typeで「3Gっぽい回線だと?」
  • Countryで「特定地域だけ遅い?」 みたいに絞れます。(Firebase)

8) Remote Config と相性が良い理由🎛️🤝⚡

Monitoring Rollout Speed

新機能を段階リリースするとき、 「出したら遅くなった😇」を早めに気づけると勝ちです🏆

Googleの学習コンテンツでも、Performance Monitoring を使って 機能ロールアウトを監視しつつ Remote Config で安全に出す流れが紹介されています。(Google for Developers)

この章では“導入”まで。 次の章で「遅いページTOP1を見つける」みたいな捜査に入ります🕵️‍♂️✨


9) AI活用(Antigravity / Gemini CLI)で導入を速くする🤖💨

「どこに何を書けばいい?」が一番つらいので、そこはAIに投げてOKです🙆‍♂️✨

9-1. Firebase MCP server が効く🧠🧰

Firebaseは MCP server を用意していて、 Antigravity / Gemini CLI / Gemini Code Assist など複数ツールから使える、と明記されています。(Firebase)

9-2. Gemini CLI にはFirebase拡張がある🧩

Gemini CLI に Firebase extension を入れると、MCP serverの設定やFirebase向けのコンテキストが自動で整う、という位置づけです。(Firebase)

導入コマンド(例)👇

gemini extensions install https://github.com/gemini-cli-extensions/firebase/

9-3. 使えるプロンプト例(コピペ用)📝

  • 「React(Vite)で getPerformance(app) を追加して、src/firebase.ts にまとめて。appId が無い場合は指摘して」
  • 「Performance dashboard で Page URL フィルタを使って、遅いページを見つける手順を“初心者向け”に箇条書きで」
  • 「Network traces の payload size が 0 になるケースがある理由と、判断の仕方を説明して」(Firebase)

10) ミニ課題(10〜20分)🧪🏁

ミッション🎯

  1. Performance Monitoring を入れる(getPerformance(app))(Firebase)
  2. 画面を3回以上開き、通信も発生させる(API叩く・画像読む等)📡
  3. タブを10秒以上開く⏳(Firebase)
  4. Consoleでデータを確認
  5. Page URL フィルタで「特定ページだけ」を見てみる👀(Firebase)

提出物(メモでOK)🗒️

  • 「いちばん遅そうなページURL」
  • そのページの “気になる指標” を1つ(例:LCP)
  • 「次に疑う原因(画像?通信?レンダリング?)」を1行🕵️‍♂️

11) チェック(理解度テスト)✅🙂

  • appId が config に入ってる?(Firebase)
  • 導入後、タブを10秒以上開いて試した?(Firebase)
  • Networkで firebaselogging.googleapis.com を見た?(Firebase)
  • Page URL フィルタでページ単位に見られた?(Firebase)
  • payload size が 0 でも「壊れた」と決めつけない理由を説明できる?(Firebase)

12) よくある詰まりポイント🧯(ここ見ればだいたい直る)

「SDK detected」にならない / データが出ない 😭

  • まずは ログ/送信の確認(WebならNetworkで送信があるか)(Firebase)
  • 公式トラブルシュートでは、SDK検出は通常 10分以内、初期データ表示は 30分以内の目安が書かれています(環境差あり)。(Firebase)
  • それでも怪しいときは Firebase Status Dashboard を確認、という流れも公式が推奨です。(Firebase)

次の第18章では、いよいよ 「遅い原因の当たりをつける」 に入ります🕵️‍♂️🌐 「ページ」「通信」「画像」「AI処理」…どれが犯人っぽいか、証拠集めしていきましょ😆📌