速度は収益の入力。実ユーザーで測る
遅いストアは転換が下がり、順位が下がり、広告クリック単価が上がります。そしてストア速度はデフォルトで劣化します——アプリ導入とキャンペーンスクリプトのたびに悪い方へ。
速度改善の典型的な失敗は 2 つ：実ユーザーが体験しないラボスコアの最適化と、劣化の原因が動き続けているのに一度直して終わりにすること。Ops は速度を継続的な規律として運用します——テンプレート・デバイス別の実ユーザー Core Web Vitals、症状でなく原因の特定、エッジで直すか Builder へ渡すか、そして退行が来たら捕まえるベースライン。
買い物客が体験するものを測る
テストサーバーの合成スコアは、モバイル回線の中位機種ユーザーの体験をほぼ語りません。テンプレート別に分割された実ユーザーデータこそ、問題を直せる何かに局所化します。
テンプレート別（商品・コレクション・トップ・チェックアウト）の実ユーザー LCP・INP・CLS
実害が集中しがちなデバイス・回線分割
一括でなくスクリプト単位で帰属されたサードパーティコスト
ラボと実測の乖離——それ自体が診断材料
正しい層で原因を直す
エッジ問題——キャッシュ、画像配信、圧縮——は Ops が設定で直します。ページ問題——レンダリングをブロックするスクリプト、巨大メディア、遅延読込要素のレイアウトシフト——は証拠つきの具体的タスクとして Builder へ。
退行はデフォルト。防ぐこと
3 月に速かったストアは、アプリとスクリプトの蓄積で 8 月には遅い。ベースラインは劣化を即座に可視化します：新アプリやテーマ更新がテンプレートの指標を下げたら、その週に原因つきでフラグ——四半期の監査で発見、ではなく。
動作の流れ
テンプレート別ベースライン
Ops がテンプレート・デバイス別の実ユーザー指標を記録——以後のすべての変化の基準です。
層別に修正
エッジ問題は設定で、ページ問題は具体的証拠つきで Builder へ。
劣化を見張る
新スクリプト・アプリ・テーマ変更はベースライン照合され、速度を犠牲にしたらフラグされます。
得られるもの
単一のラボスコアでなくテンプレート・デバイス別の実測指標
コストに対して個別に説明責任を負うサードパーティスクリプト
問題を所有する層で適用される修正
退行は発生したその週に、原因つきで捕捉
担当するエージェント
よくある質問
ストアで一番重要な指標は？
商品・コレクションテンプレートの LCP が通常最も収益が晒され、操作の多いページの INP が続きます。ただし正直な答えは：あなたの実ユーザーの実デバイスで最悪のもの、です。
アプリ削除で機能が壊れませんか？
監査はコストに見合うスクリプトとそうでないものを区別します。削除は証拠つきで提案され、段階的に実施されるため、本当に必要なものは問題化する前に捕まります。
速度は転換にどれくらい効く？
自社データに現れるほど効きます——業界統計でなくそれが重要な測定です。ベースラインがあれば他人の数字を引用せず自社の弾力性が見えます。
SEO にも効きますか？
効きます——ページ体験シグナルは順位に入り、速いページはクロール効率も上がります。ただし転換効果の方が、順位効果が来る前に元を取るのが普通です。