網站效能 是做什麼的？
載入 brand-guide（確保速度修正不改變品牌外觀），並遵循 website-change-safety。
方法
- 使用 PageSpeed Insights 行動版進行基準測試，每個頁面執行 2-3 次，並參考真實使用者資料。記錄 LCP 元素。
- 在報告中找到原因：長時間任務、啟動時間 / 第三方資源摘要、渲染阻斷請求、LCP 細項（載入延遲 vs 渲染延遲）、DOM 大小、強制重排。
- 一次只修正一個原因，再次測量，只保留有幫助的變更。
- 如果可以，在發佈前進行本地 A/B 測試：透過請求攔截，對即時頁面提供新的 JS/HTML/CSS，並以相同方式提供兩個版本（未壓縮的本機檔案與 gzip 壓縮的即時檔案會使模擬時間產生偏差）。比較主執行緒時間、DOM 大小、樣式/佈局時間。
能實際提升分數的修正（優先檢查這些）
第三方資源與平台重量（通常影響最大）
- 已卸載但仍在載入的應用程式。 移除遺留的頁面編輯器 widget 與腳本條目。有些平台在移除應用程式後仍會持續注入整合程式碼（例如 50 多個檔案的視覺編輯器執行時期）；尋找頻道/商店層級的「停用」開關，否則請聯繫平台支援。
- 按需載入，而非每個頁面都載入： 影片播放器（顯示海報圖片 + 播放按鈕，點擊時才建立 iframe）、驗證碼（表單開啟時載入）、聊天 widget、忠誠度/獎勵 widget（僅在需要的頁面載入）、評論 widget 在頁面下方。
- 透過頁面編輯器嵌入的影片區塊無法被主題延遲載入；將這些影片移至主題本身的影片區域，該區域使用點擊載入的遮罩層。
- 重複項目： 兩個分析程式庫、相同的標籤出現兩次、舊的與新的像素。
- 未經擁有者同意，不要將廣告/分析標籤延遲到互動時載入；這會改變他們的數據。
JavaScript 在載入時執行太多工作
- 輪播/滑桿： 預設桌面版的輪播設定通常會先建立桌面佈局，然後再為手機重建；切換為行動優先設定。「無限/循環」模式會將每張投影片複製 2-3 次（產生數百個額外元素）；在不需要的地方關閉循環。初始化那些在首屏以下才開始的輪播時，僅在它們接近視口時才初始化（使用 IntersectionObserver），並使用 CSS 顯示未初始化時相同高度的行列，以避免頁面跳動。
- 頁面編輯器與外掛（尤其是 WordPress/Wix/Squarespace）：每個外掛可能都會向每個頁面加入自己的 CSS/JS；停用未使用的部分，並僅在需要的地方載入其餘部分。
- 隱藏的重复標記： 例如列表頁面同時呈現網格與每個產品的隱藏列表視圖。只渲染一種。
- 移除遺留的除錯日誌與仍在執行的無用程式碼路徑。
最大內容繪製（Largest Contentful Paint）
- 識別真正的 LCP 元素。如果是 CSS 背景圖片，瀏覽器會較晚找到它；僅在該頁面新增
<link rel="preload" as="image" fetchpriority="high">，並且 URL 必須與 CSS 解析到的 URL 完全位元一致（否則會下載兩次）。 - 只有第一列可見的圖片才使用
fetchpriority="high"（例如在 2 欄手機網格中只有 2 張）；更多高優先級圖片會與真正的 LCP 圖片競爭頻寬。 - 永遠不要對 LCP 圖片使用懶加載。對首屏以下的所有內容進行懶加載。
- 檢查平台已經提供哪些格式（許多 CDN 會自動轉換為 WebP/AVIF）；重新儲存圖片可能沒有任何好處。最大的效益來自於過大的原始圖片與錯誤的
sizes屬性。
首次繪製 / 渲染阻斷
- 主題的主要樣式表通常是瓶頸。可以將頁面專用的 CSS 拆分出來或內聯關鍵 CSS，但這是一個較大且風險較高的專案；提出建議，但不要偷偷做。
- 每個額外的渲染阻斷樣式表或
<head>中的同步腳本（通常由應用程式注入）都會增加延遲。 - 字型：有意識地選擇
font-display設定（圖示字型需要block；文字字型只有在後備字型指標足夠接近以避免佈局位移時才能使用swap）。
佈局位移
- 為圖片（width/height）、嵌入內容（aspect-ratio 盒子）、後期出現的橫幅與 widget 預留空間。
- 任何由 JavaScript 初始化的內容都必須有相同尺寸的初始化前 CSS。
報告
每個頁面改善前後的數值（以範圍表示）、真實使用者資料狀態、變更了什麼，以及需要擁有者決定的事項（第三方取捨）。提醒他們實驗室分數會有波動；趨勢與真實使用者資料比單次執行更重要。