速度是收入輸入，以真實用戶度量
慢的店轉化更差、排名更低、每次廣告點擊更貴。而店舖速度預設就會衰退——每次裝應用、每個活動腳本都在把它往錯的方向推。
速度優化常見兩種失敗：優化一個真實用戶從未經歷的實驗室分數，以及修一次就完事而衰退的原因還在繼續運轉。Ops 把速度當持續學科來跑——真實用戶 Core Web Vitals 按模板與設備細分、找原因而非治症狀、在邊緣修或交給 Builder、用基線在迴歸到來時抓住它。
度量顧客真實經歷的
測試伺服器上的合成分數説明不了蜂窩網絡上中端手機用戶的體驗。按模板拆分的真實用戶數據，才能把問題定位到可修的東西上。
按模板（商品、分類、首頁、結賬）的真實用戶 LCP、INP、CLS
設備與網絡拆分——真正的損失通常集中在這裏
第三方腳本成本，逐腳本歸因而非籠統彙總
實驗室分數與實測數據的差距，本身就是診斷線索
在正確的層修正確的因
有些是邊緣問題——緩存、圖片分發、壓縮——Ops 直接修。有些是頁面問題——渲染阻塞腳本、超大媒體、遲加載元素造成的佈局偏移——這些帶著證據作為具體任務交給 Builder。
迴歸是預設值；要防
三月很快的店到八月就慢了，因為應用和腳本在累積。基線讓衰退立即可見：新應用或主題更新拖低某模板的指標時，當週就被標記、附上原因，而不是等季度審計才發現。
運作方式
按模板建基線
Ops 按模板與設備記錄真實用戶指標——之後每次變化的評判參照。
按層修復
邊緣問題在配置裏修；頁面問題帶著具體證據交給 Builder。
盯住衰退
新腳本、應用與主題變更對照基線檢查，拖慢速度時被標記。
你會得到甚麼
按模板與設備的實測指標，而非一個實驗室分數
第三方腳本為其成本逐一負責
修復應用在擁有該問題的層
迴歸發生當週即被抓住，原因隨附
由這些 Agent 負責
常見問題
店舖最該看哪個指標？
商品與分類模板的 LCP 通常是收入敞口最大的，交互密集頁面的 INP 緊隨其後。但誠實的答案是：你的真實用戶在真實設備上最差的那一個。
刪應用會不會弄壞功能？
審計會區分「值回成本」和「不再值」的腳本。移除是帶證據提議、分步執行的，真正承重的東西會在出事前被攔下。
速度對轉化影響到底多大？
大到在你自己的數據裏就能看見——這才是要緊的度量，而不是行業統計。基線讓你看到自己的彈性，不用引用別人的。
這對 SEO 也有幫助嗎？
有——頁面體驗信號參與排名，更快的頁面爬取也更高效。但轉化收益通常在排名收益到來之前就把工錢掙回來了。