Dev Dashboard で admin の Web Vitals を監視 パフォーマンス計測が「開発の本拠地」に集約

図解 ： Dev Dashboard で admin の Web Vitals を監視 Developer / Tools Dev Dashboard で admin の Web Vitals を監視 パフォーマンス計測が「開発の本拠地」に集約 アプリの管理画面パフォーマンスデータが Partner Dashboard から Dev Dashboard へ移動。タブを行き来せず、既存のモニタリングツールと並べて Core Web Vitals を確認できるようになった。コード変更は不要。 このページの構成 そもそも何が変わるのか（30秒で理解） 移動の全体像 ： データはどこへ行ったか 見られる 3 つの Core Web Vitals FID の引退と INP への置き換え マーチャント／開発者がやること 確認手順（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか アプリの admin（管理画面）パフォーマンスデータ が、 Partner Dashboard から Dev Dashboard へ移動 した。 これまで Web Vitals を見るために Partner Dashboard のタブを切り替えていた手間が無くなり、既存のモニタリングツールと同じ場所で確認できる。 これまで ： Partner Dashboard パフォーマンスを見るために Partner Dashboard 側のタブへ移動。他の開発作業と画面が分断されていた。 これから ： Dev Dashboard 既存のモニタリングツールと同じ Dev Dashboard 上に統合。Web Vitals 確認のためのタブ移動が不要に。 2 移動の全体像 ： データはどこへ行ったか ダッシュボードに表示されるのは App Store がアプリの適合性を評価する際に使うのと同じデータ 。つまり「自分が見ている数値」と「審査側が見ている数値」が一致するため、ズレなく Built for Shopify 基準を追える。 3 見られる 3 つの Core Web Vitals 日次（daily）と 28 日間（28-day）の P75 ロールアップ （上位 75 パーセンタイル集計）を、次の 3 指標について確認できる。 LCP Largest Contentful Paint 最大要素の描画完了までの時間。 読み込みパフォーマンス を測る。 INP Interaction to Next Paint 操作してから次の描画までの応答性。 インタラクティブ性 を評価する。 CLS Cumulative Layout Shift レイアウトの予期せぬズレの累積。 視覚的な安定性 を評価する。 各指標には、 Built for Shopify 評価で使われるしきい値 に基づいた明快な pass / fail ステータス が付く。数値の良し悪しを自分で判断せずとも、合否で一目で分かる。 4 FID の引退と INP への置き換え FID は引退（retired） First Input Delay （最初の入力遅延）は廃止された。ダッシュボードからも姿を消している。 INP が後継の Core Web Vital に FID の代わりに INP が Core Web Vital として採用され、ダッシュボードもこの更新を反映している。 FID は「最初の入力に対する遅延だけ」を測っていたのに対し、INP は セッション全体の操作応答性 を捉える。インタラクティブ性の実態をより正確に反映する指標へ移行した、と理解すればよい。 5 マーチャント／開発者がやること 項目 内容 コード変更 不要 アプリの Web Vitals テレメトリはこれまで通り機能し続ける。 旧ブックマーク 自動 Partner Dashboard の admin パフォーマンスページの URL は、自動的に Dev Dashboard へリダイレクトされる。 Distribution ページのリンク 更新済み アプリの「Distribution（配布）」ページのリンクは、新しい場所を指すようになった。 実質的に開発者側の作業は ゼロ 。テレメトリの送信は変わらず、見る場所が変わっただけ。古いリンクも壊れずに新しい場所へ案内される。 6 確認手順（3ステップ） 1 Dev Dashboard を開く 既存のモニタリングツールがある Dev Dashboard へアクセスする。 2 admin パフォーマンスを開く LCP / INP / CLS の日次・28 日間 P75 ロールアップを表示。 3 pass / fail を確認 Built for Shopify しきい値に基づく合否で、対応の要否を判断。 7 技術者が押さえるべき5つのポイント 1. 見る場所が一本化された パフォーマンスデータが Dev Dashboard に集約され、既存のモニタリングと同じ画面で確認できる。Partner Dashboard とのタブ往復が消えた。 2. 指標は P75 ロールアップ 日次と 28 日間の P75（上位 75 パーセンタイル）集計。単発の外れ値ではなく「大半のユーザー体験」を見る前提で改善を判断する。 3. 合否は Built for Shopify 基準 各指標の pass/fail は Built for Shopify 評価のしきい値準拠。BFS バッジ維持・取得を狙うなら、ここが直接の管理指標になる。 4. FID → INP への移行を反映 FID は廃止、INP が Core Web Vital に。応答性の監視対象とアラート閾値を INP ベースへ切り替える前提でダッシュボードを読む。 5. テレメトリと旧 URL は無改修で生き続ける アプリ側の Web Vitals テレメトリ送信は従来通りで、 コード変更は不要 。Partner Dashboard の旧ブックマーク URL は自動リダイレクトされ、Distribution ページのリンクも新しい場所に更新済み。移行作業を組む必要はない。 8 業務に活かせる3つのユースケース USE CASE 1 BFS バッジの維持を「合否ダッシュボード」で定常監視 課題 Built for Shopify を取得済みのアプリで、LCP/INP/CLS が基準を割っていないかの監視が属人化していた。 打ち手 Dev Dashboard の pass/fail と 28 日間 P75 を週次でチェックし、fail に転じた指標を即トリアージするフローを作る。 効果 審査側と同一データを見るためズレが無く、バッジ剥落リスクを早期に察知できる。 技術メモ 合否しきい値は BFS 評価準拠。日次で兆候、28 日間で確定傾向、と粒度を使い分ける。 USE CASE 2 FID 廃止に合わせた社内モニタリングの INP 移行 課題 自前の計測ダッシュボードやアラートが FID ベースのままで、Shopify の評価基準とズレ始めていた。 打ち手 監視対象とアラート閾値を INP に置き換え、Dev Dashboard の INP 合否と社内指標を突き合わせる。 効果 「最初の入力遅延」ではなくセッション全体の応答性を捉え、実ユーザー体験に沿った改善優先度がつけられる。 技術メモ FID はダッシュボードから消えているため、FID 依存のレポートは作り直しが必要。 USE CASE 3 チーム手順書・ブックマークの「移動先」棚卸し 課題 運用手順書や共有ブックマークが Partner Dashboard のパフォーマンス画面を指しており、メンバーが迷う。 打ち手 自動リダイレクトに頼りつつ、手順書・社内 Wiki のリンクを Dev Dashboard へ正式に張り替える。 効果 新メンバーのオンボーディングが迷わず完結。リンク切れ・古い導線による問い合わせを削減。 技術メモ 旧 URL は自動リダイレクトされるため移行猶予はあるが、アプリの Distribution ページは既に新しい場所を指している。 9 提案で使える1行サマリ 「アプリの admin パフォーマンス（LCP / INP / CLS の P75・合否）が Dev Dashboard に集約 。 コード変更ゼロ・旧 URL は自動リダイレクト・FID は INP へ置き換え。 審査側と同じデータで Built for Shopify 基準を一画面で追える。」 source ： shopify.dev / changelog / monitor-admin-web-vitals-in-the-dev-dashboard