ページ速度 playbook
速度改善はラボスコアを一度磨いて勝利宣言すると失敗します。持続する版は実ユーザーを測り、層別に直し、退行をデフォルトの敵として扱います。
ストア速度は収益の入力——転換・広告効率・順位のすべてが織り込みます——そしてアプリ・スクリプト・画像の蓄積でデフォルトで劣化します。この playbook は規律を回します：テンプレート別の実測ベースライン、正しい層（エッジ設定かページ構造か）でのインパクト順修正、そして改善を四半期ごとの英雄譚でなく永続にする退行の仕掛け線。
ステージ 1：テンプレート別・実測データでベースライン
ラボスコアは両方向に誤導します。実ユーザーの LCP・INP・CLS をテンプレート別——商品・コレクション・トップ・チェックアウト——とデバイス別に収集します。収益加重のビューが着手点を教えます：モバイルの遅い商品テンプレートは、たいてい他のすべてをインパクトで上回ります。
テンプレート・デバイス階級別の実ユーザー Core Web Vitals
作業順を決めるテンプレート × 収益の加重
スクリプト単位のコストつき完全なサードパーティ台帳
ラボ対実測の乖離——それ自体が原因を指す
ステージ 2：問題を所有する層で直す
エッジ層の問題——キャッシュルール、画像フォーマットとサイズ、圧縮、配信——は設定で直り、即座に全店で効きます。ページ層の問題——レンダリングをブロックするスクリプト、巨大なヒーローメディア、遅延ウィジェットのレイアウトシフト、アプリ肥大——はテンプレートで直します。エッジを先にやると、テンプレートに触れる前に問題が半減することがよくあります。
ステージ 3：直ったままにする
将来のアプリ導入とキャンペーンスクリプトはすべて、着地待ちの速度退行です。テンプレート別ベースラインを生かし続け、スクリプト追加を実測コストで審査し、サードパーティ台帳を計画的に再監査します——去年その場所に値したスクリプトが、今年も値するとは限りません。
動作の流れ
ベースラインとランク
テンプレート別実測指標を収益加重で、スクリプト台帳はコスト算定済みで。
エッジが先、テンプレートは後
設定レベルの修正は即座に全店へ。テンプレート修正はインパクト順で続く。
成果を防衛
生きたベースライン、スクリプトコスト審査、計画的再監査で再劣化を防ぐ。
得られるもの
実際に支払うユーザーの上で測られた速度
各問題を所有する層で適用された修正
コストに個別に責任を負うサードパーティスクリプト
退行は着地した週に捕捉——次の四半期でなく
担当するエージェント
よくある質問
Core Web Vitals の目標は？
公表される良好しきい値——LCP 2.5 秒未満、INP 200ms 未満、CLS 0.1 未満——を、テンプレート別・実ユーザー 75 パーセンタイルで。ただし方向がしきい値より重要です：ひどい→並みへの移動が転換利得の大半を取ります。
エッジ層だけでどれくらい速くなる？
一度も調整していないストアでは、エッジ作業——正しいキャッシュ、現代的画像フォーマット、圧縮——だけで、テンプレートに触れず改善の大きい方の半分が出るのが普通です。だから先なのです。
テーマが問題。作り直しか、パッチか？
まず測ること：テンプレート修正リストが短く有界ならパッチ。テーマの構造があらゆる修正に抗うなら作り直しが回収します——苛立ちでなく証拠で下す判断です。
どのエージェントが実行？
Ops がベースライン・エッジ層・退行監視を、Builder が証拠つきのテンプレート修正を担当。監査ログが何を変え、指標に何をしたかを記録します。