光輝咖碼

VPN 跟 HTTPS 差在哪？公共 Wi-Fi 上到底要開哪一個？

2026-08-10T06:12:00Z

咖啡店連上 Wi-Fi，網址列出現鎖頭，很多人就以為「這台手機已經安全了」——鎖頭很可愛，但它只管你和某一個網站之間的傳輸，不是整台手機的保護罩。也有人聽說 VPN 很神，開了以為能防釣魚、防病毒；結果在假網站輸入密碼，VPN 還是會很盡責地把資料加密送到那個假網站。唉。

其實 HTTPS 和 VPN 保護的是不同層次：一個管你和「某個網站」之間的內容，一個管你和「整段網路」之間的連線。搞懂差異，你才能判斷：看新聞可能不用 VPN，但登入信箱或網銀時，光靠鎖頭可能不夠。讀完這篇，你應該能用一張表快速決定「現在這件事，HTTPS 夠嗎？要不要加 VPN？」

一句話記住：兩者保護的範圍不同

	HTTPS	VPN
保護對象	你和某一個網站之間的連線	你的裝置到 VPN 伺服器之間的整段流量
主要功能	加密內容、防止竄改、驗證網站身分	把本地網路／ISP 能看到的活動藏起來，換成 VPN 業者成為信任對象
典型比喻	寄信時用密封信封，只有收信人能打開	整條路都走加密隧道，路邊的人較難看你去了哪裡
不能做的事	不能證明網站不是假的；不保護其他 App 流量	不能防釣魚、不能防病毒；目的地若沒 HTTPS 仍可能明文

記這四句就夠（比背 VPN 協定名稱實用多了）：

沒有 HTTPS：別人可能看到或修改你與網站交換的內容。
有 HTTPS、沒有 VPN：內容通常受保護，但本地網路仍可能知道你連到哪些網域。
有 VPN、沒有 HTTPS：裝置到 VPN 這一段受保護，但網站端與 VPN 業者仍是信任問題。
兩者都有：公共網路上較完整的組合，但仍不能取代防詐、更新、強密碼與 MFA。

HTTPS 保護什麼？鎖頭代表什麼？

HTTPS 是 HTTP 加上 TLS 加密。依 Mozilla 等官方說明，它主要做三件事：

加密：傳輸中的資料不容易被旁觀者讀取。
完整性：攻擊者不能在途中悄悄改內容而不被發現。
伺服器驗證：瀏覽器透過憑證確認自己連到的是宣稱的網域。

所以在沒有 HTTPS 的網站上（網址仍是 http://），公共 Wi-Fi 上的其他人可能看到帳號、密碼或表單內容，也可能改頁面。千萬不要在 HTTP 網站輸入信用卡或登入資料——那就像用透明信封寄密碼，鎖頭還沒上場。

但 HTTPS 不是整台裝置的加密罩：

它通常只保護瀏覽器與特定網站之間的連線，不會自動保護其他 App。
網路觀察者通常仍可能知道你連到哪個網域、連線時間與流量大小；不一定能看到具體頁面內容。
有 HTTPS 不代表網站可信。假網站也可能申請有效憑證——鎖頭只代表傳輸加密，不代表這家公司是真的（證書不會幫你審核商業道德）。
若頁面載入未加密的圖片、腳本等混合內容，整體安全性可能被削弱。

現代網站大多已強制 HTTPS，Google 也把它當 SEO 因素；Chrome 會把純 HTTP 標成「不安全」。對站長來說，HTTPS 是建站基本功；對一般使用者來說，重點是：敏感操作前確認網址是 https://，並核對網域拼字——g00gle.com 有鎖頭也沒用。

VPN 補上哪一塊？為什麼 HTTPS 夠了還有人開 VPN？

VPN 會在裝置與 VPN 伺服器之間建立加密通道。對公共 Wi-Fi 業者或 ISP 而言，較難直接看到你通道內的瀏覽目的地；網站看到的來源 IP 也通常會變成 VPN 伺服器的 IP。

VPN 比較適合這些情境：

你不信任目前的網路（旅館、機場、咖啡店 Wi-Fi）。
你不希望本地網路業者直接看到你的瀏覽網域或 DNS 查詢。
你需要連回公司或家中的私有網路。

但 VPN 不是匿名按鈕，也不是防毒軟體：

VPN 業者本身成為新的信任對象，可能看見部分連線資訊；挑選時要查隱私政策、商業模式與獨立稽核。
VPN 不會阻止釣魚網站、惡意下載、Cookie、帳號登入或裝置指紋追蹤。
若目的地網站沒有 HTTPS，VPN 伺服器到網站之間的內容仍可能沒有端對端保護。
連線中斷、設定錯誤或未更新時，保護效果可能不如預期。

EFF 在 2026 年更新的 VPN 指南也提醒：現代網路大多已使用 HTTPS，因此 VPN 不一定是防公共 Wi-Fi 大多數威脅的必要條件；它更主要是在保護網路中繼資料（例如你連了哪些網域），以及把信任從 ISP／本地網路轉移到 VPN 業者——不是讓你完全隱形，只是換一個你要信任的人。

情境決策表：我現在要做的事，要開 VPN 嗎？

把「內容、網域、整台裝置流量」分開想，就不會亂開或亂關 VPN——也不會在查地圖時硬開 VPN 然後抱怨速度變慢。

公共 Wi-Fi 常見情境

情境	沒有 HTTPS 的風險	沒有 VPN 的限制	較實際的做法
咖啡店登入銀行或信箱	他人可能讀取或竄改登入內容	Wi-Fi 業者仍可能看到你連到哪些網域	優先改用手機行動網路；必須用公共 Wi-Fi 時，確認 HTTPS 再加可信任 VPN
在家瀏覽一般 HTTPS 網站	若網站只用 HTTP，內容可能被窺看	ISP 通常仍能看到網域；網站也能用 Cookie 辨識你	不在 HTTP 網站輸入敏感資料；需要隱私時用 VPN，並保持系統更新

我要做什麼 → 怎麼連線（一頁帶走）

我要做什麼	建議連線方式	要 VPN 嗎
看新聞、查地圖	公共 Wi-Fi 或 eSIM	可選
機場查航班	公共 Wi-Fi 或 eSIM	可選
飯店 Wi-Fi 看 YouTube	飯店 Wi-Fi + VPN	建議
登入信箱、社群	Wi-Fi 或 eSIM + VPN	✅ 建議
咖啡廳寄信	Wi-Fi 或 eSIM + VPN	✅ 建議
eSIM 登入銀行 App	旅遊 eSIM + VPN	✅
網銀轉帳	手機 eSIM／個人熱點 + VPN	✅ 必開

只有 HTTPS 夠嗎？快速對照

只做這件事	HTTPS 夠嗎	要 VPN 嗎
看新聞、查地圖	通常夠	可選
登入信箱、社群	建議加 VPN	✅
網銀、購物、公司系統	不建議只靠公共 Wi-Fi	✅ 必開

Q：有 HTTPS 了，還需要 VPN 嗎？

短答：敏感操作（銀行、信箱、公司系統）建議還是要。

HTTPS 保護你和正確網站之間的傳輸加密；但它不能證明你連的是真網站，也不能阻止別人在公共網路上看到你的 DNS 查詢或流量模式。VPN 多一層從裝置到 VPN 伺服器的加密——兩層疊起來，至少不會只靠一把鎖頭硬撐。

常見誤解：別把鎖頭或 VPN 當萬能藥

「有鎖頭就安全」 — 假網站也可能有 HTTPS；要看網域是否正確，必要時用書籤或官方 App。
「開了 VPN 就不會被駭」 — VPN 不防釣魚；你若在仿冒 HTTPS 網站輸入密碼，VPN 仍會把資料加密送到那個假網站（加密很盡責，方向錯了）。
「飯店 Wi-Fi 有密碼就安全」 — 密碼通常只防路過的人；同飯店其他住客或被入侵的路由器仍有風險。敏感操作用 eSIM 或個人熱點更穩。
「VPN 可以取代防毒、MFA、更新」 — 不能。完整防線還需要強密碼、多因素驗證、系統與瀏覽器更新。

三分鐘安全檢查清單

出門連陌生 Wi-Fi 前，照這六步做（比多下載三個「Wi-Fi 加速器」實用）：

先確認網路名稱：向店家或櫃檯確認 SSID，不要只選訊號最強的同名網路。
先看網址：敏感操作前確認是 https://，不要因為有鎖頭就忽略網域拼字。
能不用公共 Wi-Fi 就不用：金融交易、工作機密或重要帳號，優先用手機行動網路或個人熱點。
需要隱藏網路活動時才加 VPN：選可信任、持續更新且有清楚隱私政策的服務。
關閉自動連線與檔案分享：公共網路上關閉自動加入 Wi-Fi、AirDrop／檔案分享等不需要的功能。
補上其他防線：更新系統與瀏覽器、使用獨立強密碼、開啟 MFA，並保留裝置防毒與備份。

工具	適合誰	說明
Proton VPN（主推）	常在公共 Wi-Fi、旅行、需要免費入門的人	免費版已有 Kill Switch、無日誌政策與不限流量；公共網路上是 HTTPS 之外合理的一步。付費版解鎖更多國家、串流與進階功能。
手機行動網路／個人熱點	網銀、轉帳、公司系統	不依賴陌生路由器；敏感操作時往往比「公共 Wi-Fi + 任何工具」更穩。
密碼管理器 + MFA	所有有帳號的人	VPN 與 HTTPS 都不防帳號被盜；強密碼與驗證器 App 是基本配。

結語：先搞懂層次，再決定要不要開 VPN

HTTPS 和 VPN 不是二選一，而是疊加不同層次的保護：

HTTPS 管你和網站之間的內容有沒有被看見、被改掉。
VPN 管本地網路／ISP 能不能輕易知道你去了哪裡。

看地圖、刷新聞，HTTPS 通常就夠；登入信箱、網銀或在飯店 Wi-Fi 上工作，建議 HTTPS + 可信任 VPN，敏感金融操作則優先 行動網路 + VPN。

若你常在咖啡店、機場或旅館上網，又不想一開始就付月費，可以先從 Proton VPN 免費版試起——在家連一次、開好 Kill Switch，下次出門就知道 HTTPS 之外還差哪一塊。沒有一杯咖啡解決不了的網路焦慮；如果有，就加一層 VPN——然後記得，咖啡還是要自己付。

聯盟揭露： 本文包含 Proton VPN 推薦連結。如果你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。

👉 免費申請 Proton VPN 帳號 →

參考資料

Mozilla MDN：Transport Layer Security (TLS) — TLS 的加密、完整性、驗證與混合內容說明。
EFF Surveillance Self-Defense：Choosing the VPN That's Right for You — VPN 用途、限制、信任轉移與選擇準則。
CISA：Securing Wireless Networks — 公共 Wi-Fi、假基地台與流量監聽風險。
FTC：Are Public Wi-Fi Networks Safe? — 公共 Wi-Fi、HTTPS 與假網站提醒。
Proton VPN：Why you need VPN to stay safe on public WiFi — DNS 查詢、公共 Wi-Fi 與 VPN 的差異說明。

Proton VPN 付費版評價（2026）：VPN Plus 值得訂閱嗎？

2026-08-10T05:18:00Z

你已經用 Proton VPN 免費版一陣子了——不限流量、沒廣告，在咖啡店連公共 Wi‑Fi 還算安心。結果一到尖峰時段，影片轉圈圈、不能自己選國家、串流跟 BT 下載通通說再見，你就會開始想：付費版到底值不值得？還是免費版已經夠我這杯咖啡的預算？

這篇不談「VPN 是什麼」（那篇留給入門文），專攻 VPN Plus 付費版評價：速度差多少、哪些功能只有付費才有、跟 NordVPN、Surfshark 比怎麼選，以及訂閱前該確認的價格與退款條件。若你想先看免費版全貌，可搭配站內另一篇 Proton VPN 值得買嗎？免費版與付費版功能完整解析。

先講結論：付費版適合誰？

你的情境	建議	原因
只在咖啡店偶爾上網、1 台裝置就夠	先維持免費版	免費版已有 Kill Switch、無日誌、不限流量；付費的串流／選國家你用不到
想看 Netflix、Disney+ 等地區片庫	VPN Plus	官方串流支援僅限付費方案；免費版不包含
需要 BT／P2P 下載	VPN Plus	免費版不支援 P2P；Plus 有專用高速伺服器
家中 2–10 台裝置同時連線	VPN Plus	最多 10 個同時連線（每個使用中的瀏覽器擴充也算 1 個）
重視可驗證的隱私證據，偶爾需要 Secure Core	VPN Plus	Secure Core、NetShield、Stealth 混淆協定都是付費功能
同時需要 Proton Mail、Drive、Pass	Proton Unlimited	別只用 VPN 月費比；把整個生態系需求一起算
家中超過 10 台裝置常同時連線	先比 Surfshark	Surfshark 付費方案不限同時連線；Proton Plus 上限 10 台
主要追求最低月費或電視 Smart DNS 便利	先比 NordVPN	NordVPN 在串流設備與近距離延遲上常有優勢，但隱私透明度呈現方式不同

一句話總結：付費版的核心價值不是「比免費版快一點點」——那是把 VPN 當成咖啡濃縮，其實你缺的是整杯。完整伺服器選擇、串流／P2P、多裝置，加上 Secure Core 等進階功能，才是升級理由。若你只用免費版做基本加密，其實已經比多數免費 VPN 安全；付費是為了解除那些「剛好卡住你」的限制。

付費版多了什麼？（VPN Plus 功能評價）

速度：差距比你想的大

Proton 不對免費版人工限速，但免費伺服器（美國、荷蘭、日本）負載高，尖峰時段常擠——就像尖峰時段只有三條免費高速公路可選，還不能自己挑出口。第三方測試與社群實測的參考區間如下：

指標	免費版	VPN Plus 付費版
典型下載速度	50–150 Mbps（尖峰可能 <30 Mbps）	950–1,500+ Mbps
典型上傳速度	30–80 Mbps	800–1,200+ Mbps
延遲（Ping）	20–200+ ms	本地 5–30 ms；跨國 80–150 ms
伺服器	3 國自動分配	140+ 國、20,000+ 台 10 Gbps 伺服器
網路優先權	低（排隊等頻寬）	高（Priority Access）

付費版還有 VPN Accelerator：透過優化 TCP 擁塞控制，長途連線速度可提升數倍。日常 4K 串流、大檔下載、視訊會議，付費版的穩定度通常明顯好一截。

誠實提醒：以上數字來自第三方基準測試，你的實際結果會受 ISP、地理位置、伺服器負載與協定影響。訂閱前建議自己測——別讓評測文替你喝這杯苦澀的現實咖啡。

只有付費版才有的功能

功能	做什麼	適合誰
完整伺服器選擇	自由選 140+ 國家，不再被系統分配到美／荷／日	需要特定地區 IP 的人
串流支援	官方列出的 Netflix、Disney+ 等 Plus 伺服器	旅行或跨區看自有訂閱的片庫
P2P／BT	專用高速伺服器	合法的大檔傳輸需求
Secure Core	流量先經瑞士／冰島／瑞典入口，再到出口國	高風險地區出口、重視實體防禦的使用者
NetShield	DNS 級別擋惡意網域、廣告與追蹤器	想少裝一個廣告攔截器的人
Stealth 協議	把 VPN 流量偽裝成 HTTPS，繞過 DPI 審查	在嚴格網路環境需要連線的人
Split Tunneling	指定哪些 App 走 VPN、哪些走直連	同時要本地銀行 App 與 VPN 的場景
瀏覽器擴充	Chrome／Firefox 一鍵連線	只想保護瀏覽器、不想全機 VPN 的人

Secure Core 和 Stealth 是 Proton 付費版較有特色的進階功能，多數競品沒有同等架構。但若你只是在家看串流，這兩個功能不是必開——Secure Core 還會讓速度更慢，官方也不建議拿它來排串流。開 Secure Core 看 Netflix，就像穿三層雨衣去海邊——很安全，但你不會因此游得比較快。

隱私與安全：付費版有比較安全嗎？

加密標準免費與付費相同（AES-256、WireGuard 等），差別在進階功能與伺服器架構：

無日誌政策：免費與付費共用同一套政策；Securitum 已連續第五年稽核，2026 年報告未發現伺服器記錄瀏覽活動或連線中繼資料。
瑞士管轄：截至 2026 年 6 月的透明度報告，47 件外國請求全部標為無法提供資料——因為沒有紀錄可交。
開源 App：程式碼公開在 GitHub，任何人可審計。
Kill Switch：免費版也有；但 macOS 切換伺服器時可能有短暫 IP 暴露，各平台限制不同。

付費版真正的安全加值是 Secure Core（多一跳、實體防禦入口）和 NetShield（擋已知惡意網域），不是「付費才加密」。若你重視可驗證的隱私證據，Proton 在公開稽核與開源這點上，確實比多數競品透明。

付費版值得買嗎？決策表

把「要不要付費」拆成可勾選的條件：

你的需求	免費版夠嗎？	付費版加分多少？
公共 Wi‑Fi 基本加密	✅ 夠	付費主要是速度與穩定度
自己選伺服器國家	❌ 不夠	⭐⭐⭐ 必要
Netflix／Disney+ 串流	❌ 不夠	⭐⭐⭐ 必要（但仍不保證每部片）
BT／P2P 下載	❌ 不夠	⭐⭐⭐ 必要
同時 2 台以上裝置	❌ 免費只有 1 台	⭐⭐⭐ 必要
擋廣告／惡意網域	❌ 沒有 NetShield	⭐⭐ 加分
繞過嚴格網路審查	❌ 沒有 Stealth	⭐⭐ 加分
高風險出口監控	❌ 沒有 Secure Core	⭐⭐ 加分（少數人需要）
只要最低月費	✅ 免費 $0	付費未必最便宜——見下方競品比較

勾選 3 項以上「付費版必要」 → 升級 VPN Plus 很合理。
只勾 1 項「速度」 → 建議先在自己網路實測免費版尖峰速度，再決定。別為了「感覺比較快」付年費，結果發現瓶頸其實是你家 Wi‑Fi——那杯咖啡就白喝了。

價格與方案：別只看促銷標語

官方結帳頁價格會依幣別、地區與促銷變動，以下為研究時的快照，訂閱前請直接查官方頁面：

方案	計費方式	參考價格（快照）	適合誰
Proton Free	—	$0	輕度使用者、先建立信任
VPN Plus	月繳	約 US$9.99／月	短期試用、不想一次付兩年
VPN Plus	年繳	約 US$3.99／月（一次 US$47.88）	確定會用滿一年
VPN Plus	兩年繳	約 US$2.99／月（一次 US$71.76）	長期使用者、單看 VPN 最划算
Proton Unlimited	依官方頁	含 Mail、Drive、Pass、VPN	本來就要用 Proton 全家桶

結帳前三件事：

看「今天要付多少」，不是只看每月折算價。
記下續費價格——促銷期過後可能不同。
確認付款管道——官網、App Store、Google Play 的退款入口不一樣。

30 天退款：訂閱前的安全網

首次直接向 Proton 購買，可在 30 天內取消並申請退款（每位使用者退款選項通常只能用一次）。重點：

取消 ≠ 退款：兩個動作都要做。
刪除 App 不會停扣款：必須在原付款管道取消續訂。
App Store／Google Play 購買：退款要走 Apple 或 Google 的流程，不是 Proton 網站。
取消後通常仍可用到目前計費週期結束，之後降回免費版。

若你只是不確定付費版好不好用，善用 30 天退款期在自己網路實測，比看十篇評測文更有說服力——畢竟你的 ISP 不會因為別人測速漂亮就對你特別溫柔。

跟 NordVPN、Surfshark 比：付費版站得住嗎？

若你已經決定要付費 VPN，但還在猶豫品牌：

比較面向	Proton VPN Plus	NordVPN	Surfshark
同時連線數	10 台	10 台	不限
隱私透明度	Securitum 稽核公開、App 開源、瑞士管轄	Deloitte 查核（報告需登入查閱）、巴拿馬公司	Deloitte 查核、荷蘭管轄
免費入門	✅ 不限流量免費版	❌ 無	❌ 無
串流設備便利	路由器／支援的 App	Smart DNS 對電視較方便	Fire TV、Android TV 等官方支援完整
獨特功能	Secure Core、Stealth、NetShield	NordLynx、威脅防護套件	不限裝置、RAM-only 伺服器
30 天退款	✅（依付款管道）	✅（續費不在內）	✅（依方案與管道）

選 Proton 付費版，若你已經用免費版、想無縫升級；重視公開稽核報告與開源；裝置數 ≤10 台；需要 Secure Core 或 Stealth。

先試 NordVPN，若你主要在智慧電視／遊戲主機看串流（Smart DNS 較省事）；重視近距離低延遲；不在意沒有免費版可長期使用。

先試 Surfshark，若你家中同時連線超過 10 台；預算優先、想要不限裝置。

沒有絕對贏家——兩家都有獨立無日誌查核，差別在證據呈現方式、功能取向與你的使用情境。建議在 30 天退款期內各測自己常用的串流服務與網路環境。

串流實際表現：付費版的真實期待

付費版才支援官方串流伺服器，但這不代表「買了就能看全世界」：

Netflix、Disney+ 仍需另外訂閱；VPN 訂閱不包含串流會員。
Netflix 廣告方案與直播活動官方明確不支援 VPN。
串流平台會更新封鎖規則，不能保證永久解鎖任何片名。
排串流問題時，不要用 Secure Core——它為安全設計，不是為速度。
遇到「使用 VPN 或 Proxy」錯誤：換 Plus 伺服器 → 重開 App → 清快取 → 暫時關 NetShield 測試 → 用 ipleak.net 查 IP／DNS 洩漏。

合理期待：付費版讓你在旅行或跨區時，有機會用自有訂閱看原本的片庫；不是繞過版權的萬能鑰匙。VPN 不是 Netflix 會員卡的加購醬料包。

訂閱前檢查清單

在按下付款前，逐項確認：

[ ] 我需要的功能（串流／P2P／多裝置／選國家）免費版確實做不到
[ ] 同時連線裝置數 ≤10（含瀏覽器擴充）
[ ] 已看過官方當下價格與續費價格
[ ] 知道退款入口（官網／Apple／Google）
[ ] 會在 30 天內實測常用服務與網路速度
[ ] 不把 VPN 當成防毒或完全匿名工具

產品	適合誰	說明
Proton VPN Plus（主推）	已用免費版、需要串流／P2P／多裝置／完整伺服器	30 天退款可實測；開源 App + 公開無日誌稽核
Proton Unlimited	同時需要 Mail、Drive、Pass 的 Proton 生態系使用者	別只用 VPN 單價比，把全家桶需求一起算
Proton Free	輕度使用者、還不確定要不要付費	先建立信任，確認限制再升級
NordVPN	重視電視串流便利（Smart DNS）、近距離低延遲	隱私查核報告需登入查閱；無免費版
Surfshark	家中超過 10 台裝置同時連線	不限同時連線；荷蘭管轄、Deloitte 查核

結語：我的評價

Proton VPN 付費版（VPN Plus）值得訂閱嗎？——若你已經被免費版的「不能選國家、不能串流、只有 1 台裝置、尖峰變慢」卡住，值得。付費版解的不只是速度，而是把 VPN 從「偶爾用用的安全網」變成「日常可用的完整工具」。

但若你只是偶爾在咖啡店上網、一台手機就夠，免費版已經是市場上少數真正可信的選擇，不必為了「付費比較安心」而多花錢——加密標準是一樣的，你的錢包不會因為多付而多一層 AES-256。

三個重點帶走：

付費版的核心價值是串流、P2P、多裝置、完整伺服器與 Secure Core／NetShield／Stealth，不是「付費才安全」。
價格要看續費與付款管道，善用 30 天退款在自己網路實測。
競品不是全面輸贏——裝置數 >10 看 Surfshark，電視串流便利看 NordVPN，隱私透明度與免費漏斗看 Proton。

若你確認需要 Plus 的功能，建議先到 Proton 官網領免費帳號（若還沒有）→ 在 30 天退款期內升級 VPN Plus 實測 → 不合適就依付款管道申請退款。決定好了再來一杯慶祝——或繼續喝免費版也沒關係，至少你的連線有加密。

聯盟揭露： 本文包含 Proton VPN 推薦連結。若你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。本文依研究筆記與官方文件撰寫，請依你的實際需求與測試結果做最終決定。

👉 免費申請 Proton 帳號 →

參考資料

Proton VPN plans explained — 官方方案類型、Free 與 Plus 功能差異。
Proton VPN official pricing — 結帳時的方案、幣別與促銷價格（以當日頁面為準）。
How to cancel a Proton VPN subscription — 取消步驟、退款管道與處理時間。
Does Proton VPN keep logs? — 無日誌政策說明。
Proton VPN passes 5th annual external audit — 2026 年 Securitum 無日誌稽核。
How to watch Netflix with Proton VPN — 串流支援範圍與限制。
Proton VPN Features — Secure Core、NetShield、Stealth 等功能說明。

為什麼要發明 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 注意事項。

光輝咖碼

VPN 跟 HTTPS 差在哪？公共 Wi-Fi 上到底要開哪一個？

目錄

一句話記住：兩者保護的範圍不同

HTTPS 保護什麼？鎖頭代表什麼？

VPN 補上哪一塊？為什麼 HTTPS 夠了還有人開 VPN？

情境決策表：我現在要做的事，要開 VPN 嗎？

公共 Wi-Fi 常見情境

我要做什麼 → 怎麼連線（一頁帶走）

只有 HTTPS 夠嗎？快速對照

常見誤解：別把鎖頭或 VPN 當萬能藥

三分鐘安全檢查清單

推薦工具與資源

結語：先搞懂層次，再決定要不要開 VPN

參考資料

Proton VPN 付費版評價（2026）：VPN Plus 值得訂閱嗎？

目錄

先講結論：付費版適合誰？

付費版多了什麼？（VPN Plus 功能評價）

速度：差距比你想的大

只有付費版才有的功能

隱私與安全：付費版有比較安全嗎？

付費版值得買嗎？決策表

價格與方案：別只看促銷標語

30 天退款：訂閱前的安全網

跟 NordVPN、Surfshark 比：付費版站得住嗎？

串流實際表現：付費版的真實期待

訂閱前檢查清單

推薦工具／資源

結語：我的評價

參考資料

為什麼要發明 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

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

常見問題排查

搜尋框出現，卻沒有結果

中文結果很少

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

部署前先確認 `_site`

依專案設定 `public/.htaccess`

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

用 `curl` 驗收 response headers

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

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