用 PageSpeed Insights（PSI） 優化 11ty 網站，核心流程很直接：把網址丟進 pagespeed.web.dev，看診斷指到哪個 HTML 元素或腳本，回到模板／CSS／圖片管道逐項修正，build 後再測一次。

在 11ty 裡，診斷結果通常能直接對應到你控制的檔案——首圖太大就處理首圖；圖片沒寬高就改 layout；GTM 阻塞主執行緒就延後載入。WordPress 也能優化，但問題常藏在佈景主題、外掛與快取層疊加，不一定知道哪一層能安全修改。

快速參考

步驟做什麼
1. 測量固定同一 URL，跑 PSI，記 LCP／CLS／INP
2. 定位確認 LCP 元素、CLS 位移源、長任務腳本
3. 修改一次只改一類問題（圖片 OR 腳本，不要同時）
4. 驗證pnpm run build → 檢查輸出 HTML → 重跑 PSI

延伸：PageSpeed Insights 與 Core Web Vitals 指南 · LCP 首屏圖優化

目錄

PSI 是診斷工具，不是框架評分表

PSI 提供兩種資料，用途不同：

類型用途
Lighthouse 實驗室資料重現問題、觀察剛做的改動
CrUX 實地資料反映真實使用者體驗（看 p75）

新站流量不足時可能沒有 CrUX。不要把一次測試分數當永久成績單。

三項 Core Web Vitals 我先看什麼

指標先看什麼
LCPhero 圖、TTFB、阻塞 CSS、圖片是否被 lazy-load
CLS圖片寬高、字體、嵌入內容預留空間
INP第三方腳本、GTM、搜尋或互動元件

優化循環：測量 → 定位 → 修改 → 驗證

  1. 固定同一 URL，跑 PSI，記下 LCP、CLS、INP 與診斷項目
  2. 找出對應的 HTML 元素或網路請求
  3. 把診斷原文貼給 AI，一次只改一類問題
  4. 本機 pnpm run build，檢查輸出 HTML
  5. 部署後用相同 URL 重跑 PSI
  6. 若動過 GTM，確認事件與轉換追蹤仍在
pnpm run build
pnpm exec lighthouse https://example.com/某篇文章/ \
	--output=html \
	--output-path=./lighthouse-report.html \
	--chrome-flags="--headless"

通用 AI 提示詞骨架

這是一個 11ty（Eleventy）網站專案。請依 PageSpeed Insights 診斷修正，一次只處理一類問題。

【目標頁面】
https://example.com/某篇文章/

【這次只要處理】
（例如：LCP 首圖太慢 / CLS 圖片缺尺寸 / 第三方 JS 長任務）

【PageSpeed Insights 原文診斷】
（貼 Opportunities、Diagnostics、LCP element）

【專案限制】
- 只改與這次問題直接相關的模板、CSS、圖片或 JS
- 不要改 URL、permalink、追蹤 ID
- 不要一次「整站優化到 100 分」

改完請跑本機 build，確認沒有錯誤。

LCP 慢：先找真正的最大元素

最常見錯誤：把首屏圖片加上 loading="lazy"。

<img
  src="/img/hero.webp"
  width="1200"
  height="630"
  alt="文章主視覺"
  loading="eager"
  fetchpriority="high"
/>

檢查項目：

  • WebP／AVIF 格式與適當尺寸
  • 正確 width／height
  • 只有 1–2 個關鍵資源用 fetchpriority="high"
  • 圖片管道輸出的 srcset 是否合理

詳見 LCP 首屏圖優化。

CLS：先補尺寸

  1. 全站 <img> 是否有 width／height 或 aspect-ratio
  2. iframe 是否有固定比例容器
  3. web font 是否造成文字換行跳動
  4. 頂部橫幅是否在內容上方突然插入

11ty 的好處：可在共用 layout、shortcode 或 Image Transform 統一修正，不必逐頁改 WordPress 編輯器。

INP：盤點第三方 JavaScript

腳本類型處理方式
不再使用的追蹤／聊天直接移除
非關鍵分析延後到 loaded 或 idle
點擊才需要的功能互動後載入
精準轉換事件保留即時路徑

GTM 不能只看 gtm.js 大小——容器裡的 Pixel、Hotjar 等可能造成長任務。延後載入後要驗證事件是否仍送出。見 GTM requestIdleCallback。

為什麼 11ty 比 WordPress 更容易直接修？

PSI 問題11ty 修改位置WordPress 常見限制
LCP 圖片慢template、eleventy-img、HTML 屬性佈景主題、圖片外掛、編輯器
CLS 位移layout、CSS、Image Transform主題元件、廣告外掛動態插入
JS 阻塞直接刪除或延後腳本外掛依賴特定載入順序
TTFB 偏高靜態輸出、CDNPHP、資料庫、快取外掛

11ty 的問題通常是「我知道哪個檔案要改」；WordPress 常是「我知道哪裡慢，但改了會不會破壞整站？」

AI 加速修正，但不自動批准部署

AI 適合把 PSI 診斷轉成 patch，但流程應是：

  1. 講清楚診斷、目標指標、禁止改動範圍
  2. 一次只改一個檔案或一類問題
  3. 讀 diff，確認沒改 URL、追蹤 ID
  4. 本機 build，檢查輸出 HTML
  5. 瀏覽器點一輪（選單、搜尋、深色模式）
  6. 重跑 PSI，記錄前後差異

總審核清單

  1. 範圍：diff 是否只涵蓋約定問題？
  2. 正確性：輸出 HTML 是否對應診斷？
  3. 回歸：導覽、搜尋、表單是否正常？
  4. 資料：GTM／分析事件是否仍在？
  5. 驗證：目標指標改善？其他指標有沒有變差？

什麼情況不該只為了 PSI 換 11ty？

情況建議
文章教學為主、願意用 Git評估 11ty 或部分靜態化
WP 站簡單，只是圖片腳本沒整理先優化圖片、快取、外掛
每天靠後台編輯、無技術人員留 WordPress，找可安全調整的瓶頸
電商、會員、複雜表單是核心留 WP 或 headless WP + 靜態前台

換 11ty 不是 SEO 自動升級——URL、301、sitemap、內容品質仍要維護。

結語

最值得記住的三件事：

  • LCP：找真正的最大元素，首圖不要盲目 lazy-load
  • CLS：先補圖片尺寸和版面預留
  • INP：盤點第三方 JavaScript，延後後驗證分析資料

選一個代表性頁面跑 PSI，把第一個具體診斷貼進提示詞骨架，做最小修改，用審核清單過完再重測。先從一個問題開始，比一次「整站優化到 100 分」更容易得到可驗證的結果。

參考資料