頁面速度 playbook
速度優化的失敗方式是優化一次實驗室分數就宣佈勝利。可持續的版本度量真實用戶、按層修復，並把迴歸當預設要防的事。
店舖速度是收入輸入——轉化、廣告效率和排名都會計價——而且隨著應用、腳本、圖片累積，它預設就在衰退。這份 playbook 跑的是紀律：按模板建立實測數據基線，在正確的層（邊緣配置對頁面結構）按影響順序修復，裝上讓改善變成永久（而非每季度一次的英雄主義）的迴歸絆線。
階段一：按模板、按實測數據建基線
實驗室分數兩個方向都會騙人。採集按模板——商品、分類、首頁、結賬——和按設備細分的真實用戶 LCP、INP、CLS。按收入加權的視圖告訴你從哪開始：手機端的慢商品模板通常在影響上碾壓其他一切。
按模板與設備檔的真實用戶 Core Web Vitals
模板 × 收入加權，排定工作順序
完整的第三方腳本清單，逐腳本計成本
實驗室與實測的落差，本身就指向原因
階段二：在擁有問題的層修復
邊緣層問題——緩存規則、圖片格式與尺寸、壓縮、分發——在配置裏修，一次全店生效。頁面層問題——渲染阻塞腳本、超大首屏媒體、遲加載掛件的佈局偏移、應用膨脹——在模板裏修。先做邊緣工作，常常在碰任何模板之前就把問題砍掉一半。
階段三：讓它保持修好
未來每次裝應用、加活動腳本都是一次待發生的迴歸。保持按模板的基線常亮、新腳本按實測成本審查、按計劃重審第三方清單——去年值回票價的腳本今年未必還值。
運作方式
建基線並排序
按模板的實測指標、按收入加權、腳本清單計完成本。
先邊緣後模板
配置級修復立即全店生效；模板修復按影響順序跟上。
守住成果
基線常亮、腳本成本審查、計劃性重審，讓店不再重新衰退。
你會得到甚麼
在真正付錢的用戶身上度量的速度
在擁有各自問題的層實施的修復
為成本逐一負責的第三方腳本
迴歸在落地當周被抓住，而非下個季度
由這些 Agent 負責
常見問題
Core Web Vitals 該定甚麼目標？
公開的良好閾值——LCP 低於 2.5 秒、INP 低於 200 毫秒、CLS 低於 0.1——按模板、取真實用戶第 75 百分位。但方向比閾值重要：從糟糕到及格的店已經拿到大部分轉化收益。
光做邊緣層能提多少？
在從未調過的店上，邊緣工作——正確的緩存、現代圖片格式、壓縮——常常不碰模板就交付大半改善。所以它排第一。
主題就是問題所在，重建還是打補丁？
先度量：模板修復清單短而有邊界，就補；主題架構跟每個修復對著幹，重建才回本——這是拿證據做的決定，不是拿情緒。
哪些 Agent 跑這個？
Ops 負責基線、邊緣層與迴歸監控；Builder 帶著證據上線模板修復。審計日誌記錄改了甚麼、對指標做了甚麼。