沒有一杯咖啡解決不了的效能問題；如果有，就先把 PageSpeed Insights 的診斷報告打開，看看是哪個資源在拖後腿。

我做 11ty 網站效能優化時，通常會先把網址丟進 PageSpeed Insights，看它指出的具體問題，再回到 11ty 的模板、CSS、圖片設定或 JavaScript 原始碼逐項修正。很多「改 HTML 屬性、補尺寸、延後腳本」這類步驟，其實可以交給 AI 動手；你負責寫清楚提示詞，再審核 diff 與實際結果。

這個流程在 11ty 上很直接：首圖太大，就處理首圖；圖片沒有明確寬高，就改 HTML 或圖片管道；第三方 JavaScript 阻塞主執行緒，就延後或移除那支腳本。改完重新 build、部署，再用相同條件測一次。

WordPress 當然也能優化，但問題有時藏在佈景主題、頁面編輯器、快取外掛和圖片外掛互相疊加的結果。你可能知道 PageSpeed Insights 要求什麼，卻不知道哪一層才是可以安全修改的地方。

這篇記錄我如何把 PageSpeed Insights 的建議轉成 11ty 的實際修改。重點不是宣稱哪個框架永遠比較快，而是：在 11ty 裡，診斷結果通常可以直接對應到你能控制的模板、資產或腳本。

目錄

先說結論：PageSpeed Insights 是診斷工具，不是框架評分表

PageSpeed Insights 不能單獨拿來比較 11ty 和 WordPress 誰比較快。它會提供實驗室資料與欄位資料，兩者用途不同：

  • Lighthouse 實驗室資料：適合重現問題、觀察剛做的改動。
  • Chrome 使用者體驗報告（CrUX）欄位資料：反映真實使用者的體驗，通常看第 75 百分位。

新網站流量不足時，可能暫時沒有 CrUX 資料。這時仍然可以先用 PageSpeed Insights 和 Lighthouse 做預防性優化，但不要把一次測試的分數當成網站的永久成績單。

我會先看這三個 Core Web Vitals 指標：

指標它在看什麼我通常先檢查什麼
LCP首屏最大文字或圖片多久出現hero 圖片、TTFB、阻塞 CSS、圖片是否被 lazy-load
CLS頁面載入時是否跳動圖片寬高、字體、嵌入內容和廣告預留空間
INP使用者點擊或輸入後多久得到回應第三方腳本、GTM、搜尋或互動元件

如果 PageSpeed Insights 顯示 95 分，但 Search Console 的 Core Web Vitals 仍有大量需要改善的 URL，我不會只看著實驗室分數自我安慰，而會回頭確認真實裝置和真實網路條件。

我的 11ty 優化循環：測量、定位、直接修改、再驗證

我通常照下面的順序做：

  1. 固定同一個 URL 或首頁當測試條件，先跑 PageSpeed Insights，記下 LCP、CLS、INP、FCP 和診斷項目。
  2. 找出問題對應的實際 HTML 元素或網路請求，例如「LCP 元素」是哪張圖，或是哪支腳本造成長任務。
  3. 把診斷原文貼給 AI，一次只請它改一類問題（例如只修 LCP 首圖），並寫清楚「不要動哪些檔案」。
  4. 在本機 build，檢查輸出的網頁是否真的產生預期的 HTML 和資產。
  5. 部署後用相同 URL 重跑 PageSpeed Insights，記錄改了什麼、分數和診斷如何變化。
  6. 如果是 GTM 或分析工具，除了看效能，也確認事件和轉換追蹤沒有被犧牲。

一次只改一類問題，比較容易判斷因果。這一輪只處理圖片，下一輪再處理第三方腳本；如果同時換模板、換 CDN、刪掉五個外掛，最後就算分數變好，也很難知道真正有效的是什麼。

通用提示詞骨架（可複製後改診斷內容）

無論修 LCP、CLS 還是腳本，我都會先用類似這樣的骨架：

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

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

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

【PageSpeed Insights 原文診斷】
（把 Opportunities、Diagnostics、LCP element、相關 network request 整段貼上）

【專案限制】
- 只改與這次問題直接相關的模板、CSS、圖片設定或 JS
- 不要改 URL、permalink、追蹤 ID、部署腳本、與效能無關的內容文案
- 不要一次「整站優化到 100 分」
- 改完請說明改了哪些檔案、為什麼這樣改，並列出我應手動驗證的項目

請先定位對應檔案與輸出 HTML，再提出最小修改。改完請跑本機 build（若專案有現成指令），確認沒有 build 錯誤。

提示詞寫得越具體，AI 越不會順便重構半個站。咖啡加太多糖也不好喝；優化提示詞也一樣，甜度要剛好。

PageSpeed Insights 指出 LCP 慢：先處理首圖

LCP 常常是文章首圖、hero 圖或 H1。最常見的錯誤，是把首屏圖片也加上 loading="lazy"。懶載入適合視窗外的圖片，但會讓瀏覽器更晚發現 LCP 資源。

我會先做幾件事：

  • 把圖片轉成 WebP 或 AVIF。
  • 讓圖片尺寸接近實際顯示寬度，不要把幾千像素的原圖直接送給手機。
  • 為圖片寫上正確的 width 和 height。
  • 首屏圖片視情況使用 loading="eager" 和 fetchpriority="high"。
  • 只有最重要的一、兩個資源使用高優先權，不要所有圖片都搶同一個優先級。

例如首圖可以像這樣：

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

如果網站圖片很多，我會再導入 @11ty/eleventy-img。它可以在 build 時產生多種格式和寬度，並補上圖片尺寸與 srcset。這比每次寫文章都手動處理圖片可靠。

不過圖片管道的預設值仍要檢查：如果 Transform 預設把圖片設成 lazy，hero 圖就要個別覆寫。

給 AI 的提示詞範例（LCP）

請只處理 LCP，不要動第三方腳本，也不要順便改 CLS 版面預留。

PageSpeed Insights 指出 LCP 元素是：（貼上 LCP element 截圖或文字，例如 article hero img）
目前問題可能包含：圖片過大、格式不是 WebP/AVIF、誤用 loading="lazy"、缺少 fetchpriority、缺少明確 width/height。

請在這個 11ty 專案中：
1. 找出產生該 LCP 圖片的 Markdown / layout / Image Transform 設定
2. 讓首屏圖片改為 loading="eager"、fetchpriority="high"，並確保有 width/height
3. 確認視窗外圖片仍可 lazy-load，不要全站改成 eager
4. 若已使用 @11ty/eleventy-img，優先在既有管道調整，不要另開一套圖片流程
5. 改完說明輸出 HTML 應長什麼樣子，並列出我要驗證的項目

AI 做完後，你要審核什麼（LCP）

  • diff 範圍：是不是只動了首圖／hero 相關模板或圖片設定，沒有順便改追蹤碼或全站 CSS。
  • 輸出 HTML：本機 build 後打開該頁原始碼，確認 LCP 圖真的是 eager + fetchpriority="high"，且有 width/height。
  • 不要誤傷下文圖片：文章中段、側欄、相關文章縮圖仍應 lazy；若全部變 eager，會反而搶頻寬。
  • 實際載入：用瀏覽器 DevTools Network，確認首屏圖優先被請求，且尺寸合理（不是幾千像素原圖硬塞手機）。
  • 重測：同一 URL 再跑 PageSpeed Insights，看 LCP 與「Improve image delivery」類診斷是否改善。

PageSpeed Insights 指出 CLS：先補尺寸，不要只調分數

CLS 的問題常常不是 11ty 本身造成，而是輸出的 HTML 沒有告訴瀏覽器圖片會佔多大空間。圖片載入後才撐開版面，讀者原本要點的按鈕就可能被推走。

我的檢查順序是：

  1. 找出全站 <img>，確認是否都有真實的 width 和 height，或有可預期的 aspect-ratio。
  2. 檢查 YouTube、社群貼文和其他 iframe 是否有固定比例或預留高度。
  3. 檢查 web font 載入後是否造成文字換行和版面位移。
  4. 檢查 cookie、聯盟揭露或廣告區塊是否在內容上方突然插入。

這也是 11ty 好處很明顯的地方：我可以在共用 layout、shortcode 或 Image Transform 統一修正，不必逐頁打開 WordPress 編輯器，也不必猜某個外掛會不會在前端再次改寫 HTML。

給 AI 的提示詞範例（CLS）

請只處理 CLS（版面位移），不要改 LCP 優先權策略，也不要動分析／GTM 載入時機。

PageSpeed Insights 診斷：（貼上 layout shift 相關項目、受影響元素）

請在這個 11ty 專案中：
1. 找出缺少 width/height 的 <img>，以及可能造成位移的 iframe、字體、上方橫幅
2. 在 layout、shortcode 或 Image Transform 統一補上真實尺寸或 aspect-ratio
3. 若有 YouTube／社群嵌入，請用固定比例容器預留空間
4. 不要用「把內容延後載入」這種方式假裝解決 CLS
5. 改完列出改動檔案，並告訴我應在哪些頁面用肉眼看載入過程有沒有跳動

AI 做完後，你要審核什麼（CLS）

  • 尺寸是真的，不是亂填：width/height 要對應實際比例；亂填會讓圖片被壓扁或裁切。
  • 全站一致性：共用 layout／Transform 改過後，抽查首頁、文章頁、分類頁各一頁，確認不是只修了示範頁。
  • 字體與橫幅：若 AI 只補了圖片尺寸，但診斷點的是 web font 或頂部通知條，要退回請它對準真正元素。
  • 肉眼驗證：硬重新整理時盯著標題與按鈕位置，載入過程不應上下跳；必要時開 DevTools 的 Layout Shift regions。
  • 重測：同一條件重跑 PageSpeed Insights，確認 CLS 下降，且沒有為了 CLS 把首圖又改回有害的 lazy。

PageSpeed Insights 指出 JavaScript 太多：先問這支腳本真的需要嗎？

純文章型 11ty 網站可以預設不載入 JavaScript，但只要加上 GA4、GTM、聊天工具、社群分享 SDK 或搜尋功能，INP 和主執行緒就可能開始變差。

我會先做腳本盤點：

腳本類型我的處理方式需要注意的取捨
不再使用的追蹤或聊天工具直接移除先確認沒有業務依賴
非關鍵分析延後到 window loaded 或 idle早期 pageview 可能遺失
使用者點擊後才需要的功能點擊時才載入第一次互動可能需要等待
需要精準記錄的轉換事件保留即時路徑或精簡標籤不能只為了效能犧牲轉換資料
社群分享優先用普通連結取代 SDK互動效果較少，但前端更輕

GTM 不能只看 gtm.js 檔案大小。真正的成本可能來自容器裡的 Facebook Pixel、Hotjar、GA4 或其他標籤執行後造成的長任務。

如果採用 requestIdleCallback 或互動後載入，也要測試事件是否仍能在導向前送出，不能只看分數變好了就算完成。瀏覽器分數變漂亮了，分析資料卻少一半，這種優化就像把咖啡杯擦得發亮，結果裡面根本沒有咖啡。

給 AI 的提示詞範例（第三方 JavaScript）

請只處理第三方／非關鍵 JavaScript 對 INP 與主執行緒的影響，不要改圖片與版面尺寸。

PageSpeed Insights 診斷：（貼上 Unused JavaScript、Reduce JavaScript execution time、長任務、相關 URL）

腳本盤點現況（請先對照專案後再改）：
- 必須保留且需準確的：（例如 GA4 轉換、主要 pageview）
- 可延後的：（例如非關鍵分析）
- 可改為點擊才載入或改成普通連結的：（例如社群 SDK）
- 可移除的：（例如已停用的聊天工具）

請提出最小修改：
1. 先盤點 layout／site.js 實際載入了哪些腳本
2. 依上表延後、互動後載入或移除；不要默默刪掉我標記為必須保留的追蹤
3. 若使用 requestIdleCallback 或 loaded 後載入，請說明對早期 pageview 的取捨
4. 改完列出我應如何驗證：效能重測 + 分析事件是否仍會送出

AI 做完後，你要審核什麼（JavaScript）

  • 業務依賴：確認沒有刪掉仍在用的聊天、廣告、轉換標籤；diff 裡出現追蹤 ID 變更要特別小心。
  • 載入時機：非關鍵腳本是否真的延後；關鍵轉換路徑是否仍即時或有可接受的備援。
  • 功能回歸：搜尋、主題切換、表單、分享按鈕在本機點一輪，確認第一次互動不會整頁壞掉。
  • 分析驗證：開 GA4／GTM 預覽或 Network 過濾相關請求，確認 pageview／轉換在典型瀏覽路徑仍會送出。
  • 重測：同一 URL 看 INP／主執行緒診斷是否改善；分數變好但事件消失，這輪算失敗，要回滾或縮小範圍。

為什麼同一個建議，在 WordPress 上常常比較難落地？

這不是說 WordPress 完全不能優化。簡單、乾淨的 WordPress 站也可能有很好的效能；反過來，11ty 如果塞滿大圖、第三方腳本和錯誤模板，也一樣會拿到差分數。

差異在於問題的可控程度：

PageSpeed Insights 顯示的問題11ty 常見修改位置WordPress 常見限制
LCP 圖片太慢Markdown、template、eleventy-img、HTML 屬性佈景主題、圖片外掛、頁面編輯器可能都有關聯
CLS 版面位移layout、CSS、Image Transform主題元件、廣告或外掛動態插入內容
CSS 太多直接整理模板和 CSS主題與外掛各自載入，停用可能影響版面
JavaScript 阻塞直接刪除、延後或修改載入策略外掛可能依賴特定順序，更新後又重新注入
TTFB 偏高靜態輸出、CDN、快取設定PHP、資料庫、主機和快取外掛互相影響

簡單說，WordPress 的問題常是「我知道哪裡慢，但改了會不會破壞整個站？」；11ty 比較常是「我知道哪個檔案要改，改完 build 驗證就好」。

我會用 AI 加速修正，但不會讓 AI 直接亂改整站

AI 很適合把 PageSpeed Insights 的診斷轉成候選 patch，例如：

  • 找出 layout 中所有沒有尺寸的圖片。
  • 檢查 hero 圖是否誤用了 lazy-loading。
  • 依目前的模板補上 fetchpriority 或 srcset。
  • 找出可能重複載入的 CSS 和 JavaScript。
  • 產生一個小範圍的 CSS 或模板修改。

但我會把 AI 當成能快速工作的實習生，而不是自動批准的部署工具。我的流程是：

  1. 先把 PageSpeed Insights 的原文診斷、目標指標和不能改動的範圍講清楚。
  2. 要 AI 一次只改一個檔案或一類問題。
  3. 讀 diff，確認它沒有順便改掉 URL、追蹤 ID 或其他不相關設定。
  4. 本機 build，檢查輸出 HTML。
  5. 用瀏覽器實際點一輪，確認圖片、選單、搜尋功能正常。
  6. 重新跑 PageSpeed Insights，並把改動和結果記錄下來。

提示詞要寫清楚的五件事

要寫清楚為什麼重要壞例子
目標頁面 URL避免 AI 改到不相干的模板「把網站變快」
只處理哪一個指標／診斷方便對照前後測結果「LCP、CLS、JS 一次修完」
診斷原文或截圖重點讓 AI 對準真實元素，不是猜「感覺首圖有點慢」
禁止改動的範圍防止誤改追蹤、部署、文案完全不設限制
完成後要回報什麼你審核時有檢查清單「改好跟我說一聲」

AI 交卷後的總審核清單

不管這輪修的是圖片還是腳本，我都會用同一張清單過一遍：

  1. 範圍：diff 是否只涵蓋這次約定的問題？有沒有「順便重構」？
  2. 正確性：輸出 HTML／CSS／JS 是否真的對應診斷（例如修 LCP 卻只改了下文 lazy 圖）？
  3. 回歸：導覽、搜尋、深色模式、表單、內嵌內容是否仍可用？
  4. 資料：若動過 GTM／分析，事件與轉換是否仍正確？
  5. 驗證：同一 URL、相近條件重測後，目標指標是否改善？有沒有其他指標明顯變差？
  6. 紀錄：這輪改了什麼、前後分數／診斷差異寫下來，方便之後回顧或回滾。

AI 可以幫我縮短「從診斷到修改」的時間，但不能替我判斷該不該犧牲分析資料，也不能保證它產生的 HTML 一定符合這個網站的模板結構，最好是本機開發審核做完再部署。

先上線再祈禱，比較像賭咖啡因，不像做優化。

什麼情況不該只為了 PageSpeed Insights 換成 11ty？

如果網站核心是 WooCommerce、會員、論壇、即時資料或複雜表單，WordPress 的動態能力可能比純靜態效能更重要。若團隊每天都需要非技術人員從後台發文，也要把編輯效率算進去。

我會把選擇簡化成這樣：

如果你的情況是比較合理的方向
文章和教學為主，願意用 Git，PageSpeed Insights 長期有明確問題評估 11ty，或先把部分頁面靜態化
WordPress 站很簡單，只是圖片和腳本沒整理先做圖片、快取、外掛和第三方腳本盤點
每天靠後台編輯，沒有技術人員維護 build留在 WordPress，優先找出可安全調整的瓶頸
電商、會員和複雜表單是核心留 WordPress，或評估 headless WordPress 加靜態前台

換成 11ty 也不是 SEO 自動升級。URL、301、sitemap、canonical、內容品質和內部連結仍然要維護。11ty 解決的是「前端和輸出 HTML 更容易控制」，不是替你完成整套 SEO。

結語：把診斷建議變成可執行的工作清單

我喜歡用 11ty 做效能優化，並不是因為它能保證每個網站都拿到滿分，而是因為 PageSpeed Insights 指出問題後，通常可以直接找到對應的模板、CSS、圖片或腳本來修改。

最值得記住的三件事：

  • LCP 先找真正的最大元素，首圖不要盲目 lazy-load；提示詞要貼診斷原文，審核輸出 HTML 的 eager／fetchpriority。
  • CLS 先補圖片尺寸和版面預留；審核時確認尺寸是真比例，並用肉眼看載入有沒有跳。
  • INP 先盤點第三方 JavaScript；AI 延後腳本後，一定要驗證分析和轉換資料還在。

如果你也在維護 11ty 網站，可以先選一個代表性頁面跑一次 PageSpeed Insights，把第一個最具體的診斷貼進上面的提示詞骨架，讓 AI 做最小修改，再用同一張審核清單過完、相同條件重測。先從一個問題開始，通常比一次叫 AI「把整站優化到 100 分」更容易得到可驗證的結果。審完，再來一杯咖啡。

參考資料