光輝咖碼

為什麼要發明 Pi？從作者角度理解 Pi vs Claude Code 該怎麼選

2026-08-07T03:32:15Z

終端裡的 AI 程式助手越來越多：Claude Code、Cursor，還有各種「多代理＋Plan Mode＋MCP」大禮包。功能清單看起來很強，但你有沒有遇過這種感覺——工具一更新，行為就變了；你以為它在「幫你想」，其實有一段上下文是介面看不到的；出錯時又不知道該查哪一層？

（有點像咖啡店改菜單：你點的還叫同名，內容卻換了豆。AI 工具也會這樣，而且通常不會在杯子上貼告示。）

Pi Coding Agent 的作者 Mario Zechner，正是從這類痛點出發，選擇重做一個極小核心，而不是繼續往既有工具堆功能。這篇不做沒有實測根據的「誰比較強」評比，也不喊誰全面勝利；目標很單純：用作者為什麼要發明 Pi 當鏡頭，幫你看懂兩種哲學，再決定自己要的是 Pi 的可控性，還是 Claude Code 的現成工作流。

讀完你會帶走：作者動機怎麼對到設計、四個原則怎麼想、一張決策表幫你 30 秒對號入座。

先講清楚：這不是「Claude Code 不好」

作者的公開文章把 Claude Code 當成「既有 Coding Agent 逐漸變複雜」的對照例子——但那是他對自己工作流的取捨，不是對所有人的判決。以下的功能描述以相關官方文件與文章目前列出的內容為準；這類工具更新很快，實際行為仍要以你使用的版本和設定為準。

Claude Code 適合：想要內建 Plan、子代理、MCP、斜線指令，少自己組裝。
Pi 適合：想看見上下文與中間產物、把工作流放在檔案／CLI／tmux，願意自己決定要加什麼。

讀完這篇，你應該能回答一句話：「我比較怕黑箱變動，還是比較怕自己組工具的成本？」

答得出來，比背一百個功能還有用——功能清單只告訴你「有什麼」；真正幫你判斷怎麼修、怎麼選的，是你對工具的使用原則。

作者為什麼要重新做一個 Coding Agent？

既有工具遇到的問題（作者說法）	Pi 的設計回應	你實際可以怎麼用
Claude Code 從早期較簡單，逐漸變成作者用不到很多功能的複雜工具；發布常改 system prompt／工具定義，既有工作流與模型行為跟著變	核心「不需要就不建」；短 system prompt；差異放到外部擴充	固定自己的提示、`AGENTS.md`、驗證流程；升級後重新檢查，不要假設行為永遠不變
Context engineering 很重要，但其他 harness 可能在 UI 看不到的地方注入上下文	Session、工具呼叫、來源與產物保持可見；規劃寫成檔案，不藏在黑箱代理裡	要求 Agent 把研究／計畫／檢查結果寫成可讀檔，人工看完再進下一階段
內建子代理把上下文傳遞與錯誤藏在另一層，出錯難追查	不提供專用子代理工具；需要時用 bash 再開一個 Pi，或用 Extension／Package 自己組	任務邊界與輸出格式清楚才拆 session，中間產物一律存檔

一句話總結作者動機：

當 Coding Agent 變得複雜、常改又不透明時，最可靠的回應不是再加一層功能——而是縮小核心、提高可觀測性，讓使用者自己決定要加什麼。

官方定位也呼應這點：「讓 Pi 適應你的工作流，而不是反過來。」——翻成口語：工具來遷就你的終端習慣，不是你遷就它的儀式流程。咖啡機有預設模式很方便；但如果你想自己調研磨度，誰也不能禁止你拿出手沖壺。

Pi 的四個設計原則（對照 Claude Code 怎麼想）

1. 極簡核心，不是功能競賽

作者文章描述：Pi 的 system prompt 與預設工具定義合計可低於約 1,000 tokens；預設核心大致是讀、寫、編輯與 bash。極簡不是叫大家永遠只用四個工具，而是把 MCP、子代理、Plan Mode 等能力移到 Extensions、Skills、Prompt Templates、Packages——按痛點再加。這裡的「四個」是核心設計的概括，不代表每個版本或擴充後都只剩四項能力。

Claude Code 走另一條路：代理人循環（收集上下文 → 執行動作 → 驗證結果）＋較豐富的內建工具與斜線指令（如 /compact、/diff、/model），並以 CLAUDE.md、Skills、MCP 擴充。對「我想立刻開工」的人，這通常比較省事。

白話對照：Claude Code 像開箱即用的咖啡機；Pi 像手沖壺——多一步，但你看得見水溫、粉量和時間。

2. 可觀測性優先

Pi 偏好把計畫寫成 Markdown：人可以編、跨 session 重用，也能進版本控制。「Agent 做了什麼」變成可檢查的產物，而不是只信最後一句摘要。換句話說，規格、計畫和進度先落檔，人工過目再寫碼；這種做法也比較容易留下日後能追溯的線索。

Claude Code 也有規範檔與驗證迴圈，但作者批評的重點是：若規劃與子工作藏在內部狀態，除錯成本會變高。你若本來就習慣「先看 diff／計畫再准執行」，兩套都能做；差別在於狀態預設放在哪——檔案系統，還是工具內建流程。

3. 用組合取代內建一體化

Pi 刻意不內建	官方建議替代	什麼時候值得自己組
MCP	小型 CLI＋README，或自行加 Extension	工具少、要控 token、輸出想直接寫檔串接
子代理	tmux 再開 Pi、Extension、Package	要看見子過程，或真的要平行任務
Plan Mode	計畫寫入檔案，或自行擴充	計畫要跨 session、共同編輯、版控
背景 bash	tmux	長跑測試、開發伺服器、互動除錯
權限彈窗	容器／隔離帳號／自訂確認	不可信程式碼或機密資料

作者對大型 MCP 的具體顧慮是：工具說明每次塞進上下文，token 貴，輸出還常得繞回 Agent 才能保存。他提的替代是「小型 CLI + README + bash」——需要時才讀，輸出可直寫檔。

Claude Code 官方文件列有 MCP 整合，對「接資料庫／瀏覽器／外部服務、不想自己包 CLI」的人是加分。你要選的是：內建方便 vs 按需載入、看得見成本。

4. 安全責任放回執行環境

Pi 預設不走「權限彈窗＝安全」這條路；作者認為 Agent 一旦能讀寫檔、跑指令，單靠彈窗很難形成完整邊界。這不是宣稱 Pi 比較安全，而是要求你用容器、隔離帳號、網路限制等真邊界。含機密的主機開 YOLO，風險在你，不能照抄作者個人設定。

Claude Code 提供權限確認與相關隔離選項；對不想自己從零設計沙箱的人，通常比較「有提示、有流程」。兩邊都不是魔法盾——差在預設假設誰負責安全，而且最後仍要由你確認實際的執行環境。

比喻	對應的做法	實際效果
門上貼「請勿打擾」	Agent 跳出權限彈窗，你點「允許」	只是提醒／確認，對方真要闖還是進得去
門鎖上了	容器、隔離帳號、網路限制	物理／技術邊界，進不去才是真隔離

彈窗是禮貌的提示；隔離才是真的鎖門。兩者看起來都在「管安全」，保護力差很多。

決策表：我該選 Pi 還是 Claude Code？

用這張表做決定（可以兩邊都裝，但同一目錄不要同時寫檔；要並行請用不同 worktree 或其他隔離方式）：

你的情境	較適合	先確認這件事
想快速使用整合好的流程，不想自己組工具	Claude Code	能否接受 system prompt、工具與版本變動
想逐步檢查上下文與中間產物、計畫要進 Git	Pi（或同等可觀測工作流）	是否願意維護 markdown、CLI、tmux
已在使用 Anthropic 生態、愛斜線指令與內建任務工作流	Claude Code	MCP／Skills 的 token 與權限範圍
本地模型、控 token、設定要可移植（`AGENTS.md`、`.pi/`）	Pi	短 prompt 在你的模型／專案規模是否夠用（要實測）
要查瀏覽器、資料庫、外部服務，且想少寫 glue code	Claude Code＋MCP，或 Pi＋按需 CLI／Extension	工具描述成本、輸出能否存檔
不可信程式碼或機密檔案	先隔離，再選任一 Agent	隔離是否真限制檔案與網路，而不只是警告

30 秒口訣

怕黑箱與升級打破工作流 → 先試 Pi。
怕自己組裝與維護成本 → 先用 Claude Code。
都要一點 → 主流程用 Claude Code／IDE；終端批次、低成本實驗、可版控的 Agent 設定用 Pi。

工具	適合誰	備註
Pi Coding Agent	想要極簡核心、可觀測產物、按需擴充的終端使用者	先用裸 Pi 跑通小任務，再加 Package／Extension
Claude Code	想要整合代理人工作流、MCP 與專案規範的 Anthropic 生態使用者	用 `CLAUDE.md` 固定專案規範；升級後抽查行為
延伸閱讀	想系統學 Pi 工作流	站內：Pi Coding Agent 完整指南

結語：選哲學，再選按鈕

作者發明 Pi，不是為了「功能贏過 Claude Code」，而是為了在複雜、常改、不透明的 Coding Agent 浪潮裡，留下一個看得見、擴得動、核心夠小的 harness。這個選擇不一定讓每個人都更省事，卻讓取捨本身變得比較清楚。

帶走三點：

動機：縮小核心＋可觀測性，對抗黑箱與工作流被升級拆掉。
取捨：Claude Code 用整合換省心；Pi 用組合換控制權。
下一步：用上面的決策表對號入座，不要只比功能勾選清單。

先挑一個小任務（例如修一個測試失敗）——若你要「開箱即用」，用 Claude Code 跑完並檢查差異；若你要「計畫與驗證都落檔」，用 Pi 把計畫寫成 Markdown 再改碼。跑完一次，比再讀十篇比較文更準。畢竟工具比較文可以收藏，失敗的測試不會因為被收藏就自己修好。

審完再來一杯。下一杯建議：直接動手，別再收藏文章了。

參考資料

What I learned building an opinionated and minimal coding agent — Mario Zechner 說明為何做極簡 Pi、對照既有 Coding Agent 的痛點
What if you don't need MCP at all? — 作者對大型 MCP 成本與「小型 CLI + README」替代方案的論點
Pi coding agent README — 官方定位、刻意不內建項目與擴充方向
Pi Coding Agent 官網 — 產品入口與文件入口
Anthropic Claude Code 官方指南 — Claude Code 的工作方式、MCP、CLAUDE.md 與擴充能力
Building Pi, and what makes self-modifying software so fascinating — Pragmatic Engineer 訪談／整理，補作者背景脈絡

我如何用 PageSpeed Insights 優化 11ty 網站：為什麼比 WordPress 更容易直接修

2026-08-06T01:25:00Z

沒有一杯咖啡解決不了的效能問題；如果有，就先把 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 優化循環：測量、定位、直接修改、再驗證

我通常照下面的順序做：

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

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

如果要在本機重現，先讓網站用和正式環境接近的方式完成 build，再用 Lighthouse 測試可存取的 URL。不要直接拿開發伺服器的熱更新狀態和正式網站比較，否則很容易把「開發工具的噪音」誤認成效能問題。

pnpm run build
pnpm exec lighthouse https://example.com/某篇文章/ \
	--output=html \
	--output-path=./lighthouse-report.html \
	--chrome-flags="--headless"

PageSpeed Insights 適合看整體診斷與欄位資料；Lighthouse 則適合在你能控制的測試環境裡重現問題。兩者不是互相競爭的咖啡師，而是不同杯型的量杯。

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

無論修 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，但不能只憑猜測決定。先在報告裡確認 LCP element，再針對那個元素處理。最常見的錯誤，是把首屏圖片也加上 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。這比每次寫文章都手動處理圖片可靠。

不過圖片管道的輸出仍要檢查：即使圖片工具產生了 srcset，也不代表瀏覽器一定會用到最適合的候選檔案；而且 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 沒有告訴瀏覽器圖片會佔多大空間。圖片載入後才撐開版面，讀者原本要點的按鈕就可能被推走。

我的檢查順序是：

找出全站 <img>，確認是否都有真實的 width 和 height，或有可預期的 aspect-ratio。
檢查 YouTube、社群貼文和其他 iframe 是否有固定比例或預留高度。
檢查 web font 載入後是否造成文字換行和版面位移。
檢查 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 或互動後載入，也要測試事件是否仍能在導向前送出，不能只看分數變好了就算完成。瀏覽器分數變漂亮了，分析資料卻少一半，這種優化就像把咖啡杯擦得發亮，結果裡面根本沒有咖啡。

下面是概念範例，不是可以直接套到所有分析工具的通用初始化碼。實際使用前，仍要依工具文件確認初始化順序、事件佇列和瀏覽器支援情況：

const loadAnalytics = () => {
	// 在這裡載入或初始化非關鍵分析工具。
};

if ('requestIdleCallback' in window) {
	window.requestIdleCallback(loadAnalytics, { timeout: 2000 });
} else {
	window.setTimeout(loadAnalytics, 2000);
}

requestIdleCallback 是「有空再做」的安排，不是「一定在某個時間完成」的保證；timeout 也不是分析事件送達的保證。若事件很重要，應該設計可接受的備援，並用瀏覽器 Network 或工具的除錯模式確認它真的送出。

給 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 當成能快速工作的實習生，而不是自動批准的部署工具。我的流程是：

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

提示詞要寫清楚的五件事

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

AI 交卷後的總審核清單

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

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

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 分」更容易得到可驗證的結果。審完，再來一杯咖啡。

參考資料

PageSpeed Insights — Google 的網頁效能檢測工具，可查看 Lighthouse 實驗室資料與 CrUX 欄位資料。
Lighthouse 文件 — Lighthouse 的用途、報告與本機測試說明。
Web Vitals（web.dev） — LCP、CLS、INP 等 Core Web Vitals 的定義與評估方式。
Largest Contentful Paint（web.dev） — LCP 的計算方式與常見優化方向。
Cumulative Layout Shift（web.dev） — CLS 的成因、計算方式與版面穩定性建議。
Eleventy Image — @11ty/eleventy-img 的官方文件，說明圖片格式、尺寸與 srcset 產生方式。

Pagefind 教學：如何為 Eleventy 靜態網站加入純前端搜尋

2026-08-04T06:51:00Z

Pagefind 教學：如何為 Eleventy 靜態網站加入純前端搜尋

文章一多，讀者只靠導覽列和分類頁，找舊文就像在咖啡渣裡找關鍵字。這時先別急著架資料庫：對以文章為主的 Eleventy 靜態網站來說，Pagefind 通常已經很夠用。

這篇會帶你弄懂 Pagefind 的工作方式，接著完成 layout 標記、build 後建立索引，以及繁體中文搜尋的驗收。讀完後，你應該能判斷 Pagefind 是否適合自己的網站，也知道搜尋失靈時該從哪裡查起。

Pagefind 是什麼？

Pagefind 是在 build 後處理靜態 HTML 的搜尋工具。它會讀取網站輸出的 HTML，建立一組可由瀏覽器載入的索引檔；訪客搜尋時，結果在前端計算，不需要另開一個搜尋 API 或資料庫伺服器。

所以它很適合個人部落格、文件站和產品說明站。文章更新後重新 build，索引也跟著重建。反過來說，如果你的資料需要登入權限、個人化結果或即時更新，Pagefind 不是後端搜尋的替代品——咖啡濾紙也不能拿來當資料庫。

開始前先確認三件事

你需要一個能正常輸出 _site/ 的 Eleventy 專案，並確認共用 layout 的 <html> 有語言標記：

<!doctype html>
<html lang="zh-Hant">
	<head>
		
	</head>
	<body>
		
	</body>
</html>

語言標記不是裝飾。Pagefind 會在索引時讀取 <html lang>，依語言分開建立索引；瀏覽器初始化搜尋時，也會依目前頁面的語言載入對應索引。繁體中文網站通常可以使用 zh-Hant，但仍應用實際文章內容測試。

另外，請先單獨確認 Eleventy build 沒有錯誤。Pagefind 只能處理已經產生的靜態檔案，不能替你修好前一步的模板錯誤。

第一步：選擇 Pagefind UI 版本

Pagefind 的搜尋索引和搜尋介面是兩件事。索引先由 CLI 建立，UI 再載入 /pagefind/ 裡產生的資產。

目前常見的兩種 UI 寫法，不能直接混在一起：

Pagefind 1.4 及更早版本常用 Default UI：載入 pagefind-ui.css、pagefind-ui.js，再用 new PagefindUI(...) 初始化。
Pagefind 1.5 開始提供 Component UI：使用 pagefind-component-ui.css、pagefind-component-ui.js 和自訂元素，例如 <pagefind-modal>。

先看專案的 package.json 版本，再照對應文件操作。本文以 Pagefind 1.4 的 Default UI 示範，因為這是目前專案使用的版本。

在共用 layout 放入 CSS 與搜尋容器：

<link rel="stylesheet" href="/pagefind/pagefind-ui.css">

<div id="search"></div>

接著在 JavaScript 中載入並初始化 UI：

const pagefindScript = document.createElement('script');
pagefindScript.src = '/pagefind/pagefind-ui.js';
pagefindScript.onload = () => {
	new window.PagefindUI({
		element: '#search',
		showSubResults: false,
	});
};
document.body.appendChild(pagefindScript);

你也可以在頁面載入時直接用 <script> 載入；只有在訪客打開搜尋時才載入，則能避免每個頁面一開始都下載搜尋程式。重點是：不論採用哪種載入時機，索引尚未建立前，/pagefind/ 下的檔案都不存在，看到 404 不一定是 UI 寫錯。

第二步：告訴 Pagefind 要索引什麼

Pagefind 預設會處理頁面內容，但你可以用 data-pagefind-body 把範圍縮小，用 data-pagefind-ignore 排除固定介面：

<body>
	<header data-pagefind-ignore>
		網站導覽
	</header>

	<main data-pagefind-body>
		
	</main>

	<footer data-pagefind-ignore>
		頁尾資訊
	</footer>
</body>

這三個標記各自做一件事：

lang="zh-Hant" 提供語言資訊，讓 Pagefind 進行對應的語言處理。
data-pagefind-body 指定頁面真正要被搜尋的內容。
data-pagefind-ignore 排除導覽列、頁尾或分享按鈕，避免固定文字污染每一筆結果。

有一個容易漏掉的規則：只要網站任何頁面使用了 data-pagefind-body，沒有這個標記的頁面就不會被索引。因此，如果首頁、分類頁也要出現在搜尋結果裡，它們同樣要標記搜尋主體。

data-pagefind-ignore 是「排除元素」；它不會讓整頁消失。把它放在 header 或 footer 上，文章正文仍然會被索引。

第三步：在 Eleventy build 後建立索引

先建立網站，再把輸出目錄交給 Pagefind。使用專案已安裝並鎖定版本的 CLI，通常比每次用 npx -y 下載最新版更容易重現：

pnpm exec eleventy
pnpm exec pagefind --site _site --glob '**/*.html'

成功後，輸出目錄會出現 _site/pagefind/，裡面包含索引資料，以及 UI 需要的 JavaScript 和 CSS。Pagefind 本身沒有搜尋後端；這些檔案部署到同一個靜態網站後，瀏覽器就能載入它們。

如果想快速測試，也可以讓 Pagefind 在建立索引後提供本機靜態伺服器：

pnpm exec pagefind --site _site --glob '**/*.html' --serve

這個 --serve 是方便開發時測試的本機伺服器，不是正式環境必須部署的服務。不要直接用 file:// 開啟 HTML，因為瀏覽器的模組載入和 fetch 請求可能受到本機檔案權限限制。

第四步：把流程接進 package.json

手動跑兩個指令可以驗證概念，但很容易忘記第二個。把 Pagefind 接在 Eleventy 後面，每次 build 就會自動更新索引：

{
	"scripts": {
		"build": "NODE_ENV=production ELEVENTY_PROFILE=true pnpm exec eleventy && pnpm exec pagefind --site _site --glob \"**/*.html\""
	}
}

實際專案的 build script 可能還有清理、Vite 或其他收尾步驟；請把 Pagefind 放在「所有 HTML 都完成之後」。如果部署平台只執行 Eleventy，卻沒有執行 Pagefind，正式站自然不會憑空長出搜尋索引。

也可以在 Eleventy 的 eleventy.after 事件裡呼叫 Pagefind，但這會讓 Eleventy 設定檔同時負責建站和啟動外部程序。對多數專案而言，package.json 用 && 串接比較容易看懂、除錯，也能確保前一步失敗時不會誤把舊索引當成新成果。

繁體中文搜尋要怎麼驗收？

Pagefind 支援中文的分詞處理，但中文不像英文那樣以空白分隔；搜尋結果仍然取決於索引內容和查詢方式。這不是「加上 lang 就保證什麼都找得到」，所以請用真正的文章做測試。

部署前至少走過這份清單：

[ ] Eleventy build 成功，沒有模板或資產錯誤。
[ ] _site/pagefind/ 存在，且正式網址能載入 /pagefind/ 下的檔案。
[ ] 搜尋一個確定存在的文章標題，可以回傳結果。
[ ] 搜尋兩三個繁體中文詞組，例如「網站安全」或「靜態網站」。
[ ] 搜尋結果沒有被導覽列、頁尾或分享按鈕的固定文字洗版。
[ ] 修改文章後重新 build，結果中的摘要已更新。

若網站同時有多種語言，請讓每個頁面的 <html lang> 正確反映內容，不要全部硬寫成同一種語言。Pagefind 會依語言分開索引；標記錯誤，等於把書放進錯的書架，搜尋當然會繞遠路。

常見問題排查

搜尋框出現，卻沒有結果

先看瀏覽器 Network 面板：/pagefind/pagefind-ui.js、/pagefind/pagefind-ui.css 和索引檔是否回傳 404。再確認 Pagefind 指向的是包含 HTML 的輸出目錄，而不是專案原始碼目錄。

中文結果很少

檢查 <html lang> 是否存在且寫對，並用文章內確實出現的詞組測試。也檢查 data-pagefind-body 是否誤放在空容器，或文章所在頁面根本沒有這個標記。不要只因為終端機出現 stemming 相關提示就移除語言標記：中文搜尋仍可運作，只是 Pagefind 不會以英文詞幹還原的方式處理中文。

首頁或分類頁沒有出現在結果裡

這通常是 data-pagefind-body 的範圍規則造成的。只標記文章 layout 時，沒有標記的首頁和分類頁會被排除；在同樣希望被搜尋的頁面補上搜尋主體即可。

搜尋結果一直出現導覽列文字

將不需要搜尋的固定區塊加上 data-pagefind-ignore，刪除舊的 _site/pagefind/ 後重新 build。只改模板、不重建索引，搜尋結果不會自己更新——索引沒有讀心術，只有讀檔術。

本機測試看起來壞掉

確認不是用 file:// 開啟 HTML，也確認 Pagefind 產出的 /pagefind/ 路徑和網站部署的 base path 一致。使用 --serve 或其他靜態檔案伺服器重新測試，通常很快就能分辨是瀏覽器載入問題還是索引內容問題。

結語：先解決搜尋，再考慮升級

對大多數 Eleventy 部落格來說，第一版站內搜尋不需要資料庫。你只要：

在 layout 加入與 Pagefind 版本相符的 UI。
設定正確的 lang、data-pagefind-body 和 data-pagefind-ignore。
在每次 Eleventy build 後執行 Pagefind。
用實際的繁體中文查詢驗收。

這樣就能讓讀者搜尋已部署的文章。未來若真的需要會員權限、個人化排序或即時資料，再評估後端或託管搜尋服務；先把今天的搜尋做好，咖啡才不會冷得太有深度。

參考資料

Pagefind 官方文件：總覽、安裝與基本整合方式。
Running Pagefind：說明 --site、--serve 等 CLI 用法。
Customizing the index：說明 data-pagefind-body 與 data-pagefind-ignore。
Multilingual Search：說明 lang、多語言索引與中文分詞。
Pagefind UI Usage：說明 Default UI 的載入和初始化方式。
Eleventy Configuration Events：查閱 eleventy.after 等 Eleventy 事件。

11ty 與 Hostinger 快取怎麼設定？從 .htaccess 到更新驗收

2026-08-04T03:44:00Z

你把新文章部署上去，自己看得到最新版，讀者卻還在看昨天的內容？先別急著重跑 11ty，也別一杯接一杯咖啡地清快取。很多時候，問題不是建置失敗，而是瀏覽器、Hostinger、CDN 或 HTTP headers 還在提供舊檔案。

這篇會帶你用 11ty 建置 _site，再依檔案類型安排 HTML、CSS、JavaScript、圖片、字型和 Pagefind 搜尋資產的快取策略。你也會看到如何在 Hostinger hPanel 清除快取，以及用 curl 檢查公開網站實際回傳的 headers。快取不是壞掉的記憶體，只是它記得比你久了一點。

先記住快取原則

不要把所有檔案都快取一年。比較穩定的分法是：

HTML：短時間快取，或要求瀏覽器重新驗證，因為文章和首頁會更新。
CSS、JavaScript、圖片、字型：如果檔名包含版本號或內容指紋，可以長效快取。
Pagefind 搜尋資產：搜尋索引會隨文章更新，不能直接套用一般靜態資產的一年 TTL。

簡單說，內容頁要容易更新；URL 已經跟著內容改變的資產，才適合快取久一點。

11ty 與 Hostinger 各自負責什麼？

11ty 負責把 Markdown、模板和資產建置成 _site 裡的靜態檔案。它不會替你決定訪客的瀏覽器或 Hostinger CDN 要快取多久。

上線後的快取主要分成三層：

快取層級	作用	更新不生效時先檢查什麼
瀏覽器	減少訪客重複下載檔案	用無痕視窗測試
Hostinger 快取	減少來源站重複處理請求	hPanel 的 Clear cache 或 Cache Manager
CDN	讓訪客從較近的節點取得檔案	依 CDN 介面執行 Purge／Flush

所以，重新執行 11ty 只會更新輸出檔案，不能保證所有快取層立刻換成新版本。

部署前先確認 `_site`

在專案根目錄執行：

npx @11ty/eleventy

本專案的 pnpm run build 還會在 Eleventy 完成後執行 Pagefind，並寫入 _site/pagefind/。如果只是先檢查 Eleventy 輸出，可以執行上面的指令；正式部署則建議直接執行：

pnpm run build

接著確認 _site 裡有：

_site/index.html
最新文章的 HTML
CSS 和 JavaScript
圖片與字型
pagefind/ 搜尋資產（如果網站有使用 Pagefind）

上傳時，要把 _site 裡面的內容放到 Hostinger 的網站根目錄，常見位置是 public_html。不要把整個專案原始碼上傳到公開目錄，也不要多包一層 _site 資料夾。

依專案設定 `public/.htaccess`

本專案的 public/.htaccess 使用 Apache 的 mod_expires、mod_headers 和 mod_setenvif 管理快取與 response headers。下面是與目前設定相同的重點片段；完整檔案還包含重新導向、安全標頭、Gzip 和目錄列表設定。

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 5 minutes"
  ExpiresByType text/html "access plus 3 minutes"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType application/x-javascript "access plus 1 month"
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType image/gif "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
  ExpiresByType image/webp "access plus 1 month"
  ExpiresByType image/svg+xml "access plus 1 month"
  ExpiresByType font/ttf "access plus 1 month"
  ExpiresByType font/otf "access plus 1 month"
  ExpiresByType font/woff "access plus 1 month"
  ExpiresByType font/woff2 "access plus 1 month"
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(?:html?)$">
    Header set Cache-Control "public, max-age=180"
  </FilesMatch>
  <FilesMatch "\.(?:css|js|gif|jpe?g|png|webp|svg|ico|woff2?)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

<IfModule mod_setenvif.c>
  SetEnvIfNoCase Request_URI "^/pagefind/" pagefind_asset
</IfModule>
<IfModule mod_headers.c>
  Header set Cache-Control "no-cache, must-revalidate" env=pagefind_asset
</IfModule>

這些設定分別做什麼？

ExpiresActive On：啟用 Apache 的過期時間設定。
ExpiresDefault "access plus 5 minutes"：沒有特別指定類型的檔案，預設快取五分鐘。
ExpiresByType text/html "access plus 3 minutes"：HTML 的 Expires 基準為三分鐘。
CSS、JavaScript、圖片和字型的 ExpiresByType：先設定為快取一個月，之後資產規則會再設定明確的 Cache-Control。
Cache-Control: public, max-age=31536000, immutable：把符合檔名規則的 CSS、JavaScript、部分圖片、圖示與 woff 字型實際設定為快取一年。
SetEnvIfNoCase Request_URI "^/pagefind/" pagefind_asset：找出 /pagefind/ 開頭的檔案。
Header set Cache-Control "no-cache, must-revalidate" env=pagefind_asset：讓 Pagefind 更新後立即重新驗證。
Strict-Transport-Security：不是檔案快取，而是告訴瀏覽器未來一年都使用 HTTPS；目前也包含 includeSubDomains。

一年快取有一個容易忽略的風險

目前的 <FilesMatch> 是按照副檔名套用一年快取，並沒有檢查檔名是否真的含有內容雜湊。因此沒有版本號的 style.css 或 app.js 也會進入一年快取。如果這些檔案在原 URL 直接更新，訪客可能長時間拿到舊版本。

另一方面，mjs、avif、ttf 和 otf 雖然有一個月的 ExpiresByType，卻不符合目前的 <FilesMatch>，不會拿到一年期的 Cache-Control。要維持一年 TTL，部署流程就必須確保資產 URL 會隨內容改變，或另外為未版本化資產加上較短的規則。

為什麼 Pagefind 需要單獨設定？

Pagefind 的檔案可能同時符合一般 JavaScript 或資產檔案規則，因此先拿到一年的長效快取。接著，env=pagefind_asset 條件會再套用重新驗證的 Cache-Control：

Cache-Control: no-cache, must-revalidate

這個例外很重要：一般資產可以快取一年，但搜尋索引不應該跟著使用同樣長的 TTL。

Header 需要 Apache mod_headers，ExpiresByType 需要 mod_expires，Pagefind 的環境變數需要 mod_setenvif。如果修改 .htaccess 後出現 500 錯誤，先還原修改，再逐段確認 Hostinger 是否支援相關模組與語法。

除了快取，`.htaccess` 還能負責哪些事情？

.htaccess 不只是快取設定檔，也可以集中管理 Apache 網站常見的伺服器規則。以下功能不一定全部都要啟用，應依網站需求和主機支援的 Apache 模組決定：

靜態網站路由：使用 mod_rewrite 管理重新導向或找不到頁面的處理方式。11ty 已經產生檔案式路由時，不要直接套用 SPA 的「全部導向 /index.html」規則，否則原本的 404 和文章路徑可能一起被煮成一鍋。
301 重新導向：將舊網址導向新網址，適合網站改版、文章改名或網址結構變更時使用。大量重定向最好由腳本產生，避免手動維護時遺漏或重複。
安全標頭：可設定 X-Frame-Options、X-Content-Type-Options 等 response headers，降低點擊劫持和 MIME 類型嗅探等風險。新增標頭前，應先確認不會影響網站嵌入或第三方服務。
Gzip 壓縮：使用 mod_deflate 壓縮 HTML、CSS、JavaScript 和 XML 等文字檔，減少傳輸量。JPEG、PNG、WebP 等通常已經壓縮，不需要再次壓縮。
目錄保護：Options -Indexes 可避免訪客直接看到沒有首頁檔案的資料夾列表。
HTTP 導向 HTTPS：使用 mod_rewrite 將 HTTP 請求重新導向 HTTPS。啟用前要先確認 SSL 憑證正常；HSTS 只會要求瀏覽器後續使用 HTTPS，不會代替 HTTP → HTTPS 的重新導向。

修改 .htaccess 前，先確認 Hostinger 支援所需的 Apache 模組與語法。建議一次只加入一個功能，修改後用 curl -I 和瀏覽器測試；若出現 500 錯誤，先還原最近一次修改，再逐段排查。

HSTS 不是檔案快取

這一行：

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

意思是瀏覽器在接下來一年內，連線到這個網站時優先使用 HTTPS。它不會決定 HTML、CSS 或圖片要存多久，因此不要把 HSTS 和 Cache-Control 當成同一種設定。

只有在 HTTPS 已經完全正常，而且所有會使用到的子網域也都能使用 HTTPS 時，才適合啟用較長的 HSTS 期限。

部署後到 hPanel 清除快取

每次部署後，依序做以下檢查：

進入 Hostinger hPanel 的網站 Dashboard，執行 Clear cache。不同方案或 hPanel 版本的選單名稱可能略有不同。
如果只想處理單一頁面，到 Advanced → Cache Manager 輸入 URL 後執行 Purge。
如果網站啟用了 Hostinger CDN，到 Performance → CDN 檢查 CDN 狀態，並依介面提供的選項清除快取。
用無痕視窗重新開啟首頁和剛更新的文章。

不要一開始只清除自己的瀏覽器快取。如果所有訪客都看到舊版本，問題更可能在 Hostinger 快取、CDN 或部署檔案，而不是單一瀏覽器。

用 `curl` 驗收 response headers

檢查首頁：

curl -I https://example.com/

檢查一個版本化資產：

curl -I https://example.com/assets/app.8f31c.css

你可以觀察 Cache-Control、Expires、ETag、Last-Modified、Age 和 Content-Type。

依本專案目前設定，首頁通常會看到三分鐘的 max-age；符合資產副檔名規則的 CSS 則可能看到一年的 max-age。Pagefind URL 則應該要求重新驗證：

curl -I https://example.com/pagefind/pagefind.js

如果重新請求時內容沒有改變，伺服器可能回傳 304 Not Modified，代表條件式快取正常運作。若 curl 已經拿到新內容，但瀏覽器仍是舊內容，再用無痕視窗、另一個網路和 DevTools Network 交叉確認。

快取設定決策表

你的情況	HTML	CSS／JS／圖片／字型	建議
文章常更新，檔名沒有版本號	`no-cache` 或短 TTL	短 TTL，例如 5–30 分鐘	先確保更新穩定，再逐步延長
CSS／JS 有內容指紋	`no-cache` 或一天	一年＋`immutable`	適合穩定的 production 靜態站
正在除錯快取問題	`no-cache`	`no-cache` 或短 TTL	驗收完成後再恢復長效快取
Pagefind 搜尋索引會更新	短 TTL	Pagefind 使用 `no-cache`；其他資產依版本策略	避免搜尋索引長時間未更新
CDN 剛啟用或剛清除	短 TTL	依 CDN 規則	等待節點更新，再用不同網路測試

這張表主要根據兩個問題決定快取時間：檔案多久會更新，以及檔案的 URL 是否會隨內容改變。

HTML 通常使用短 TTL：首頁和文章內容可能經常更新，因此使用短時間快取，讓瀏覽器較快向伺服器確認。本專案目前設定為三分鐘；no-cache 則是另一種要求使用前重新驗證的策略。
有內容指紋的靜態資產可以快取一年：例如 app.8f31c.css。CSS 或 JavaScript 更新後，檔名也會改變，瀏覽器會把它視為全新的檔案，因此適合搭配 immutable 使用一年 TTL。
固定檔名的資產應使用短 TTL：例如 style.css 或 app.js。如果內容更新但 URL 不變，長效快取可能讓訪客持續取得舊檔案；在尚未完成版本化時，可先使用 5–30 分鐘。
Pagefind 使用 no-cache：搜尋索引會隨文章更新，但 URL 通常不一定包含內容指紋，因此每次使用前都應重新驗證。
正在除錯時全部縮短 TTL：先讓 HTML、CSS 和 JavaScript 使用 no-cache 或短 TTL，確認部署與 response headers 正常後，再恢復長效快取。

要注意的是，這張表是判斷原則，不代表目前 .htaccess 已經自動檢查檔名是否含有內容指紋。目前的 <FilesMatch> 是按照副檔名設定一年快取，所以固定名稱的 style.css 或 app.js 也可能被快取一年。只有在部署流程確實會讓資產 URL 隨內容改變時，才適合使用一年 TTL 和 immutable。

常見問題

重新建置後，網站為什麼還是舊頁面？

先確認 _site 裡真的有新內容，再確認上傳的是 _site 內容，而不是原始 Markdown。接著依序檢查 Hostinger 快取、CDN 和瀏覽器，不要只重跑 11ty。

可以把所有檔案都設定成快取一年嗎？

不建議。沒有版本化的 HTML、style.css 或 app.js 可能長時間讓訪客拿到舊內容。只有 URL 會隨內容改變的資產，才適合搭配 immutable 使用一年 TTL。

為什麼 Pagefind 搜尋不到剛發布的文章？

可能是 Pagefind 索引本身沒有重新建置，也可能是 /pagefind/ 資產仍被舊快取提供。先確認部署輸出有最新索引，再用 curl -I 檢查 Pagefind URL 是否真的要求重新驗證，最後清除 Hostinger 或 CDN 快取。

改 `.htaccess` 後網站出現 500 怎麼辦？

先還原最後一次修改，確認 Hostinger 支援 mod_headers、mod_expires 和相關語法，再逐段加入設定。不要在未驗證前，直接把同一份 .htaccess 複製到其他網站。

部署驗收工具

Hostinger hPanel：用來清除網站快取、管理 Cache Manager，以及依方案管理 CDN。
curl：直接查看公開網站的 response headers，先確認伺服器實際回傳什麼，再判斷是不是瀏覽器問題。
Chrome DevTools Network：查看 Age、ETag、Cache-Control 和 response body，交叉確認不同資產是否使用預期的 TTL。

結語：先分層，再決定 TTL

11ty 快取問題的重點不是把數字設得越大越好，而是讓不同檔案採用適合自己的更新策略：

HTML 使用短 TTL，保持容易更新。
版本化 CSS、JavaScript、圖片和字型使用長效快取。
Pagefind 搜尋資產使用 no-cache，避免索引更新被卡住。
每次部署後用 hPanel、curl 和無痕視窗驗收。

完成設定後，下一步是到 Hostinger hPanel 清除快取，再用 curl -I 確認公開網站真的回傳預期的 headers。快取驗收完，再來一杯咖啡；這次咖啡和 HTML 都應該是熱的。

參考資料

Apache mod_expires 官方文件：說明 ExpiresActive、ExpiresDefault 和 ExpiresByType 如何產生快取標頭。
Apache mod_headers 官方文件：查閱 .htaccess 中設定與修改 response headers 的 Header 指令。
Pagefind Running Pagefind：說明在靜態網站建置後產生 pagefind/ 搜尋資產的流程。
Hostinger：Website caching explained：說明 hPanel Cache Manager、瀏覽器快取、伺服器快取與 CDN 的差異。

字型子集化：2026 中文網站如何減少字型載入、改善首屏速度

2026-08-03T07:45:00Z

繁體中文網站最容易被忽略的效能成本，常常不是第三方腳本，而是字型。完整 CJK 字型可能很大；若每位訪客都先下載整包，手機網路就得先端上一杯「等待咖啡」，文字才慢慢穩定下來。

這篇會帶你判斷是否真的需要 Web Font、理解字型子集化與 unicode-range 的差別，最後用自架 WOFF2 的流程把載入成本降下來。重點不是追求某個神奇檔案大小，而是讓字型策略符合網站內容與實際測量結果。

先判斷：你真的需要 Web Font 嗎？

如果網站是內容型部落格、管理後台或文件站，最划算的起點通常是系統字體優先。系統字體不需要額外下載，少了一趟網路請求，也少了一個可能延遲文字顯示的變數：

body {
	font-family:
		system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
		"PingFang TC", "Microsoft JhengHei", "Noto Sans CJK TC", sans-serif,
		"Apple Color Emoji", "Segoe UI Emoji";
}

macOS 與 iOS 常見的是 PingFang TC，Windows 常見的是 Microsoft JhengHei；實際結果仍會受作業系統、已安裝字型與瀏覽器影響。如果你不需要每台裝置都呈現完全相同的品牌字形，這一步可能比任何字型工具更有效。

三種字型策略怎麼選？

可以先用下面的方式縮小選擇：

情境	建議做法	主要取捨
內容型部落格	內文使用系統字體	載入成本低，但不同平台字形不完全一致
品牌官網或 Landing Page	標題使用子集化 Web Font，內文使用系統字體	兼顧美觀與速度，但要維護字元清單
必須固定品牌字形的產品 UI	自架 WOFF2，搭配靜態或分片子集化	控制力最高，也需要加入 build 流程

不要只因為「看起來專業」，就讓整篇內文載入完整的 Noto Sans TC。先把 Web Font 限制在 H1、H2 或少量 UI 元件，通常更容易取得可接受的速度與一致性。字型不是越多越有文化，請求數才不會因此變成詩。

為什麼繁中字型特別容易拖慢首屏？

中文字型需要涵蓋大量漢字、標點與不同字重，因此完整檔案可能遠大於 Latin 字型。一個網站若同時載入多個 CJK 字型族和多個字重，下載量很快就會累積；若使用外部服務，還要考慮連線、CSS 發現時機與字型檔本身的請求。

外部 CDN 不一定比較慢，自架也不保證比較快。實際結果會受到 CDN 位置、HTTP 版本、快取策略、CSS 何時被瀏覽器發現，以及頁面到底匹配到哪些字型分片影響。跨網站共用快取也不能當成必然優勢，所以應該把「外部服務」和「自架」都放進同一套實測裡比較。

字型子集化到底在做什麼？

子集化就是從完整字型中只保留網站需要的字元，再輸出較小的字型檔。HarfBuzz 的 hb-subset 文件也把它描述為縮減字型涵蓋的 codepoint，並移除不再需要的資料。

常見做法有兩種：

靜態子集化：掃描指定頁面或整個網站，只保留目前用到的字元。檔案通常更小，適合內容固定的 Landing Page；但內容更新後必須重跑。
Unicode 分片：把字型切成多個檔案，在 CSS 的每組 @font-face 中用 unicode-range 指定負責的字元範圍。瀏覽器會根據頁面文字判斷要不要載入某個分片，但匹配後下載的是整個分片，不是單獨一個字。

這裡有個容易誤會的地方：WOFF2 格式和瀏覽器不會自動替你切檔。分片需要多組 @font-face、多個 WOFF2 網址，以及對應的 unicode-range。只有一個完整 WOFF2 和一條 @font-face，瀏覽器就只會把它當成一個檔案處理。

Google Fonts 會替你產生包含 unicode-range 的 CSS，某些字型也會依字元或語系切成多個檔案；你只放入 stylesheet 連結，就能使用它預先準備好的分片。自架則要自行產生分片與 CSS，例如使用 cn-font-split。

本站曾以四種字型載入約 23 個 WOFF2 請求、總計約 1.78MB 作為改版前觀測值；後來改用自架子集，並讓內文回到系統字體，目前實際使用的 Web Font 減少到兩個檔案。這是本站某次測量，不是所有網站都會得到相同數字；分片數量減少，也不代表每個頁面一定少下載同樣多的位元組。

子集缺少的字也不會自動變成缺字方框。瀏覽器會沿著 font-family 堆疊尋找下一個可用字型，代價是罕見字可能和周圍文字有些風格差異。因此，子集化完成後要測試特殊人名、專有名詞、全形標點與程式碼符號。

自架子集化的實作流程

1. 收集真正會出現的字元

掃描文章、模板、導覽列、按鈕和錯誤訊息，收集漢字、全形標點、Latin 字母、數字與常用符號。不要只掃一篇文章，否則下一篇新增一個罕見字時，字型就會突然「失憶」。

Latin 部分可以參考字型服務提供的範圍，但仍要依網站實際內容確認，避免英文、貨幣符號或程式碼標點意外 fallback。若標題和內文使用不同字型，也應分別收集，避免把所有文章文字都塞進只套用於標題的字型。

2. 用工具產出 WOFF2

cn-font-split 適合把 CJK 字型切成可按範圍載入的分片；如果想依網站實際用字產出單一子集，可以使用 subset-font。這個 Node.js 套件以 HarfBuzz 的 subset 功能為基礎，會輸出指定格式的字型檔。

概念流程如下：

掃描 Markdown、模板與導覽文字
            ↓
收集 Latin、CJK 與符號
            ↓
subset-font 或 cn-font-split
            ↓
輸出 WOFF2 與必要的 CSS
            ↓
用瀏覽器與效能工具驗證

如果專案已經有腳本，讓它成為固定的 build 步驟會比手動操作可靠。例如本站可在新增內容後執行：

pnpm run subset-fonts
pnpm run build

3. 用 `@font-face` 控制載入行為

最基本的自架設定可以長這樣：

@font-face {
	font-family: "Noto Sans TC";
	src: url("/fonts/noto-sans-tc.woff2") format("woff2");
	font-weight: 400 700;
	font-style: normal;
	font-display: swap;
}

接著在 HTML 中把它套用到真正需要的元素，而不是只宣告卻全站使用：

<h1 class="hero-title">網站標題</h1>

font-display: swap 會先顯示 fallback 字型，字型載入完成後再替換，適合需要優先看見文字的標題。optional 則讓瀏覽器在載入不及時時更傾向維持 fallback；它可以降低字型替換造成版面變化的機會，但不是「完全不會 CLS」的保證。實際顯示時間仍由瀏覽器實作與網路狀況決定。

4. 把子集化接進 build 流程

新增文章或修改導覽列後，重新執行字型腳本，再進行 production build。原始字型可以放在本機快取，避免每次重跑都重新下載；真正重要的是讓「新增內容 → 重新產生子集 → 測量效能」成為固定流程。

5. 移除不再需要的 CDN 標籤

改成自架後，檢查 <head> 裡的 Google Fonts preconnect、preload、stylesheet 和 noscript 標籤。新舊兩套設定同時留下來，等於請瀏覽器喝兩杯咖啡再做同一件事——熱鬧，但沒有比較快。

常見錯誤與取捨

直接上傳 OTF 或 TTF：Web Font 通常優先使用 WOFF2，因為壓縮效率較好且現代瀏覽器支援廣；仍要依你的瀏覽器支援範圍決定是否提供其他格式。
以為分片等於只下載一個字：unicode-range 只負責判斷某個分片是否匹配；匹配後通常會下載整個分片。
只留下漢字、忘了 Latin 和符號：英文、數字、括號或程式碼符號可能改用不同字型，應把實際需要的字元一起納入。
把整個網站都套品牌字體：先從標題或少量 UI 開始，否則字型下載量和替換風險都會快速增加。
忽略子集缺字：fallback 能避免缺字方框，卻不會讓不同字型的字形風格自動一致；上線前要測試罕見字、專有名詞與標點。
只看檔案大小、不測實際體驗：請用 PageSpeed Insights 或自己的效能驗收流程，觀察 LCP、CLS、文字是否及時出現，以及 Network 面板實際下載了哪些字型。

結語：先少載入，再追求一致

字型最佳化可以先記住三件事：

內容站先用系統字體，不要預設整包載入 CJK Web Font。
需要品牌字形時，只把標題或 UI 子集化，並依需求選擇單一子集或 Unicode 分片。
用 font-display、fallback 和實際 Core Web Vitals 測量確認取捨，不要只看理論檔案大小。

下一步很簡單：先記下改動前的數據，挑一個頁面做子集化，再比較 LCP、CLS、字型請求數和實際文字顯示。先測一頁就好，不必一口氣把整個網站的字型 pipeline 變成考古現場。測完再來一杯，這次是慶功。

參考資料

MDN：@font-face：查閱 src、font-display、unicode-range 與 Web Font 格式。
MDN：Web fonts：說明 WOFF2、fallback、子集化與字型實際載入時機。
Google Fonts CSS API：說明 Google Fonts CSS、text 參數與字型請求格式。
HarfBuzz：hb-subset：說明字型子集化如何縮減 codepoint 涵蓋範圍與不必要資料。
subset-font GitHub：Node.js 字型子集化套件的原始碼與使用資訊。
cn-font-split GitHub：CJK 字型分片工具的功能與文件入口。

LCP 優化實戰：首屏別 lazy-load，用 fetchpriority 把關鍵資源拉上來

2026-08-03T06:45:00Z

PageSpeed 分數掉下來，你第一個想到的通常是「圖太大了」。有時候沒錯，但也可能是你把主視覺圖設成 loading="lazy"，等於請瀏覽器「晚點再叫主角上台」——LCP 當然跟著延後，比咖啡涼掉還難受。

LCP（Largest Contentful Paint）衡量的是：初次載入時，視窗內最大的文字、圖片或其他內容元素，何時完成繪製。這篇會帶你找出真正的 LCP 元素，分清楚 lazy、fetchpriority 與 preload 各自解決什麼問題，再用一套可以實際驗收的流程收尾。看完，你不必對著瀑布圖施法，也能知道下一杯咖啡該泡給誰。

先抓到你真正的 LCP 元素

先不要猜「應該是主視覺圖」。LCP 也可能是 H1、文章開頭的大段文字，或其他在初次視窗內佔面積最大的元素。流程如下：

開 PageSpeed Insights 或 Chrome DevTools → Performance 錄一次載入
看報告標出的 LCP 元素 是什麼（圖片、文字區塊或 H1）
記下它的 URL 或 DOM 節點，後面改碼才有對象

在 DevTools 的 Performance 面板中，也可以從 LCP 標記查看元素與時間。先確認「誰是 LCP」，再決定要不要調圖片；不然很容易把不是主角的圖片打扮成 VIP。

靜態網站常見的 LCP 來源包括主視覺圖、H1 標題與產品截圖。以真實使用者資料的評估方式來看，LCP 在第 75 百分位不超過 2.5 秒才算「良好」；這和 Lighthouse 的單次實驗室測試不是同一件事。想先搞懂欄位資料與實驗室資料的差異，可看站內 PageSpeed Insights 與 Core Web Vitals 2026。

決策表：lazy、fetchpriority、preload 怎麼選？

情境	建議做法	為什麼
確認是首屏內的 LCP 圖片	不使用 `loading="lazy"`；必要時加 `fetchpriority="high"`	讓瀏覽器及早發現並下載關鍵圖片
LCP 是 CSS 背景圖，或資源要等 JS 才出現	`<link rel="preload" as="image" fetchpriority="high">`	瀏覽器不容易從初始 HTML 直接發現它，需主動提示
內文圖、頁尾圖、側欄縮圖	`loading="lazy"`	讓頻寬先留給首屏內容
頁面有一、兩張真正關鍵的圖片	只對那些圖片使用 `fetchpriority="high"`	高優先級用太多，反而失去區分效果
本站的 Eleventy Transform 自動補上 `lazy`	在主視覺圖上明確覆寫 `loading="eager"`	內文圖的預設值不一定適合 LCP 圖

一句話心法：首屏 LCP 圖不要 lazy；確認是關鍵資源後再提高優先級；其餘圖片放心 lazy。

LCP 優化策略（核心：優先級 + 不被 lazy）

1. 不要 lazy-load LCP

最常見的壞操作，就是把首屏 LCP 圖片加上 loading="lazy"。瀏覽器通常要先完成版面計算，確認圖片接近視窗後才請求它；原本可以從 HTML 先發現的資源，就被迫排隊。下載、解碼、繪製每一步都往後，LCP 只好一起等。

<!-- ❌ 主視覺圖被延後載入 -->
<img src="/img/hero.webp" loading="lazy" alt="主視覺">

<!-- ✅ 首屏主角：不 lazy，並提示它很重要 -->
<img
  src="/img/hero.webp"
  alt="主視覺"
  width="1200"
  height="630"
  loading="eager"
  fetchpriority="high"
/>

eager 是明確表達「不要額外延後」；它不等於魔法加速器，真正的下載順序仍由瀏覽器決定。fetchpriority="high" 也是提示，不是命令。最後，別忘了補 width／height 預留版面，LCP 和 CLS 常常是同一張圖一起修。細節見站內圖片最佳化與 CLS 解決方案。

2. 用 fetchpriority 把關鍵資源拉到前面

當 LCP 是圖片，而且瀏覽器發現它太晚時，方向是：

主視覺圖：加 fetchpriority="high"
CSS 背景圖或 JS 稍後插入的圖片：在 <head> 視情況用 preload 宣告

<!-- CSS 背景 LCP：在 head 主動預載 -->
<link rel="preload" fetchpriority="high" as="image" href="/img/hero.webp" type="image/webp">

<!-- HTML 直接宣告的 LCP 圖 -->
<img
  src="/img/hero.webp"
  fetchpriority="high"
  alt="網站主視覺 Banner"
  width="1200"
  height="630"
/>

preload 解決的是「讓瀏覽器更早發現資源」；fetchpriority 解決的是「在已發現的資源中，提示相對重要性」。兩者可以搭配，但不是每張圖片都要一起上。fetchpriority="high" 請只給真正可能成為 LCP、而且確實需要提早下載的資源；大家都當 VIP，最後就沒有 VIP。

3. Eleventy 靜態站：管道預設 lazy 的陷阱

在本站，HTML Transform 會替沒有明確設定的圖片補上 loading="lazy"。這對文章中段的圖片通常合理，卻不一定適合首屏 LCP 圖。遇到這種情況，要在那張圖片上明確覆寫：

<img
  src="/img/hero.png"
  alt="產品主視覺"
  loading="eager"
  fetchpriority="high"
  sizes="(max-width: 800px) 100vw, 1200px"
/>

不要只看 HTML 屬性，也要在 build 後檢查實際輸出的 HTML，確認 loading、fetchpriority、srcset 與 sizes 都符合預期。接著檢查圖片的實際下載大小、尺寸與格式：手機只需要幾百像素寬，就別把幾千像素的原圖整包寄過去。WebP 或 AVIF 可以是選項，但最後仍要以實際檔案大小、畫質和瀏覽器支援情況驗收。

如果圖片是由 JavaScript 動態插入，瀏覽器會更晚才知道它存在。能直接寫進初始 HTML 就直接寫；真的必須動態產生時，至少確認它不是因為程式執行太晚才錯過下載時機：

const hero = document.querySelector('.hero-image');

hero.src = '/img/hero.webp';
hero.fetchPriority = 'high';

這段程式只是在 HTML 已經有圖片元素的前提下補上來源與提示；它不會讓 JavaScript 變成 preload。若資源本來就能在 <head> 預先宣告，優先考慮 HTML 的 preload。

4. 避免 render-blocking 讓首屏後面卡住

如果非關鍵 JS／CSS 形成很長的依賴鏈，LCP 圖片就算早早下載完成，也可能等不到繪製。快速檢查：

資源類型	建議
非關鍵 JavaScript	依載入需求考慮 `defer` 或 `async`；第三方標籤可在主要內容穩定後再載入
CSS	避免不必要的 `@import` 串接；確認 CSS 沒有讓首屏繪製卡在長依賴鏈上
Web 字體	使用 `font-display: swap`；只有確定是關鍵字體時才考慮 preload

GTM 延遲載入的具體寫法，可參考站內 GTM 延遲載入：用 requestIdleCallback 降低 PSI 的 TBT。

一個快速驗收心法：先 CLS 穩，再談 LCP

LCP 是「什麼時候畫出來」，CLS 是「版面有沒有抖」。兩者不是同一個指標，但同一張圖片可能同時影響兩者：沒有尺寸時會推動版面，有錯誤載入策略時又會晚到。

建議順序：

先確保圖片／嵌入不會讓版面在載入期抖動（CLS 預留）
再回頭把 LCP 圖片的優先級拉到位
最後用 GSC → 體驗 → Core Web Vitals 對欄位資料驗收；報告反映的是一段期間的真實使用者資料，不會改完立刻更新

框架快速對照

框架	圖片管道	LCP 注意事項
Hugo	`resources.Get` + `Resize`／`webp`	主視覺圖模板別加 lazy
Eleventy	`@11ty/eleventy-img`	Transform 預設 lazy，主視覺圖覆寫 eager + fetchpriority
Astro	`astro:assets` 或 `<Image />`	依實際輸出與圖片位置確認 loading 設定，LCP 圖別盲目 lazy

快速驗收清單

每次修改後，按這個順序檢查：

PSI 或 DevTools 是否指出同一個 LCP 元素？
LCP 圖是否在初始 HTML 中可被發現？若是背景圖，是否真的需要 preload？
是否誤用了 loading="lazy"？fetchpriority="high" 是否只用在少數關鍵資源？
build 後的 HTML、Network 瀑布圖與實際圖片大小是否符合預期？
CLS 的尺寸預留是否仍然存在？

結語：LCP 優化是「不要拖關鍵資源」的工程紀律

用 PSI／DevTools 找出真正的 LCP 元素，別憑感覺改
首屏 LCP 圖不要 loading="lazy"；確認需要時再加 fetchpriority="high"
CSS 背景圖等難以被初始 HTML 發現的資源，才考慮 preload
Eleventy 管道若自動補上 lazy，主視覺圖要個別覆寫
圖片下載完成不代表已經繪製；也要排查 CSS、字體與 JavaScript 的依賴鏈

先改一個真正的瓶頸，再重新測量；不要一次把整個 <head> 塞滿 preload，否則瀏覽器也會開始懷疑人生。等資料慢慢累積，再回 GSC 看真實使用者的趨勢。改完記得再來一杯，這次是慶祝主角準時登場的那杯。

參考資料

web.dev：Optimize Largest Contentful Paint — LCP 元素、資源發現、lazy loading、fetch priority 與 preload 的整體優化方法。
web.dev：Optimize resource loading with the Fetch Priority API — 說明 fetchpriority 如何影響資源優先級，以及它和 preload 的搭配方式。
web.dev：Browser-level image lazy loading for the web — 說明 loading="lazy" 與 loading="eager" 的載入行為和適用情境。
MDN：<img> HTML image element — 查閱圖片元素的 loading、fetchpriority、尺寸與響應式圖片屬性。
MDN：fetchpriority HTML attribute — 查閱 fetchpriority 的用途、限制與應該節制使用的原因。

GTM 延遲載入：用 requestIdleCallback 降低 PSI 的 TBT

2026-08-03T06:00:00Z

GTM 一掛上去，PageSpeed Insights（PSI）分數就往下掉？先別急著把它整個拔掉。很多時候，問題不是「有沒有 GTM」，而是它在首屏最忙的時候也跑進來搶頻寬、搶主執行緒——大家都還沒坐好，它已經開始開會了。

這篇會帶你把 GTM 從「頁面一開就啟動」改成「使用者互動或瀏覽器有空時才啟動」，再用同一套流程檢查 LCP、TBT、INP，以及轉換事件有沒有被延遲到漏掉。讀完你會知道這種延遲適合什麼情境、程式碼怎麼寫，以及為什麼「分數變綠」不等於資料一定完整。簡單說，就是先讓瀏覽器把早餐吃完，再請 GTM 進來開會。

為什麼 GTM 可能拖慢 PSI？

GTM 常見的影響大致分兩條線：

網路頻寬競爭：gtm.js 下載時，可能和 hero 圖片、CSS 等首屏資源競爭，讓 LCP 延後。實際影響仍取決於網路、資源優先順序與容器內容，不能只看檔名就宣稱一定變慢。
主執行緒工作增加：容器啟動後，GA4、Pixel、Hotjar 等標籤可能執行 JavaScript。標籤太多或太重，就可能製造長任務，推高 TBT，也讓互動回饋變慢。

延遲載入可以保護首屏，但它不是免費午餐：越晚啟動，越可能漏掉頁面剛開啟時的分析或轉換事件。因此要一起看效能和資料完整度。

核心做法：互動觸發加 idle fallback

可以讓以下兩條路都呼叫同一個 boot()：

使用者真的開始使用頁面，例如滾動、按鍵或觸控。
使用者沒有互動時，等主執行緒進入 idle；如果瀏覽器不支援，就退回 setTimeout。

重點是用 started flag 去重。once: true 只會移除某一個事件的 listener，不能取消已排程的 idle callback，也不能保證兩條路不會同時進入函式。所以要在 boot() 裡設防，並在互動搶先發生時取消排程。

可直接複製的最小版本

把 GTM-XXXXXXX 換成自己的 container ID。這段程式會先建立 dataLayer，再在互動或 idle 時只載入一次 GTM。它是「延遲載入的起點」，不是可以直接取代所有 consent、轉換與 noscript 設計的萬用片段。

(function (w, d) {
  var started = false;
  var idleId = null;
  var timeoutId = null;
  var events = ['pointerdown', 'keydown', 'touchstart', 'scroll'];

  w.dataLayer = w.dataLayer || [];

  function boot() {
    if (started) return;
    started = true;

    if (idleId !== null && w.cancelIdleCallback) {
      w.cancelIdleCallback(idleId);
    }
    if (timeoutId !== null) {
      w.clearTimeout(timeoutId);
    }

    w.dataLayer.push({ 'gtm.start': Date.now(), event: 'gtm.js' });

    var script = d.createElement('script');
    script.async = true;
    script.src = 'https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX';
    d.head.appendChild(script);
  }

  events.forEach(function (type) {
    d.addEventListener(type, boot, { once: true, passive: true });
  });

  if ('requestIdleCallback' in w) {
    idleId = w.requestIdleCallback(boot, { timeout: 2000 });
  } else {
    timeoutId = w.setTimeout(boot, 2000);
  }
})(window, document);

requestIdleCallback 的 timeout 不是精準鬧鐘，也不是「GTM 完成載入」的期限。瀏覽器會先等 idle period；若期限到了還沒執行，才把 callback 排進 event loop。callback 開始執行後，還要下載、解析並執行 GTM 與容器裡的 tag。

另外，requestIdleCallback() 目前不是所有瀏覽器都一致支援，所以用 feature detection 比寫死「某某瀏覽器不支援」安全。上面的 fallback 只處理 API 不存在的情況；若網站還有 CSP、consent mode 或特殊 WebView 限制，仍要在目標環境測試。

timeout 要設多少？

真正要平衡的是「首屏保護」和「資料多早開始收集」。下面的數字只是第一輪 A/B 實驗的起點，不是 Google 或 GTM 規定的標準；沒有一個數字適合所有網站，先用實測建立基準比較可靠。

timeout	優點	風險	適合情境
1500–2500ms	適合先做第一輪實驗	早期 pageview 或轉換可能延後	一般內容站、非關鍵分析
1000ms 以下	較早啟動，資料風險較小	首屏和 TBT 的保護變弱	頁面很輕、轉換追蹤較重要
3000ms 以上	首屏保護較久	秒退與早期轉換漏算更多	只有實測支持時才用

如果登入、註冊或購買事件不能漏，不要把所有 tag 都綁在延遲初始化上。可以保留關鍵事件的即時路徑，只延後非必要的分析和行銷 tag。若有同意管理平台，也要依使用者同意狀態決定哪些 tag 能啟動；效能優化不能偷偷繞過隱私規則。

dataLayer 會保留事件，但不是資料保險箱

GTM 載入前先建立陣列，並把資料與 event 放在同一個 object：

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'signup_complete',
  plan: 'free'
});

這能保留「目前頁面、GTM 載入前已成功 push」的事件，GTM 載入後會依序處理 queue。但要記得三個界線：

dataLayer 不會自動跨頁保存；下一頁要重新初始化和 push。
queue 被處理，不代表 tag 的網路請求已經送達。
使用者秒退或立即導向時，下載、執行或 beacon 仍可能被中斷。

因此，GTM Preview 或 Tag Assistant 顯示「有 push」只是第一關，還要到分析或廣告平台的測試工具確認事件真的送出。

延遲前先做的兩件事

先精簡 GTM container

每隔一段時間檢查 container：

刪掉過期活動和不再使用的第三方 tag。
把不需要每頁執行的 tag 改成 Window Loaded 或自訂事件。
減少會反覆掃描 DOM 的變數和觸發條件。

如果只是把一堆不必要的 tag 延後，主執行緒只是晚點忙，並沒有真正變輕。

高階方案再考慮 Worker

Partytown 等方案可以把部分第三方腳本移到 Web Worker，但需要額外整合，且依賴 DOM 或同步行為的 tag 可能不相容。它比較適合已經完成 tag 審計、仍有明確長任務問題的技術型網站，不是第一個該按的按鈕。先把不用的 tag 刪掉，通常比替整個倉庫搬家更划算。

怎麼驗收：不要只看一次 PSI 分數

用下面流程比較立即載入版和延遲版：

固定同一個 URL、GTM container、裝置策略和 cookie／consent 狀態。
PSI 兩個版本都跑多次，記錄 LCP、TBT、CLS、FCP，不要用單次分數宣稱因果。PSI 的 lab 結果會受測試條件影響，分數不是精密秤。
Lighthouse Navigation mode 看首屏；Timespan mode 則用來觀察互動後載入 GTM 的影響。
在 Performance trace 和 Network 面板確認 gtm.js、tag 長任務與請求發生時間。
用 GTM Preview／Tag Assistant 檢查 queue、Custom Event trigger、consent 和轉換 tag。
以真實流量的 CrUX 或 PSI field data 觀察 INP。TBT 是 lab 指標，可作為載入期間主執行緒壅塞的線索，但不能直接當成真實 INP。

如果首屏改善了，但註冊或購買事件明顯少掉，這不是成功的優化；它只是把問題從 PSI 搬到分析資料裡。

需求	工具／做法	適合誰
首屏與 lab 指標比較	PageSpeed Insights、Chrome Lighthouse	想確認 LCP、TBT 是否改善的站長
真實互動體驗	CrUX／PSI field data	有足夠流量、要看 INP 的網站
Tag 行為驗證	GTM Preview、Tag Assistant	不能接受事件悄悄漏掉的網站
整理效能與 SEO 驗收	SEO 與 Core Web Vitals 檢查流程	想把單次修正變成固定流程的站長

結語：先讓主執行緒喘口氣

GTM 不一定要刪，先把它改成互動觸發加 idle fallback。
timeout 越小，資料越早開始；越大，首屏保護越強，但早期事件風險也越高。
dataLayer 能排隊目前頁面的事件，不能保證跨頁保存或請求送達。

下一步：先用 2000ms 做基準，將立即載入版與延遲版各跑多次，同時核對轉換事件，再依 LCP、TBT、INP 和資料完整度調整。修完再喝一口咖啡，這次讓瀏覽器先喝；它如果還是忙，就代表該審的是 tag，不是咖啡師。

參考資料

Google Tag Manager：The data layer：說明 dataLayer 的建立位置、push() 與容器程式碼的關係。
MDN：Window.requestIdleCallback()：說明 idle callback、timeout 與瀏覽器支援限制。
web.dev：Total Blocking Time（TBT）：說明 TBT 的計算方式，以及它和 INP 的差異。
web.dev：Interaction to Next Paint（INP）：說明 INP 應以實地資料觀察，及 lab 指標的限制。
Chrome for Developers：Lighthouse：說明 Navigation、Timespan 與 Snapshot 模式的使用情境。

圖片最佳化與 CLS 解決方案：用 width、height 預防網頁版面跳動

2026-08-03T03:15:00Z

你有沒有遇過這種情況：正準備點連結，圖片突然載入，整段文字往下一跳。手指點到旁邊的空白，只能默念：「很好，咖啡也跟著位移了。」

這不是單純的「圖片太大」問題。圖片還沒載入時，如果瀏覽器不知道它要佔多少空間，後面的內容就可能被推開，形成 CLS（Cumulative Layout Shift，累積版面配置位移）。另一方面，圖片若大到離譜，又會拖慢下載與解碼，影響 LCP。

這篇會用白話整理三件事：如何替圖片預留空間、如何讓下載尺寸符合實際顯示寬度，以及 Eleventy Image Transform 該怎麼接上工作流程。讀完後，你應該能判斷什麼時候寫 width／height，什麼時候使用 aspect-ratio，也能避開幾個很常見的圖片效能坑。

CLS 到底在量什麼？

CLS 衡量的是頁面生命週期中，非預期的版面位移。例如文章文字先排好，圖片載入後才把文字往下推；這種跳動會讓讀者誤點按鈕，也會讓人覺得網站在偷偷喝醉。

Google 的 Core Web Vitals 建議值是：CLS 不高於 0.1、LCP 不超過 2.5 秒，都是以實際使用者資料的第 75 百分位作為判斷基準。這不代表每一台裝置都會得到同樣結果，所以本機 Lighthouse 分數很漂亮，也不等於真實訪客完全沒有問題。

先把範圍切清楚：本文專注圖片造成的位移。字型交換、廣告、Cookie 橫幅與第三方嵌入，也可能造成 CLS，但應該分開檢查，否則修到最後會像在咖啡渣裡找 bug。

第一招：在 HTML 寫上真實寬高

對一般 <img>，最穩妥的做法是提供圖片檔案的實際像素尺寸：

<img
	src="/img/product-dashboard.webp"
	width="1200"
	height="675"
	alt="產品控制台介面截圖"
	loading="lazy"
	decoding="async"
>

這裡的 width 與 height 是圖片的內在尺寸，不是你希望它在畫面上永遠顯示的 CSS 寬度。瀏覽器可以先用這兩個數值算出比例，在圖片下載完成前預留大致正確的高度。

接著用 CSS 讓它能縮小，但不要被拉伸：

img {
	max-width: 100%;
	height: auto;
}

max-width: 100% 只限制圖片不要超出容器；height: auto 則依照原本比例計算高度。這兩行解決的是響應式顯示，HTML 寬高屬性解決的是載入前的尺寸提示，兩者是隊友，不是二選一。

寬高比例填錯，仍然會跳

如果圖片實際是 1600 × 900，卻寫成 1600 × 1200，瀏覽器會先預留錯誤的高度，圖片載入後再校正。這仍可能產生位移，因此請從原檔或產圖工具確認比例，不要靠目測——螢幕上的圖片很會偽裝。

Lazy loading 圖片也一樣需要寬高。它本來就可能等到接近視窗才下載；若此時才突然取得高度，讀者正在看的內容就會被推走。

第二招：需要固定框架時使用 `aspect-ratio`

aspect-ratio 適合用在圖片比例不固定、但設計需要統一視覺框的情境，也很適合 iframe、影片或其他沒有圖片內在比例的嵌入內容。

<figure class="screenshot">
	<img
		src="/img/compare-a.webp"
		width="1600"
		height="900"
		alt="方案 A 設定畫面"
		loading="lazy"
		decoding="async"
	>
</figure>

.screenshot {
	aspect-ratio: 16 / 9;
	width: 100%;
	overflow: hidden;
	background: #f2f2f2;
}

.screenshot img {
	width: 100%;
	height: 100%;
	object-fit: cover;
}

object-fit: cover 會讓圖片填滿框架，必要時裁掉邊緣。如果內容不能被裁切，就改用 contain，或保留 height: auto 讓圖片完整顯示。

一般內容圖片仍建議保留正確的 HTML 寬高；aspect-ratio 是補充工具，不是把每張圖的實際比例都忘掉的通行證。

第三招：圖片尺寸要配合顯示寬度

一張在手機上只顯示 360px 寬的圖片，如果每次都下載 4000px 原圖，瀏覽器不只要多下載，也要多解碼。做法不是無限降低品質，而是先產生符合版面需求的尺寸，再用 srcset 和 sizes 讓瀏覽器選擇候選檔案。

<img
	src="/img/guide-800.webp"
	srcset="
		/img/guide-400.webp 400w,
		/img/guide-800.webp 800w,
		/img/guide-1200.webp 1200w
	"
	sizes="(max-width: 768px) 100vw, 720px"
	width="1200"
	height="675"
	alt="設定步驟示意"
	loading="lazy"
	decoding="async"
>

srcset 列出可用的圖片候選；sizes 描述圖片在目前版面大約會顯示多寬。瀏覽器會綜合視窗寬度與裝置像素比例，選出合適的檔案。sizes 寫成 100vw 但圖片其實只佔內容欄，可能就會下載過大的檔案。

首屏真正的主圖不要一律設定 loading="lazy"。它若是 LCP 候選，應讓瀏覽器正常優先取得；是否加上 fetchpriority="high"，則要看實際載入瀑布流與頁面結構，別把「高優先」當成圖片界的萬用咖啡因。

格式與壓縮怎麼選？

沒有一個適用所有圖片的固定 KB 門檻。照片、介面截圖、透明 Logo 的可接受品質不同，應該在實際裝置與網路條件下比較畫質、檔案大小和 LCP。

可以遵循這個順序：

先裁掉不需要的畫面，並縮到合理的輸出寬度。
依瀏覽器支援與網站流程選擇 AVIF、WebP 或原格式作為 fallback。
UI 截圖放大檢查文字；壓縮不是越狠越專業。
用 PageSpeed Insights 或瀏覽器 Performance 面板確認實際結果。

像 Squoosh 這類工具適合手動比較不同格式與品質，但工具只負責產檔，width 和 height 仍要回到 HTML 補好。

Eleventy Image Transform：把重複工作交給建置流程

圖片不多時，手動處理沒有問題；部落格持續更新後，漏掉寬高或忘記產縮圖就很容易發生。Eleventy 官方的 @11ty/eleventy-img Image HTML Transform 可以在建置時產生多種尺寸與格式，並輸出含有寬高和 srcset 的標記。

概念設定如下：

import { eleventyImageTransformPlugin } from '@11ty/eleventy-img';

export default function (eleventyConfig) {
	eleventyConfig.addPlugin(eleventyImageTransformPlugin, {
		formats: ['webp', 'auto'],
		widths: [400, 800, 1200],
	});
}

實際使用多個寬度時，請為輸出的 <img> 提供符合版面的 sizes。沒有 sizes，瀏覽器可能無法正確判斷候選圖片適合的顯示寬度，最佳化就只完成一半。

Eleventy 也可能替圖片加上 loading="lazy"。這對文章下方的圖片通常合理，但首屏主圖要個別覆寫，並在建置後檢查產出的 HTML，而不是只相信設定檔看起來很漂亮。

建議導入順序很簡單：先讓所有圖片有正確比例，再讓建置流程產生合適尺寸，最後用真實頁面檢查 CLS 與 LCP。先把地板畫好，再搬沙發；不然每次圖片載入，都像重新裝潢一次。

一次完成的檢查清單

改完圖片後，可以照這個順序驗收：

搜尋所有 <img>，確認有 alt，並檢查 width／height 是否符合原圖比例。
確認響應式 CSS 沒有用兩個固定尺寸把圖片拉伸；一般圖片通常搭配 max-width: 100% 與 height: auto。
圖片若需要統一框架，確認容器的 aspect-ratio 和 object-fit 符合內容需求。
檢查 srcset 的候選寬度與 sizes 是否符合實際版面。
確認首屏主圖沒有被不必要的 lazy loading 延後。
用 PageSpeed Insights、Chrome DevTools Performance 或 Search Console 的 Core Web Vitals 資料觀察結果。

CLS 修好不代表整站就會飛起來；伺服器回應、字型、JavaScript 和第三方服務仍可能影響體驗。不過圖片先把尺寸說清楚，至少不會一邊載入、一邊把讀者的手指送去錯的按鈕。

結語：先預留，再瘦身

圖片最佳化可以記成兩句話：先用 HTML 寬高或 CSS 比例預留空間，再讓檔案尺寸符合實際顯示寬度。 前者守住 CLS，後者幫助下載與解碼；兩邊一起做，才不是只把問題從「會跳」換成「等很久」。

先挑一篇文章，補齊圖片寬高並檢查產出的 srcset。做完再跑一次效能檢查，然後放心喝咖啡——這次咖啡杯的位置，應該不會因為圖片載入而改變。

參考資料

web.dev：Optimize Cumulative Layout Shift：說明圖片尺寸、aspect-ratio 與預留版面空間如何降低 CLS。
web.dev：Web Vitals：Core Web Vitals 與 CLS、LCP 建議值及評估方式。
MDN：<img> HTML image element：查閱 width、height、loading、srcset 與 sizes 的行為。
MDN：Using responsive images in HTML：說明解析度切換、srcset 和 sizes 的使用方式。
Eleventy：Image：官方 Image Transform 設定、輸出格式、尺寸與 sizes 注意事項。

Proton VPN 值得買嗎？免費版與付費版功能完整解析

2026-08-02T13:25:00Z

你是不是也曾經在 App Store 搜尋「免費 VPN」，下載一個評分不錯的 App，結果隔沒多久就看到新聞說某款免費 VPN 洩露使用者資料？免費不一定有問題，但「免費」兩個字也不會自動替 App 做資安審查。這就像免費咖啡：先問清楚誰付了豆子的錢，心裡比較踏實。

Proton VPN 是少數提供免費方案、而且把隱私保護當成產品核心的 VPN 服務。這篇文章會用實際使用情境比較 Free 與 VPN Plus：你會知道免費版能做什麼、付費版到底多了哪些功能，以及價格為什麼不適合用一個固定數字概括。讀完後，你應該能依自己的需求做選擇，而不是被「買最貴才最安全」的焦慮推著走。

先說明我的使用背景：我自己使用 Proton VPN、Proton Drive 和 Proton Mail 已經超過兩年。選擇它們不是為了切換國家觀看 Netflix，也不是為了玩遊戲或追求特殊用途，主要是想在日常上網時多加一層保護。到國外住飯店、使用公共 Wi-Fi 時，我通常會先開啟 VPN；但 VPN 不是防毒軟體，也不是「開了就無敵」的護身符，這點要先講在前面。

Proton Mail 的別名功能可以減少公開主要電子郵件地址，Proton Pass 也能作為密碼管理工具。不過本文主角是 Proton VPN，其他 Proton 服務只會在討論 Proton Unlimited 時順帶提到，免得一篇 VPN 評測突然變成全家福產品目錄。

為什麼大多數「免費 VPN」很危險？

在討論 Proton VPN 之前，先理解免費 VPN 的商業模式會比較容易判斷風險。不是每一個免費 VPN 都會把使用者當商品，但服務總要有收入來源；如果業者沒有清楚說明資料如何處理，就值得提高警覺。

常見的免費 VPN 營利手法包括：

以廣告或資料分析支撐服務，卻沒有清楚交代收集哪些資料
記錄 DNS 查詢、連線時間或其他使用 metadata，並用於分析或行銷
出租使用者的頻寬，讓其他流量從你的 IP 位址通過
使用過度的權限或不透明的第三方元件

因此，選 VPN 時不能只看「免費」或下載量。隱私政策、公司背景、App 是否公開原始碼、是否有獨立審計，才是比較有用的檢查項目。否則你以為自己買了保護傘，結果傘面寫著「使用者行為分析中」。

Proton VPN 免費版：市場上的異類

Proton VPN Free 的定位，是讓使用者不用付費也能取得基本 VPN 保護。依 Proton 官方方案說明，免費方案提供：

✅ 不限資料量
✅ 無廣告，且官方承諾不記錄活動紀錄、不出售個人資料
✅ Kill Switch 與基本的 VPN 防洩漏保護
✅ 官方 App 原始碼公開，並接受獨立安全審計

這些條件讓它成為值得考慮的免費入門方案，但「免費」仍然有產品限制。

免費版的三個主要限制

可用地點有限：免費伺服器的可用國家與分配方式，應以官方方案頁面和 App 當下顯示為準。如果你需要指定國家，免費版可能不符合需求。
同時只能連線一台裝置：家中電腦、手機和平板不能全部一起掛著。這不是 VPN 在鬧脾氣，而是方案限制。
官方速度等級較低：Proton 將 Free 標示為 Medium VPN speed；實際速度仍會受距離、伺服器負載、裝置和原本網路品質影響。

免費版 vs 付費版速度差異

Proton 官方沒有保證 Free 與 Plus 固定的下載、上傳或延遲數字，所以不要把某一次測速結果當成所有人的成績單。官方將 Free 標示為 Medium VPN speed，Plus 則標示為 Highest VPN speed；兩者都沒有資料量上限。

評測指標	免費方案 (Free)	Plus 付費方案
官方速度描述	Medium VPN speed	Highest VPN speed
資料量	無限	無限
實際表現	受可用地點、距離、伺服器負載與網路環境影響	可使用較多地點與 Plus 伺服器，實際表現仍因環境而異

💡 免費版提速小提醒：若網頁載入緩慢，可以在 App 中嘗試其他支援的 VPN 協定或 Smart Protocol。協定不是速度保證，距離和伺服器負載通常也很有存在感。

Proton 官方方案頁面目前以「20,000 多台伺服器、140 多個國家」以及最高 10 Gbps 的伺服器能力介紹 Plus。官方也表示 VPN Accelerator 在某些情況下最多可提升約 400% 的速度；這是特定條件下的最高宣稱，不是每次連線都會得到的保證。

免費版 vs 付費版（Plus）：完整功能對比

功能	免費版	Plus 付費版
流量限制	無限 ✅	無限 ✅
可用伺服器國家	依官方頁面與 App 當下顯示，地點有限且可能隨機分配	140+ 個（以官方當下資料為準）
伺服器數量	免費節點	20,000+ 個（以官方當下資料為準）
官方速度描述	Medium VPN speed	Highest VPN speed，最高可達 10 Gbps
同時連線裝置數	1 台	10 台
支援的串流服務	不保證支援	付費方案支援部分串流服務
P2P / BT 下載	不支援	✅
Secure Core（雙重跳板）	❌	✅
NetShield（廣告與惡意軟體攔截）	❌	✅
Stealth 混淆協定	✅	✅

關鍵升級理由：如果你需要指定更多國家、部分串流服務、P2P、NetShield 或 Secure Core，Plus 才有升級的實際理由。Stealth 則不是 Plus 專屬功能，Proton 官方也將它列為 Free 可用的反審查功能。至於串流服務能否連線，仍可能受到服務商封鎖策略、伺服器和所在地區影響，不該寫成「永遠解鎖」。

讓 Proton VPN 與眾不同的四大技術特色

1. Secure Core：雙重跳板防禦

一般 VPN 的流量路徑是：你的裝置 → VPN 伺服器 → 目標網站。

如果出口伺服器遭到監控，理論上可能透過流量關聯分析輸入與輸出，增加追蹤來源的機會。

Proton VPN 的 Secure Core 會讓流量先經過 Proton 自有、位於高安全性資料中心的伺服器，再轉接到目標國家的出口伺服器。官方表示 Secure Core 伺服器位於瑞士、冰島與瑞典，並使用自有硬體配置。它能增加追蹤來源的難度，但不代表絕對匿名，也不能消除所有端點或使用習慣造成的風險。

2. Stealth 協定：突破深度封包檢測

標準的 OpenVPN 和 WireGuard 流量可能有可被識別的特徵，某些網路環境會針對這些特徵進行阻斷。

Proton 的 Stealth 協定會：

將 VPN 流量包裝在混淆的 TLS over TCP 通道中。
讓流量更像一般 HTTPS，增加深度封包檢測系統辨識與封鎖的難度。

這對身處高審查網路環境的人可能有幫助，但 Proton 也提醒，封鎖措施會持續變化，沒有任何 VPN 能保證在特定國家或網路永遠連線成功。網路封鎖不是固定考卷，今天能連不代表明天也會給你及格。

3. NetShield：DNS 層廣告與惡意軟體防護

NetShield 是基於 DNS 的網路層過濾器。啟用後，DNS 請求會在 Proton 伺服器端與已知的廣告、追蹤器和惡意網域清單比對，在資源載入前封鎖符合條件的請求。

實際效益：

加速網頁載入（跳過廣告載入時間）
節省行動數據流量
降低連到已知惡意網域的風險

這能減少部分廣告、追蹤器和已知惡意網域帶來的干擾，也可能省下一些載入時間與行動數據。不過 NetShield 不是萬能防毒軟體，不能保證攔截所有木馬或病毒；遇到陌生網站和自動下載的檔案，還是要保持警覺。

4. 瑞士法律管轄權：法律層面的最強隱私盾牌

Proton VPN 受瑞士法律管轄，這是評估服務時可以納入的因素，但不能直接等同於「絕對隱私」。

Proton 官方表示，在目前的瑞士法律框架下，Proton VPN 沒有強制保存 VPN connection logs 的義務；如果服務本身沒有保存相關 VPN 活動紀錄，也就無法提供不存在的資料。實際權利義務仍應以官方隱私政策、透明度報告和適用法律為準。

不過，法律管轄權不是「絕對隱私」的保證。使用者仍應閱讀 Proton 的隱私政策與透明度報告，按照自己的威脅模型選擇服務。

「無日誌」不只是廣告詞——如何驗證 Proton VPN 的誠信？

市面上不少 VPN 都宣稱自己是「無日誌（No-Logs）」，但口號不能單獨當證據。可以從以下三個方向檢查：

驗證指標 1：第三方獨立安全審計

Proton 會委託獨立資安機構審查 App 或 no-logs 架構，並公開相關報告。Proton 官方的 no-logs 審計文章提到由 Securitum 執行，內容涵蓋 VPN 伺服器是否記錄瀏覽活動、DNS 查詢、連線 metadata 和流量內容。閱讀時仍要注意報告的範圍與日期，因為一次審計不是永久通行證。

驗證指標 2：真實法庭案例的考驗（最強鐵證）

再嚴謹的審計，也可以搭配透明度報告和實際法律案件一起看：

Proton 官方 no-logs 說明指出，2019 年曾收到要求提供特定使用者 VPN connection logs 的法律命令，但因為相關紀錄不存在，Proton 無法提供。官方也表示，這項 no-logs 政策在多個法律案件中受到檢驗。這些是 Proton 的官方說法，讀者仍可搭配透明度報告自行判讀。

驗證指標 3：開源程式碼（任何人都可以審計）

Proton 官方表示，Proton VPN App 的程式碼公開，並接受獨立安全審計。開源讓研究人員可以檢查 App 的實作方式，但 App 開源本身不等於能單獨證明所有伺服器端行為；這也是為什麼審計、法律和透明度資料要一起看。

Proton 不只是 VPN：完整隱私生態系

如果你開始關注數位隱私，Proton VPN 只是其中一項工具。Proton 也提供其他隱私導向服務：

Proton 產品	替代方案	核心優勢
Proton Mail	Gmail	提供加密與別名功能；不同郵件情境的加密方式與 metadata 保護程度有所不同
Proton Drive	Google Drive	以端對端加密和零知識設計保護檔案
Proton Pass	瀏覽器密碼管理器	加密金庫，並整合 2FA 與別名功能
Proton Calendar	Google Calendar	以端對端加密設計保護行事曆資料

Proton Unlimited 可一次取得多項 Proton 服務的付費功能。官方方案頁面目前列出 Proton Mail 與 Proton Drive 共用的 500 GB 儲存空間；Calendar 也包含在方案服務中，但不代表共用這項儲存空間。是否划算，要看你是否真的會使用這些服務，不是看到「全家桶」就要把整個廚房搬回家。

💰 Proton 方案價格怎麼看

Proton 的價格會因計費週期、貨幣、地區、促銷活動與續訂條件變動。本文不硬塞一個台幣換算或促銷價，避免你看到文章時，價格已經像咖啡店的季節限定一樣下架。實際金額請以 Proton 官方價格頁面和結帳頁為準；台灣信用卡的匯率與海外刷卡手續費，也可能影響最後支出。

我推薦誰應該選擇哪個方案？

✅ 選免費版，如果你：

只是偶爾需要 VPN 保護公共 Wi-Fi 安全
不需要解鎖串流平台或 P2P 下載
想先試用後再決定是否付費

✅ 選 Plus 付費版，如果你：

需要官方列出的部分串流服務支援，例如 Netflix、Disney+、Prime Video 等
需要 P2P / BT 下載高速伺服器
需要更多國家與伺服器選擇
需要多裝置同時連線（最多 10 台）
需要 Secure Core、NetShield 等進階功能

✅ 考慮 Proton Unlimited，如果你：

想從 Google / Microsoft 生態系遷移到隱私導向的替代服務
會同時使用郵件、雲端、密碼管理和行事曆
需要一個涵蓋郵件、雲端、密碼管理的一站式隱私解決方案

結論：免費版值得用嗎？

我的結論是：Proton VPN Free 值得當作免費入門方案，但不一定適合所有人。 它的優點是不限資料量、功能透明，且不必一開始就付款；如果你只是偶爾保護公共 Wi-Fi，通常已經足夠。

如果你需要指定更多地點、部分串流服務、P2P、NetShield、Secure Core 或多台裝置同時連線，VPN Plus 才有明確的升級理由。若你還會使用 Proton Mail、Drive、Pass 和 Calendar，再比較 Proton Unlimited；價格請以官方當下頁面為準。

最後提醒：VPN 能降低部分網路風險，卻不能替你辨識釣魚網站、修補裝置漏洞，或讓你在網路上自動隱形。選好方案後，更新系統、使用多因素驗證和管理密碼，這些基本功仍然不能外包給 VPN。隱私保護像泡咖啡，磨豆、沖煮、清潔都要做，不能只買一個漂亮濾杯。

聯盟揭露： 本文包含 Proton VPN 推薦連結。如果你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。本文仍應依實際功能、限制與使用需求做選擇。

👉 免費申請 Proton 帳號 →

參考資料

Proton VPN 免費方案 — 查閱 Free 方案的功能、限制與申請方式。
Proton VPN 方案說明 — 比較 Free、VPN Plus 與 Proton Unlimited 的功能。
Proton VPN 價格頁面 — 查閱依地區、計費週期與當期活動顯示的實際價格。
Proton VPN Secure Core — 了解 Secure Core 的流量路徑與伺服器配置。
Proton VPN NetShield — 了解 DNS 層廣告、追蹤器與惡意網域過濾。
Proton VPN no-logs 審計報告 — 查閱 Securitum 審計及 Proton 對 no-logs 政策的說明。
Proton VPN Transparency Report — 查閱 Proton 公開的法律要求與資料提供紀錄。

AI 時代還需要學習 CSS 嗎？從「語法背誦」到「架構審查」的思維轉向

2026-07-31T03:17:00Z

沒有一杯咖啡解決不了的 CSS；如果有，就交給 AI——然後你可能會發現，它把整頁都寫成 position: absolute。版面跑到懷疑人生，只好再沖一杯。

你是不是也遇過這種情境：打開 Cursor 或 Claude，輸入「幫我做一個響應式產品頁」，幾秒後就得到一大串看起來很漂亮的 CSS。你心想：「太好了，以後不用學了！」結果換個螢幕寬度，版面像被貓踩過一樣。

結論先講：CSS 還是要學，但學習重點已經改變。 你不必把每個屬性和值背成咖啡店菜單；你需要建立版面與效能的心智模型，能看懂 AI 的決策、驗證結果，並在必要時把它拉回正軌。這篇會帶你整理這套學法，還會示範怎麼寫出比較可靠的 CSS Prompt。

你不只要寫 CSS，也要審 CSS

以前學 CSS，很大一部分時間花在記屬性與語法。現在查文件很方便，像 align-content 的值或 flex-shrink 的預設行為，都可以在需要時查清楚。這不代表基礎不重要，而是學習時間應該從「背答案」移到「理解問題」。

真正重要的是，你能不能看出 AI 寫的版面為什麼不穩，並用清楚的條件請它修正。否則就會陷入經典循環：和 AI 來回對話十輪，Bug 還在，咖啡倒是喝了三杯。這不是咖啡因不足，是驗收條件不足。

AI 是乘數：底子越厚，幫助越大

把 AI 想成乘數會比較貼近實際：它可以加快產生草稿、改寫重複程式碼，但不會替你承擔需求不清、驗收錯誤或維護困難的後果。

概念不清 × AI：很快得到一個能展示的版本，但遇到不同內容、不同寬度或下一次修改，就不知道該從哪裡修。
概念清楚 × AI：你可以把重複工作交給 AI，再用版面、可及性、效能與可維護性的原則檢查成果。

白話說，AI 會放大你的能力，也會放大你的盲點。底子不夠，它幫你「快」；底子夠，它才比較有機會幫你「又快又穩」。

AI 越強，你越需要 CSS 心智模型

AI 能產生程式碼，但它不會替你確認需求，也不會自動知道這個元件在真實內容與各種螢幕下是否合理。因此，它可能交出看起來對、實際很脆弱的解法——像自動咖啡機做出一杯外表像拿鐵、喝起來像苦水的飲料。

常見警訊包括：

亂用 position: absolute：為了對齊就硬拉座標，內容一變或視窗變窄，版面便可能重疊。絕對定位不是禁忌，但應該用在確實需要脫離正常流的情境。
無止境堆 @media 斷點：若每個元件都只依賴視窗寬度，元件放到不同容器時就難以重用。Container Queries 可以在適合的情況下，讓樣式依祖先容器的尺寸調整；前提是先正確設定查詢容器。
把 z-index 加到 9999 還是沒用：z-index 受層疊上下文影響，數字大不等於一定顯示在最上層。這時候再來一杯咖啡也沒用，得先找出是哪個元素建立了新的層疊上下文。

這幾件事，AI 真的替不了你

概念	AI 常犯的錯	你要會的
正常流（Normal Flow）	版面一亂就加定位硬撐	知道元素預設如何排列，再判斷是否真的要脫離正常流
佈局選型	不分情境套用 Grid 或 Flex	Flexbox 適合一維排列，Grid 適合同時處理列與欄；實際選擇仍要看內容
Intrinsic Sizing	直接把 `width`、`height` 寫死	理解內容如何影響尺寸，再用 `min()`、`max()` 或 `clamp()` 等方式設計彈性
設計系統（Tokens）	到處硬編碼顏色與間距	使用像 `--color-primary` 這類變數，讓修改有一致的入口

CSS 會影響體驗，也可能牽動搜尋表現

CSS 不只影響外觀，也會參與版面配置與瀏覽器渲染。Core Web Vitals（CWV）是用來觀察載入、互動與視覺穩定性的使用者體驗指標；Google 說明這些指標會在相關工具中呈現，也可能作為搜尋排名系統考量的一部分，但它們不是「CSS 分數」，更不是分數一掉就必然失去流量。真正的目標，是讓使用者感覺網站穩定、快速、好操作。

AI 產出的 CSS 可以從這些角度檢查：

CLS（累積版面位移）：圖片或嵌入內容若沒有預留空間，載入後可能把既有內容推開。可以確認媒體尺寸、aspect-ratio 或其他空間預留方式是否符合實際版面。
INP（互動至下一次繪製）：它反映使用者互動後，頁面回應並完成下一次繪製的延遲。動畫若頻繁改動會影響版面配置的屬性，可能增加瀏覽器工作量；在適合的情況下，可優先評估 transform 或 opacity，但仍要用實際測量驗證，不能保證換了屬性就一定改善。
LCP（最大內容繪製）：主要內容的載入與呈現也會影響體驗。不要只看 CSS，還要一起檢查圖片、字型、HTML 與 JavaScript 的載入路徑。

想搞懂門檻跟優化清單，可以看這篇：PageSpeed Insights 與 Core Web Vitals 2026 完全指南。

四階段學習路線（邊做邊跟 AI 練，別乾讀）

如果你現在要重新學 CSS，我會建議照這張地圖走。每完成一階段，可以獎勵自己一杯咖啡；只是別邊喝邊讓 AI 無限制自由發揮：

階段 1：先建立心智模型——先用正常流做出可閱讀的 HTML，再觀察什麼時候需要 Flexbox、Grid 或定位。你會逐漸理解「流」不是玄學，而是瀏覽器的預設排版方式。
階段 2：練習 Flexbox 與 Grid 的分工——先問自己是在處理一個方向，還是同時管理列與欄，再選擇工具。可以要求 AI：「請說明為什麼這個區塊適合使用 Flexbox 或 Grid。」
階段 3：練習元件級響應式——學會 Container Queries 的基本條件，理解它和 Media Queries 解決的是不同層級的問題，再請 AI 產生小範例並逐行審查。
階段 4：加入效能與可及性驗收——用 PageSpeed Insights、瀏覽器開發者工具或其他合適工具觀察 LCP、CLS、INP 與可及性問題。content-visibility 可以是進階研究題目，但要先理解它的適用情境與限制，不要把它當成長頁面的萬用咖啡粉。

別只說「幫我做一個卡片」——給它一個好 Prompt

模糊指令 = 模糊產出。就像你走進咖啡店只說「給我一杯好喝的」，店員也只能猜。你可以複製下面這個結構，再依專案改寫：

請為我實作一個響應式文章卡片元件：
1. **佈局**：使用語意化 HTML；圖片在上、標題在下、按鈕靠底對齊。請說明為什麼選 Flexbox 或 Grid。
2. **設計系統**：優先使用專案既有的 CSS 變數；如果沒有，先列出需要的變數，再提供暫時值，禁止散落難以維護的硬編碼色碼。
3. **響應式**：若使用 Container Queries，請補上必要的容器設定，並說明查詢條件；不要只複製視窗斷點。
4. **效能**：只在適合的情況使用 `transform`、`opacity` 等動畫方式，並說明仍需如何測量驗證。
5. **a11y**：確保鍵盤 focus 狀態可見、互動元素有清楚名稱，並檢查文字與背景對比是否符合 WCAG 2.2 的要求。
6. **要求**：請先解釋佈局與響應式策略，再提供 HTML 與 CSS 程式碼，最後列出需要人工驗收的項目。

重點不是 Prompt 越長越好，而是把決策權留給你。先讓 AI 解釋為什麼這樣排、有哪些假設，再決定要不要採用。AI 可以當外骨骼，但方向盤還是你的；不然它很可能一路開向 !important 的荒野。

結語：會寫 CSS 的人變多了，會審 CSS 的人更值錢

「會寫 CSS」這件事本身，不代表價值消失了；只是單純產生一段能跑的樣式，已經不是完整能力。真正有差的是：你能不能交付一個能上線、好維護、在真實情境下穩定的成品。

下次請 AI 寫 CSS 時，先給它清楚的限制，再逐項驗收。沒有一杯咖啡解決不了的 CSS，如果有，就交給 AI——但記得，審完再來一杯。

參考資料

MDN：CSS 版面配置入門：正常流、Flexbox 與 Grid 的基本概念。
MDN：Flexbox 與其他版面方法的關係：Flexbox 一維佈局的特性與選用思路。
MDN：Grid 與其他版面方法的關係：Grid 二維佈局的特性與和 Flexbox 的差異。
MDN：CSS Container Queries：依容器尺寸套用樣式的語法與必要設定。
web.dev：Web Vitals：LCP、INP、CLS 的定義、門檻與測量方式。
W3C：Web Content Accessibility Guidelines (WCAG) 2.2：可及性成功準則，包括鍵盤操作與色彩對比。

光輝咖碼

為什麼要發明 Pi？從作者角度理解 Pi vs Claude Code 該怎麼選

目錄

先講清楚：這不是「Claude Code 不好」

作者為什麼要重新做一個 Coding Agent？

Pi 的四個設計原則（對照 Claude Code 怎麼想）

1. 極簡核心，不是功能競賽

2. 可觀測性優先

3. 用組合取代內建一體化

4. 安全責任放回執行環境

決策表：我該選 Pi 還是 Claude Code？

30 秒口訣

推薦工具／資源

結語：選哲學，再選按鈕

參考資料

我如何用 PageSpeed Insights 優化 11ty 網站：為什麼比 WordPress 更容易直接修

目錄

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

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

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

PageSpeed Insights 指出 LCP 慢：先找真正的最大元素

給 AI 的提示詞範例（LCP）

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

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

給 AI 的提示詞範例（CLS）

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

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

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

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

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

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

提示詞要寫清楚的五件事

AI 交卷後的總審核清單

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

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

參考資料

Pagefind 教學：如何為 Eleventy 靜態網站加入純前端搜尋

Pagefind 教學：如何為 Eleventy 靜態網站加入純前端搜尋

目錄

Pagefind 是什麼？

開始前先確認三件事

第一步：選擇 Pagefind UI 版本

第二步：告訴 Pagefind 要索引什麼

第三步：在 Eleventy build 後建立索引

第四步：把流程接進 package.json

繁體中文搜尋要怎麼驗收？

常見問題排查

搜尋框出現，卻沒有結果

中文結果很少

首頁或分類頁沒有出現在結果裡

搜尋結果一直出現導覽列文字

本機測試看起來壞掉

結語：先解決搜尋，再考慮升級

參考資料

11ty 與 Hostinger 快取怎麼設定？從 .htaccess 到更新驗收

目錄

先記住快取原則

11ty 與 Hostinger 各自負責什麼？

部署前先確認 _site

依專案設定 public/.htaccess

這些設定分別做什麼？

一年快取有一個容易忽略的風險

為什麼 Pagefind 需要單獨設定？

除了快取，.htaccess 還能負責哪些事情？

HSTS 不是檔案快取

部署後到 hPanel 清除快取

用 curl 驗收 response headers

快取設定決策表

常見問題

重新建置後，網站為什麼還是舊頁面？

可以把所有檔案都設定成快取一年嗎？

為什麼 Pagefind 搜尋不到剛發布的文章？

改 .htaccess 後網站出現 500 怎麼辦？

部署驗收工具

結語：先分層，再決定 TTL

參考資料

字型子集化：2026 中文網站如何減少字型載入、改善首屏速度

目錄

先判斷：你真的需要 Web Font 嗎？

三種字型策略怎麼選？

部署前先確認 `_site`

依專案設定 `public/.htaccess`

除了快取，`.htaccess` 還能負責哪些事情？

用 `curl` 驗收 response headers

改 `.htaccess` 後網站出現 500 怎麼辦？

3. 用 `@font-face` 控制載入行為

第二招：需要固定框架時使用 `aspect-ratio`