光輝咖碼

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

2026-08-03T07:45:00Z

繁體中文網站最容易被忽略的效能成本，往往不是第三方腳本，而是字型。

一套完整的 CJK 字型可能超過 10MB；如果把它整包送給每位訪客，手機使用者會先等字型下載，才看到穩定的文字。這篇整理 2026 年比較實用的做法：先用系統字體扛住大部分內文，再把真正需要品牌風格的字型做子集化。少載一點，咖啡就能早一點喝到。

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

如果網站是內容型部落格、管理後台或文件站，最划算的選擇通常是系統字體優先。系統字體不需要額外下載，對 LCP、FCP 和行動流量都比較友善：

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

macOS 與 iOS 通常會使用 PingFang TC，Windows 則多半 fallback 到 Microsoft JhengHei。如果你不需要完全一致的品牌字形，這一步可能比任何字型工具更有效。

三種字型策略怎麼選？

情境	建議做法	取捨
內容型部落格	全站系統字體 + `font-display: optional`	最快，但不同平台字形不完全一致
品牌官網或 Landing Page	標題使用子集化 Web Font，內文用系統字	兼顧美觀與速度，需維護字元清單
需要固定品牌字形的產品 UI	自架 WOFF2 + 動態或靜態子集化	控制力最高，但要加入 build 流程

不要為了「看起來專業」就讓整篇內文載入完整 Noto Sans TC。先把 Web Font 限制在 H1、H2 或少量 UI 元件，通常更容易得到可接受的效能與一致性。

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

中文字型需要涵蓋數千到數萬個漢字、標點與不同字重，完整檔案常達 10MB 以上。以一個實際靜態站案例來看，Google Fonts 曾依 Unicode 範圍送出 23 個請求、共約 1.78MB；改成依站內實際用字自架後，該案例收斂為 4 個請求。這是特定頁面與測試條件的案例，不是所有網站都會得到相同數字。

外部 CDN 通常還會多出 fonts.googleapis.com 與 fonts.gstatic.com 的連線設定成本；但自架不代表一定更快，還要看 CDN、HTTP 版本、CSS 發現時機與實際字型分片。瀏覽器快取也可能受分區策略影響，跨站共用快取的優勢不能直接當成保證，因此「同網域自架」值得納入實測比較。

子集化到底在做什麼？

子集化就是從完整字型裡只留下網站真的會用到的字，再輸出較小的 WOFF2。

有兩種常見模式：

靜態子集化：掃描一頁內容，只保留這頁的字。檔案最小，適合單頁 Landing Page；但內容一改就要重跑。
Unicode-range 分片：把字型切成許多小碎片，CSS 用 unicode-range 宣告每個碎片負責的範圍。瀏覽器會依頁面文字與範圍判斷需要哪些分片；一旦某分片匹配，通常會下載整個分片，而不是只下載其中一個字，適合內容持續增加的網站。

子集裡沒有的字不會自動變成方框。瀏覽器會沿著 font-family 堆疊找下一個可用字型；真正的代價是那個字可能和周圍文字有些風格差異。

自架子集化的實作流程

1. 保留 Latin 與站內實際 CJK 字元

掃描文章、模板與導覽文字，收集漢字、全形標點和英文數字。Latin 子集則建議沿用 Google Fonts 原本的字元範圍，避免英文、貨幣符號或常用標點突然 fallback。

2. 用工具產出 WOFF2

cn-font-split 適合把大字型切成 Unicode 分片；如果想依整個網站實際用字產出單一子集，也可以使用 subset-font，其底層是 HarfBuzz hb-subset 的 WASM 封裝。

概念上的流程如下：

掃描 .md / .njk
      ↓
收集 Latin + CJK 字元
      ↓
subset-font / cn-font-split
      ↓
輸出 .woff2
      ↓
CSS @font-face 掛載

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;
}

swap 會先顯示系統字，再替換成 Web Font，適合品牌標題；內容型網站若更在意避免文字跳動，可考慮 optional，讓載入不及時的訪客直接維持系統字。實際 block/swap 時間是瀏覽器依規格建議值實作，不是固定保證。

4. 把它接進 build 流程

新增文章或修改導覽列後，重新執行例如 pnpm run subset-fonts。原始字型可以快取，所以通常不需要每次重新下載；重點是讓「新增內容 → 重跑子集 → 測量效能」成為固定流程。

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

改成自架後，檢查 <head> 裡的 Google Fonts preconnect、preload、stylesheet 與 noscript 標籤，避免新舊兩套字型同時載入。

常見錯誤與取捨

直接上傳 OTF/TTF：檔案太大，應先輸出 WOFF2。
只留下漢字、忘了 Latin：英文和數字可能換成不同風格，應保留常用 Latin 子集。
把整個網站都套品牌字體：流量與載入成本會快速增加，先限制在標題或 UI。
以為 fallback 就代表沒有問題：雖然不會 tofu，但罕見字的字形可能不一致，上線前要測試。
只看檔案大小、不測實際體驗：請用 PageSpeed Insights 或自己的效能驗收流程觀察 LCP、FCP、CLS 與文字顯示是否改善。

工具或做法	適合誰	特色
PageSpeed Insights	所有站長	檢查字型改動是否真的改善載入與 Core Web Vitals
`cn-font-split`	需要 Unicode 分片的網站	讓瀏覽器按需載入字型
`subset-font`	想整合 Node.js build 流程的開發者	將站內實際用字打包成 WOFF2
系統字體堆疊	內容站與文件站	不需下載，載入成本最低

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

內容站先用系統字體，不要預設整包載入 CJK Web Font。
需要品牌字形時，只把標題或 UI 子集化並自架 WOFF2。
用 font-display、fallback 與實際 CWV 測量確認取捨，而不是只看理論檔案大小。

下一步很簡單：先用 PageSpeed Insights 記下改動前的數據，再選一個頁面做字型子集化，最後比較 LCP、CLS 和實際文字顯示。先測一頁就好，不必一口氣把整個網站的字型 pipeline 變成考古現場。

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

2026-08-03T06:45:00Z

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

LCP（Largest Contentful Paint）量的是「首屏最大的那個元素，什麼時候真的被畫出來」。這篇只做一件事：把 LCP 優化拆成可以動手驗收的策略，並把你最容易踩的坑講清楚。如果你剛處理完 CLS（圖片預留寬高），這篇剛好接著把「載入速度」補齊。

先抓到你真正的 LCP 元素

不要猜「應該是主視覺圖」。流程是：

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

靜態網站常見 LCP 來源：主視覺圖、H1 標題、產品截圖。Google 2026 門檻仍是 LCP ≤ 2.5 秒（CrUX 第 75 百分位），不是 Lighthouse 實驗室分數。想先搞懂欄位資料 vs 實驗室差異，可看站內 PageSpeed Insights 與 Core Web Vitals 2026。

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

情境	建議做法	為什麼
確認是 LCP 的主視覺圖	`loading="eager"` + `fetchpriority="high"`	不要延遲載入主角；拉高下載優先級
LCP 是 CSS 背景圖或 JS 動態插入	`<link rel="preload" as="image" fetchpriority="high">`	瀏覽器從 HTML 掃不到，要主動宣告
內文圖、頁尾圖、側欄縮圖	`loading="lazy"`（預設即可）	不在首屏，延後載入省頻寬
全站只有 1–2 張關鍵圖	只對那 1–2 張用 `fetchpriority="high"`	濫用高優先級會把佇列分流掉
Eleventy Image Transform 預設 `lazy`	主視覺圖手動覆寫 `loading="eager"`	管道預設 lazy ≠ 每張都該 lazy

一句話心法：LCP 元素 不要 lazy；關鍵圖 拉高優先級；其餘圖片照常 lazy。

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

1. 不要 lazy-load LCP

最常見的壞操作：把 LCP 圖片加上 loading="lazy"。這會刻意延遲「載入 → 解碼 → 繪製」，LCP 就跟著往後延。

<!-- ❌ 自殺操作：主視覺圖被 lazy -->
<img src="/img/hero.webp" loading="lazy" alt="主視覺">

<!-- ✅ 首屏主角：明確 eager + 高優先級 -->
<img
  src="/img/hero.webp"
  alt="主視覺"
  width="1200"
  height="630"
  loading="eager"
  fetchpriority="high"
/>

順便補 width／height 預留版面——LCP 和 CLS 常常同一張圖一起修。細節見站內圖片最佳化與 CLS 解決方案。

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

當 LCP 是圖片時，方向是：

主視覺圖：加 fetchpriority="high"
配合（需要時）在 <head> 用 preload 宣告，讓瀏覽器先知道「這張是主角」

<!-- CSS 背景 LCP 或較晚才出現在 DOM 的圖：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"
/>

fetchpriority="high" 適用在 LCP／首圖這種關鍵資源；不要濫用，不然你會把優先權分流掉，大家都變「高優先級」就等於沒有。

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

若你用 @11ty/eleventy-img 的 HTML Transform，設定裡常見預設 loading: "lazy"——對內文圖很好，對 主視覺圖是災難。在該張圖覆寫：

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

同時確認主視覺圖檔案大小合理（目標 < 150KB）、顯示寬度對齊（手機 400px 寬就不要傳 4000px 原圖）。格式用 WebP／AVIF 通常比 JPEG 小 25–50%。

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

如果你把非關鍵 JS／CSS 搞成阻塞鏈，LCP 再怎麼優先級也可能等不到繪製窗口。快速檢查：

資源類型	建議
非關鍵 JavaScript	`defer` 或 `async`；第三方標籤延後到 `requestIdleCallback`
CSS	避免 `@import` 串接；關鍵 CSS < 14KB 可考慮 inline
Web 字體	`font-display: swap`；關鍵字體可 `<link rel="preload" as="font">`

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

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

LCP 是「什麼時候畫出來」，CLS 是「有沒有抖」。有些站看起來 LCP 差，其實是版面在動，最後量測也會一起變差。

建議順序：

先確保圖片／嵌入不會讓版面在載入期抖動（CLS 預留）
再回頭把 LCP 圖片的優先級拉到位
最後用 GSC → 體驗 → Core Web Vitals 對 欄位資料 驗收（28 天週期）

框架快速對照

框架	圖片管道	LCP 注意事項
Hugo	`resources.Get` + `Resize`／`webp`	主視覺圖模板別加 lazy
Eleventy	`@11ty/eleventy-img`	Transform 預設 lazy，主視覺圖覆寫 eager + fetchpriority
Astro	`astro:assets` 或 `<Image />`	內建 lazy，記得 LCP 關 lazy

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

用 PSI／DevTools 找出真正的 LCP 元素，別憑感覺改
LCP 元素不要 loading="lazy"；關鍵圖加 fetchpriority="high"，必要時 preload
Eleventy 管道預設 lazy 時，主視覺圖一定要手動覆寫
render-blocking 別讓首屏卡住；驗收以 GSC 欄位資料為準

下一步：先把 LCP 圖片／資源優先級調到位；同時確保 HTTPS／憑證鏈完整——自架站可用 ZeroSSL 申請免費憑證，流程穩了再回 GSC 看 28 天滾動更新。改完記得再來一杯，這次是慶祝分數回來的那杯。

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，也不能保證兩條路不會同時進入函式。

可直接複製的最小版本

把 GTM-XXXXXXX 換成自己的 container ID。這段程式會先建立 dataLayer，再在互動或 idle 時只載入一次 GTM。

(function (w, d) {
  var started = false;
  var idleId = 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);
    }

    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 {
    idleId = w.setTimeout(boot, 2000);
  }
})(window, document);

requestIdleCallback 的 timeout 不是精準鬧鐘。瀏覽器會先等 idle period；若期限到了還沒執行，才把 callback 排進 event loop。它能限制等待時間，但不代表 GTM 會在那一刻完成下載或執行。

另外，Safari 和不同 WebView 的支援狀況可能不同，所以用 feature detection 比寫死「Safari 不支援」安全。舊版環境才需要 fallback。

timeout 要設多少？

真正要平衡的是「首屏保護」和「資料多早開始收集」。沒有一個數字適合所有網站，先用實測建立基準比較可靠。

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

如果登入、註冊或購買事件不能漏，不要把所有 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 審計、仍有明確長任務問題的技術型網站，不是第一個該按的按鈕。

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

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

固定同一個 URL、GTM container、裝置策略和 cookie／consent 狀態。
PSI 兩個版本都跑多次，記錄 LCP、TBT、CLS、FCP，不要用單次分數宣稱因果。
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 和資料完整度調整。修完再喝一口咖啡，這次讓瀏覽器先喝。

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

2026-08-03T03:15:00Z

你有沒有遇過這種情況：正準備點一個連結，圖片突然載入，整段文字往下一跳。結果手指點到旁邊的空白，只能在心裡默念：「謝謝，咖啡涼了。」

圖片最佳化不是單純把檔案壓到越小越好。面對 PageSpeed 和 Core Web Vitals，你通常要同時處理兩件事：

LCP（載入速度）：首圖什麼時候真正顯示出來？檔案太大、尺寸又不合適，下載自然會變慢。
CLS（版面穩定度）：圖片還沒載完之前，下面的內容會不會被往下推？沒有預留寬高，版面就容易跳動。

網站通常有很多圖片，像是產品截圖、比較表和規格圖。這篇先專心處理三件事：控制檔案大小、符合顯示寬度，以及預留圖片版面，並整理成可以直接照做的決策方式和範例。至於 LCP 的 fetchpriority 細節，留到之後再深入討論；這次先把「不要亂跳，也不要浪費頻寬」處理好。

先搞清楚：圖片最常造成兩種效能問題

靜態網站最常見的圖片問題，大概有這幾種：

圖沒有可預測的高度（CLS）
hero／內文圖過肥，或丟超大原圖給小螢幕（LCP）
圖很多卻全靠手壓，漏寫 width／height

這篇會聚焦在：預留圖片尺寸、讓檔案大小和顯示寬度對得上，以及（可選的）Eleventy 圖片處理流程。字體、Cookie 橫幅和第三方腳本造成的 CLS／INP，先留到另一篇處理。一次解決一類問題，才不會改到最後連自己在修什麼都忘了。

以 2026 年的標準來看，Google 建議 CLS ≤ 0.1、LCP ≤ 2.5 秒。這裡看的是 CrUX 第 75 百分位的真實使用者資料，不是本機 Lighthouse 跑到 100 分就代表一切沒問題。想先了解 PageSpeed Insights 和欄位資料的差異，可以參考 PageSpeed Insights 與 Core Web Vitals 2026。

決策表一：width+height 還是 aspect-ratio？

白話一點說，瀏覽器在下載圖片前，最好先知道「這張圖大概會佔多高」，才不會把下面的內容推歪。HTML 的 width 和 height 會提供比例提示；再搭配 max-width: 100%; height: auto;，圖片在響應式縮放時，版面預留仍然有效。

可以把它想成搬家：先用膠帶在地板上標出沙發的位置，就算貨車晚一點到，也不會把其他家具推歪。圖片預留就是那捲膠帶。

情境	優先做法	為什麼
一般 `<img>`（hero、內文、產品圖）	HTML 真實像素 `width` + `height` + CSS `max-width:100%; height:auto;`	web.dev 推薦；瀏覽器自動算比例
比較表／圖牆：多張截圖要同一視覺框	外層容器 `aspect-ratio: 16/9`（或 4/3），圖用 `object-fit: cover`	各圖比例不一也能先佔固定高
iframe／YouTube 等嵌入	容器設 `aspect-ratio` 或固定高度	嵌入預設比例常怪，容易抖
還沒定最終檔案尺寸的占位	先用 CSS `aspect-ratio`，上線前補真實寬高	過渡方案

一般情況優先使用 HTML 寬高。 CSS 的 aspect-ratio 比較適合容器、嵌入內容或需要統一裁切比例的情境，不能完全取代每張圖片的寬高屬性。

可複製：一般內文／hero

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

/* 全站圖建議基底——不要寫 width: auto */
img {
  max-width: 100%;
  height: auto;
}

width 和 height 要填的是圖片檔案本身的像素尺寸，不是圖片在螢幕上實際顯示的寬度。顯示大小交給 CSS 控制就好。

可複製：固定比例截圖容器

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

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

.shot img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  max-width: none;
}

常見錯誤（預留會失效）

錯誤	為什麼翻車	怎麼改
只有 `max-width: 100%`，沒有 width/height	高度從 0 撐開 → 下面全跳	補真實 `width`+`height`
CSS 寫了 `img { width: auto; }`	蓋掉 HTML 寬度 hint，未載入變 0×0	刪掉 `width: auto`，保留 `height: auto`
width/height 比例填錯	先留錯高，圖載入再校正 → 仍算 CLS	用檔案真實像素核對
Lazy 圖沒預留	捲到才撐高 → post-load CLS	lazy 圖同樣要有寬高

5 分鐘快速檢查：全站搜尋 <img，確認每張圖都有寬高 → 檢查全域 CSS 沒有 width: auto → 用 PSI 或 Performance 面板查看 Layout Shifts。修完再喝一口咖啡，版面和心情都會穩定不少。

決策表二：檔案大小、顯示寬、WebP／AVIF

與其一直調低圖片品質，很多時候先符合顯示寬度更有效。手機上的內容欄可能只有 400px，卻載入一張 4000px 的原圖，像素數量差了不只一點點，下載和解碼都會變慢。這就像點了全家桶外送，最後只吃一塊雞塊。

顯示寬（約）	建議產出寬（約，含 2× DPR）
手機全寬 ~360–430px	720–860px
內容欄 ~640–720px	1280–1440px
Hero 全寬桌面 ~1200px	1200–1600px（超過 2000 通常浪費）

站內檔案預算（實務目標，非官方硬門檻）

類型	目標大小	用法
Hero／LCP 圖	< 150KB	優先保證首屏最大圖下載快
內文圖／截圖	< 80KB	長文多圖時累積流量很明顯
小縮圖／圖示	< 20–30KB	能用 SVG／CSS 就別用照片

這些數字不是 Google 訂下的官方門檻；Google 真正關心的是載入時間和版面位移。把圖片控制在合理大小，是讓使用慢速手機或 4G 網路的讀者更容易通過 LCP 的實用做法。

如果圖片超過預算，可以按照這個順序處理：先縮小寬度 → 改用 AVIF／WebP → 微調壓縮品質 → 裁掉不重要的背景。

格式怎麼選

條件	建議
靜態站、build 一次產檔	AVIF + WebP + JPEG（`<picture>`）
只想維護一種現代格式	WebP + JPEG
UI 截圖、文字要銳利	別壓太狠；必要時略提高品質
Logo／簡單圖示	SVG 優先

<picture> 順序：先 AVIF，再 WebP，<img> 用 JPEG／PNG 兜底。瀏覽器會選第一個它吃得下的。

最小可用：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"
/>

sizes 寫錯，瀏覽器常會下太大檔——等於你說「我只要一杯」，店員卻端來整壺。Hero／LCP 圖請用 loading="eager"（必要時加 fetchpriority="high"），別把首屏主角設成懶載入。

手動壓檔可用 Squoosh：先縮寬 → 試 AVIF／WebP → 符合 KB 預算 → 再寫真實寬高。

決策表三：手動補寬高，還是上 Eleventy 圖片管道？

圖片不多時，手動處理還可以接受；但如果網站每週都要放截圖，漏寫寬高或直接放出原始大圖，幾乎只是早晚的事。尤其是請 AI 產生 Markdown 時，它很愛順手塞一張超肥的 PNG。

如果你使用 Eleventy，可以考慮官方套件 @11ty/eleventy-img。建議先從 Image HTML Transform 開始，它能在建置時自動產生多種尺寸和現代圖片格式，也會幫你補上 width／height。

情境	建議
全站 < ~20 張圖、很少更新	手動縮圖 + 寫 `width`/`height` 可接受
部落格持續貼截圖／hero	HTML Transform（推薦）
需要每圖不同裁切／藝術方向	Image shortcode 或 WebC
只要先救 CLS、暫不產多尺寸	至少手動補真實寬高

最小設定概念：

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

export default function (eleventyConfig) {
  eleventyConfig.addPlugin(eleventyImageTransformPlugin, {
    formats: ["avif", "webp", "jpeg"],
    widths: [400, 800, 1200, "auto"],
    htmlOptions: {
      imgAttributes: {
        loading: "lazy",
        decoding: "async",
        sizes: "(max-width: 768px) 100vw, 720px",
      },
    },
  });
}

注意：Transform 預設通常會使用 loading: "lazy"。Hero／LCP 圖要改成 eager，必要時再加上 fetchpriority="high"。如果產生了多種寬度，也要記得設定合理的 sizes，否則瀏覽器可能把它當成 100vw，下載比實際需要更大的圖片。

建議按照這個順序導入：先檢查全站圖片並補上寬高，先把 CLS 穩住 → 再開啟 Transform，抽查建置結果 → 新文章只放合理尺寸的原圖。不要再丟一張 8000px 的巨圖，然後安慰自己「以後可能用得到」。

Hugo／Astro 也有對應圖片管道；原則相同：建置時產對的尺寸 + 寫上寬高。

需求	工具／做法	適合誰
手動壓到 KB 目標	Squoosh、ImageOptim	圖少、先驗流程
Eleventy 自動多尺寸＋寬高	`@11ty/eleventy-img` Transform	持續發文的靜態站
驗收欄位資料	GSC → 體驗 → Core Web Vitals、PageSpeed Insights	修完要對真實使用者分數
圖都瘦了但全站仍慢（TTFB／憑證）	ZeroSSL 檢查／更新 HTTPS 憑證鏈	自架或憑證快到期、混合內容警告時

結語：圖片最佳化，就是別讓 CLS 亂跳、也別拖慢下載

每張 <img> 補真實 width＋height（或容器 aspect-ratio）；刪掉會搞壞預留的 width: auto
顯示寬符合再壓檔：hero 瞄準 < 150KB、內文 < 80KB；優先 AVIF／WebP
圖一多就上 build 管道（Eleventy 用 eleventy-img），hero 記得覆寫勿 lazy
用 GSC／PSI 驗收；欄位資料大約看 28 天滾動

下一步：先替全站圖片補齊寬高，並檢查 Hero 和內文圖片是否符合檔案預算。如果建置產物都沒問題，但 TTFB 仍然偏高，或憑證出現警告，再用 ZeroSSL 把 HTTPS 和憑證鏈處理好，最後回到 GSC 對照體驗資料。檢查完，再來一杯咖啡。

Proton VPN 值得買嗎？免費版實測 + 付費版完整功能深度解析

2026-08-02T13:25:00Z

你是不是也曾經在 App Store 搜尋「免費 VPN」，然後下載了一個評分看起來還不錯的 App，結果沒多久卻看到新聞說「某某免費 VPN 洩露用戶資料」？

免費 VPN 的世界充滿陷阱——有些偷偷蒐集你的瀏覽紀錄販售給廣告商，有些在背景悄悄挖礦，有些甚至將你的裝置當成流量節點出租。但付費 VPN 動輒每月數百元，又讓人下不了手。

有沒有兩全其美的選擇？

有。而且它來自一家由 CERN（歐洲核子研究組織）科學家創立、總部設在瑞士的公司——Proton VPN。

這篇文章會完整告訴你：Proton VPN 的免費版到底有多好用、付費版值不值得升級，以及它在技術安全層面為什麼與眾不同。

先說明我的使用背景：我自己使用 Proton VPN、Proton Drive 和 Proton Mail 已經超過兩年。選擇它們不是為了切換國家觀看 Netflix，也不是為了玩遊戲或追求其他特殊用途，完完全全就是為了提升日常的網路安全與隱私保護。對我來說，VPN 不只是「連到其他國家」的工具，而是平常使用網路時，多加一層保護的基本配備。

我去國外住飯店時，只要使用飯店 Wi-Fi，就會開啟 VPN。平常在外面遇到免費 Wi-Fi 也是一樣：只要它比手機網路更快、更順，我就會使用，但一定會先把 VPN 打開。畢竟免費 Wi-Fi 再方便，也不代表它值得完全信任。

另外，Proton Mail 也是一個非常好用的服務，可以透過別名等功能減少公開自己的主要電子郵件地址；Proton Pass 更是我認為值得列入必備清單的工具。

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

在討論 Proton VPN 之前，我們需要先理解免費 VPN 的商業模式——如果你不付錢，你就是商品。

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

出售用戶瀏覽紀錄給廣告數據公司
注入廣告腳本到你造訪的網頁中
出租你的頻寬給其他人使用（你的 IP 可能被用來做你不知道的事）
記錄 DNS 查詢並分析用戶行為

選擇免費 VPN 的風險，有時候比完全不用 VPN 還大。

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

Proton VPN 免費版的特殊之處在於，它打破了「免費一定不安全」的慣例：

✅ 完全不限流量（市場上幾乎獨一無二）
✅ 無廣告、不追蹤、不販售用戶資料
✅ 與付費版使用相同的加密標準（AES-256）
✅ 開源程式碼，任何人都能審計

那它的限制是什麼？

免費版的三個主要限制

僅支援三個國家的伺服器：美國、荷蘭、日本。如果你需要連到特定地區（例如英國看 BBC iPlayer），免費版就力有未逮。
單一裝置連線：同一時間只能在一台設備上使用。
低網路優先權：免費伺服器使用者眾多，負載常年維持在 80–95%，尖峰時段速度明顯受影響。

免費版 vs 付費版速度實測數據

根據 2026 年 TechRadar、PCMag 等第三方機構的測速基準，以及 Proton VPN 社群實測數據，以下為免費版與 Plus 付費版的詳細效能對比（測試基底頻寬：1,000 Mbps）：

評測指標	免費方案 (Free)	Plus 付費方案	效能差異
下載速度	50–150 Mbps（尖峰可能降至 30 Mbps 以下）	950–1,500+ Mbps	付費版快 6–10 倍以上
上傳速度	30–80 Mbps	800–1,200+ Mbps	免費版不適合大型上傳或 P2P
延遲 (Ping)	20–200+ ms（受限於美、荷、日三地）	5–30 ms（本地）/ 80–150 ms（跨國）	付費版可選鄰近節點大幅降低延遲
網路優先權	低優先（Deprioritized）	高優先（Priority Access）	尖峰時段付費版無明顯卡頓

💡 免費版提速技巧：若網頁載入緩慢，進入設定將連線協定強制切換為 WireGuard，可有效改善頻寬擁擠時的效率。

速度差異的技術根因：Proton VPN 並不對免費版進行人工限速，差異主要來自伺服器資源分配——Plus 版提供全球 90+ 個國家、超過 20,000 個 10 Gbps 高速伺服器，平均負載維持在 30% 以下，並搭載 VPN Accelerator 技術，透過優化 TCP 擁塞控制算法，能將長途連線速度提升達 400% 以上。

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

功能	免費版	Plus 付費版
流量限制	無限 ✅	無限 ✅
可用伺服器國家	3 個	90+ 個
伺服器數量	少量免費節點	20,000+ 個
連線速度優先權	低（共享資源）	高（10 Gbps 專屬通道）
同時連線裝置數	1 台	10 台
Netflix / 串流解鎖	❌	✅
P2P / BT 下載	❌	✅
Secure Core（雙重跳板）	❌	✅
NetShield（廣告 & 惡意軟體攔截）	❌	✅
Stealth 混淆協定	❌	✅

關鍵升級理由：如果你的主要需求是解鎖串流平台、P2P 下載，或在高審查地區穩定使用，免費版將會讓你明顯感到受限。

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

1. Secure Core：雙重跳板防禦

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

如果 VPN 的出口伺服器被監控（例如國家級的流量分析），理論上可以關聯輸入與輸出流量，找出你的真實 IP。

Proton VPN 的 Secure Core 解決了這個問題：流量會先通過 Proton 自有、實體安全等級極高的伺服器（部分位於瑞士舊軍事掩體、冰島及瑞典），再轉接至目標國家的出口伺服器。即使出口伺服器被駭，攻擊者也無法回溯你的真實位置。

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

標準的 OpenVPN 和 WireGuard 流量，其封包特徵是可被識別的。部分國家的防火牆（如中國的 GFW）會針對這些特徵進行阻斷。

Proton 的 Stealth 協定運用了雙重混淆機制：

TLS 偽裝：將 VPN 數據封裝在標準 TLS 加密通道中，讓流量看起來與銀行網站的 HTTPS 完全相同
主動探測防禦：當防火牆向 VPN 端口發送探測包驗證時，伺服器會返回普通的網頁響應，騙過 DPI 系統

這對在高審查地區旅行或居住的用戶（如往返中國大陸、中東的商務人士）至關重要。

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

NetShield 是一個基於 DNS 的網路層過濾器。當你啟用它後，DNS 請求會在 Proton 伺服器端即時與已知的廣告伺服器、追蹤器及惡意網域列表進行比對，在資源載入之前就直接封鎖該請求。

實際效益：

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

這也是我覺得 NetShield 很必要的原因。平常瀏覽網站時，偶爾會遇到一些奇奇怪怪的網站，頁面裡可能塞滿廣告、追蹤器，甚至導向可疑的下載連結。Proton VPN 會先在 DNS 層級擋掉部分已知的廣告、追蹤與惡意網域，讓這些內容沒有機會正常載入。當然，它不是萬能的防毒軟體，不能保證攔截所有木馬或病毒；遇到不熟悉的網站和自動下載的檔案，還是要保持警覺。

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

Proton VPN 總部設在瑞士，這不只是一個「聽起來很安全」的賣點，而是有實質法律意義的。

瑞士於 2023 年 9 月正式生效的全新《聯邦數據保護法》(nFADP) 確立了以下關鍵保護：

瑞士不屬於五眼、九眼、十四眼情報聯盟，情報機構無法互通資料
瑞士法律不將 VPN 列為電信業者，因此不適用強制數據保留法——Proton 在法律上被允許實施徹底的「無日誌政策」
禁言令（Gag Orders）在瑞士不存在：任何外國情報機構索取用戶資料，必須通過正式的 MLAT 國際司法協助程序，並由瑞士聯邦法院獨立審查
若請求涉及的事項在瑞士不構成犯罪，或違反瑞士憲法與人權標準，請求將直接被拒絕

相較之下，設立在巴拿馬（NordVPN）或英屬維京群島（ExpressVPN）的競爭者，雖然同樣聲稱無日誌，但其法律架構的透明度與可驗證性不及瑞士法律體系完整。

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

市面上幾乎每一家 VPN 都宣稱自己是「無日誌（No-Logs）」，但如何辨真假？以下是三個硬核驗證指標：

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

Proton VPN 定期委託全球頂尖的資安機構（包括 Cure53 等）進行代碼審查與實地伺服器架構稽核，並公開發布完整審計報告，任何人皆可下載查閱。

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

再嚴謹的審計，都比不上執法機關實際索取資料失敗的真實案例：

Proton VPN 法庭紀錄：曾收到法庭命令要求提供特定用戶的資料，但因為無日誌架構，Proton 最終僅能回覆「無法提供，因為我們沒有這些資料」——這是最有說服力的隱私承諾。

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

Proton VPN 的客戶端程式碼全部開源發布在 GitHub，任何具備能力的開發者都可以自行審計其是否有隱藏的日誌收集行為。這一點是封閉原始碼的競爭對手（如 Surfshark、NordVPN 的部分元件）所做不到的。

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

如果你開始關注數位隱私，Proton VPN 只是第一步。Proton 還提供一整套替代主流科技巨頭的隱私產品：

Proton 產品	替代方案	核心優勢
Proton Mail	Gmail	端對端加密，Proton 本身也無法讀取你的郵件
Proton Drive	Google Drive	零知識加密，檔案在上傳前就已加密
Proton Pass	Chrome 密碼管理器	獨立加密金庫，整合 2FA 與別名生成
Proton Calendar	Google Calendar	端對端加密行事曆

購買 Proton Unlimited 套餐可一次解鎖所有服務，對於希望全面「去 Google 化」的用戶來說，性價比遠高於分別訂閱各項服務。

💰 Proton 方案台灣地區定價估算 (以 1 USD ≈ 31.9 TWD 換算)

目前 Proton 官方網站採美元、歐元與瑞士法郎結帳，台灣讀者可直接使用台灣信用卡刷卡扣款（下表為折合台幣的估算，不含海外刷卡手續費）：

Proton VPN Plus（單純 VPN 升級方案）

計費週期	月費（USD）	折合台幣（估算）
按月付費	$9.99 / 月	約 $319 TWD / 月
按年付費	$3.99 / 月	約 $127 TWD / 月（年結共約 $1,527 TWD）
兩年付費	$2.99 / 月	約 $95 TWD / 月（兩年結共約 $2,289 TWD）⭐ 最划算

Proton Unlimited（含 VPN Plus + Mail + Drive 500GB + Pass + Calendar）

計費週期	月費（USD）	折合台幣（估算）
按月付費	$12.99 / 月	約 $414 TWD / 月
按年付費	$9.99 / 月	約 $319 TWD / 月（年結共約 $3,824 TWD）
兩年付費	$7.99 / 月	約 $255 TWD / 月（兩年結共約 $6,117 TWD）

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

✅ 選免費版，如果你：

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

✅ 選 Plus 付費版，如果你：

需要解鎖 Netflix、Disney+、YouTube Premium 等地區限制內容
需要 P2P / BT 下載高速伺服器
在高審查地區（需要 Stealth 協定）
需要多裝置同時連線（最多 10 台）
重視最高等級的匿名性（Secure Core + NetShield）

✅ 選 Proton Unlimited，如果你：

想全面從 Google / Microsoft 生態系遷移到隱私優先的替代品
是自由工作者、律師、獨立記者，需要保護客戶機密資料的專業人士
需要一個涵蓋郵件、雲端、密碼管理的一站式隱私解決方案

總結

Proton VPN 免費版是市場上極少數真正安全、不限流量的免費選擇，適合輕度用戶入門
速度差異顯著：付費版可達 950–1,500+ Mbps，是免費版的 6–10 倍；延遲也從 20–200ms 降至 5–30ms
付費版的核心升級點是：串流解鎖、P2P 支援、NetShield 廣告攔截、Stealth 混淆協定與 Secure Core
瑞士法律管轄、開源程式碼與法庭實證紀錄是 Proton VPN 在安全信任度上的真正護城河
若有全面隱私需求，Proton Unlimited 提供一站式的 Google 替代方案，每月僅需 $255 TWD（兩年方案）

準備好保護你的數位隱私了嗎？點擊下方連結免費申請 Proton 帳號，體驗看看——不需要信用卡，隨時可以升級。

👉 免費申請 Proton 帳號 →

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

2026-07-31T03:17:00Z

沒有一杯咖啡解決不了的 CSS，如果有，就交給 AI 吧——然後你發現 AI 把整頁都 position: absolute 了，跑版跑到懷疑人生，只好再來一杯。

你是不是也遇過：打開 Cursor 或 Claude，丟一句「幫我做響應式產品頁」，幾秒鐘就吐出一堆看起來很漂亮的 CSS。你心裡想：太好了，以後不用學了。結果換個螢幕寬度，版面像被貓踩過一樣。

結論先講：要學。但學法跟以前完全不一樣。 你現在的任務不是背語法，是當 AI 的「版面審查員」——它負責產碼，你負責把關，別讓它把 PageSpeed 分數和 SEO 一起帶去陪葬。

你不再是「寫 CSS 的人」，是「審 CSS 的人」

以前學 CSS，很大一塊時間花在背屬性——align-content 有幾個值、flex-shrink 預設是多少。老實說，現在 Google 一下就好，死背這些就像記咖啡機型號：知道有這台就好，不必背到能朗誦說明書。

真正值錢的，是你能不能一眼看出 AI 寫的版面哪裡怪怪的，然後用一句話把它拉回正軌。不然你就會陷入那種經典循環：跟 AI 來回對話十輪，Bug 還在，咖啡倒是喝了三杯。

AI 是乘數：底子越厚，它幫你越猛

Josh Comeau 和 Kevin Powell 這類前端大師都說，我們正在進入「後開發者時代」。AI 跟你的關係比較像乘數，不是替身：

底子薄 (1) × AI (10) = 10：MVP 很快做出來，但 Bug 一來就卡死，成品也上不了檯面。
底子厚 (10) × AI (10) = 100：繁瑣 code 交給 AI，你用真的懂的東西（效能、a11y、可維護性）把關。

白話說：AI 會放大你的能力，也會放大你的盲點。底子不夠，它幫你「快」；底子夠，它幫你「又快又好」。

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

AI 能寫 code，但它沒有眼睛，也沒有「這樣排版合理嗎」的直覺。所以它常給你看起來對、實際很慘的解法——像自動咖啡機偶爾會出現一杯看起來是拿鐵、喝起來是苦水的東西：

亂用 position: absolute：對不齊就硬拉，換個螢幕寬度整頁跑版。經典 AI 起手式。
還在堆 @media 斷點：訓練資料裡舊 code 太多，很少主動用 clamp() 或 Container Queries。
z-index: 9999 加到手酸還是沒用：不懂層疊上下文，你就只能跟 AI 無限對話，永遠修不好。這時候再來一杯咖啡也沒用，得先搞懂概念。

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

概念	AI 常犯的錯	你要會的
正常流 (Flow)	版面一亂就加定位硬撐	知道元素預設怎麼排、什麼時候才該脫離流
佈局選型	簡單橫排用 Grid、二維版面用 Flex	1D 用 Flex、2D 用 Grid——選錯工具後面全慘
Intrinsic Sizing	直接 `width: 300px` 寫死	讓內容決定大小，別讓 AI 把寬高焊死
設計系統 (Tokens)	到處 `#3b82f6` 這種 hardcode	逼它用 `--color-primary` 這類變數

CSS 跟 SEO 其實綁在一起（Google 也在看）

很多人以為 CSS 只影響長相。錯。在 2026 年，它直接碰 Core Web Vitals (CWV)——Google 拿來衡量體驗的分數，跟排名也有關係。版面再漂亮，分數掉光，搜尋流量也會跟著掉，這比咖啡涼掉還難受。

AI 亂寫的 CSS，很容易搞出這些問題：

CLS（版面位移）：圖片沒尺寸、內容突然插入，頁面會跳來跳去。你要自己檢查有沒有用 aspect-ratio，或預留空間。
INP（互動延遲）：動畫用 width 會觸發重排，卡卡的。引導它改用 transform，分數通常好看很多。

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

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

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

階段 1：先把心智模型建起來——拿 AI 生成的卡片，把裡面所有 absolute 拔掉，改用 Flex 對齊。你會很快發現「流」是什麼感覺。
階段 2：Flex + Grid 分工——外層 12 欄用 Grid，內層元件用 Flex。練習下指令：「1D 用 Flex、2D 用 Grid，並說明為什麼。」
階段 3：元件級響應式——少靠全局 @media，多學 Container Queries。可以要求 AI：「父層設 container-type，不要只靠斷點。」
階段 4：效能實戰——把 AI 產出的 code 丟進 PageSpeed Insights，看 LCP、CLS 掉在哪。順便學 content-visibility 怎麼救長頁面。

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

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

請為我實作一個響應式文章卡片元件：
1. **佈局**：使用語意化 HTML5；圖片在上、標題在下、按鈕靠底對齊（使用 Flex + margin-top: auto）。
2. **設計系統**：嚴格使用 var(--color-primary-600) 與 var(--spacing-md)，禁止使用 Hardcode 色碼。
3. **響應式**：使用 Container Queries。當寬度小於 280px 時，切換為緊湊模式。
4. **效能**：hover 效果僅限 transform 與 box-shadow，確保動畫流暢。
5. **a11y**：確保 focus 狀態可見，且文字對比符合 WCAG AA 標準。
6. **要求**：請先解釋你選擇佈局模式的理由，再提供 CSS 代碼。

重點不是 prompt 很長，而是把決策權留給你——先讓它解釋為什麼這樣排，你再決定要不要採用。AI 是外骨骼，腦袋還是你的。

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

「會寫 CSS」這件事本身，價值正在變薄。真正有差的是：你能不能交付一個能上線、好維護、分數也好看的成品。

最後一句送給你：沒有一杯咖啡解決不了的 CSS，如果有，就交給 AI——但記得，審完再來一杯。

Pi Coding Agent 完整指南：極簡終端 AI 程式助手入門與實戰工作流

2026-07-28T08:20:00Z

你是不是也遇過這種情況：開了某個 AI 程式助手，它硬要你走「先規劃 → 再開子代理 → 再審查」的流程，結果改一個小 bug 也要等它跑完一整串儀式？

市面上很多 Coding Agent 越來越像「整套 IDE 替代品」，而不是「幫你省時間的夥伴」。如果你想要的是：極簡、快、能嵌進自己習慣的終端工作流，那值得認識 Pi Coding Agent（pi.dev）。

這篇會帶你從「它是什麼」一路走到「怎麼裝、怎麼設定、怎麼跟 Cursor 分工」——讀完你可以決定要不要試，以及該用哪種工作流模式。

什麼是 Pi Coding Agent？

Pi Coding Agent 是跑在終端機（Terminal）裡的 AI 程式開發助手，由 Earendil Inc. 維護。它的設計哲學可以濃縮成一句話：

世界上有很多 Agent 框架，但這一個是你的——工具來適應你，不是你來適應工具。

跟 Devin、重度多代理編排系統不同，Pi 走的是 「極簡核心 + 按需擴充」：

Devin 是 Cognition 推出的自主 AI 軟體工程師（devin.ai）：接到任務後會自行拆解步驟、讀 repo、寫 code、跑測試、開 PR，人類多半只需審核結果。這類「大而全」的 agent 平台內建規劃模式與子代理編排，能獨立完成整個 feature，但工作流往往也由工具決定，而不是開發者自己拼裝。

核心只有四個工具：read、write、edit、bash
不內建 sub-agent、Plan mode、全專案向量索引
能力靠你自己加：AGENTS.md、Skills、Extensions、Pi Packages

白話說：你在專案資料夾打 pi，就能用自然語言叫 AI 讀檔、改 code、跑測試；要不要加 MCP、子代理、網頁搜尋，全由你決定。

四層架構（看懂 Pi 在幹嘛）

層級	做什麼
CLI / TUI	終端互動、顯示 token 與狀態、高風險操作的人工確認
Agent 協調	ReAct 迴圈：想 → 做 → 看結果 → 再修正
工具與上下文	四工具 + Extension 注入的 RAG / MCP
持久化	Session 樹狀歷史、JSONL 日誌，可 fork、可匯出

把 AI 直接放在終端的好處很實際：不用再「複製錯誤訊息 → 貼到聊天窗 → 複製修復 code 回來」。Linter 報錯、測試失敗，Agent 可以直接讀輸出並迭代修正。

Pi vs Cursor vs Claude Code：該選誰？

Pi 不是 Cursor 的平替，而是不同取捨。下面這張表幫你 30 秒判斷：

維度	Pi Coding Agent	Claude Code	Cursor Agent
核心工具	4 個（read/write/edit/bash）	10+ 內建	IDE + MCP + 多模型
上下文來源	AGENTS.md + Extension 注入	CLAUDE.md + 選擇性讀檔	全專案向量索引 + `@`
Sub-agents	無（Package 自建）	內建 Task	Background Agent
Plan mode	無（Prompt Template 替代）	內建	Composer 規劃
RAG / 索引	社群 Extension（如 pi-local-rag）	grep + 讀檔	自動 codebase embedding
Session	樹狀分支 + compact	線性 + compact	多 chat tab
部署	CLI / RPC / SDK 嵌入	CLI only	Desktop IDE
Token 效率	極小 system prompt	中等	較高
最適合	終端實驗、SDK 嵌入、可版本控制的 Agent 設定	Anthropic 生態深度使用者	日常 IDE 多檔編輯

依場景選工具

你的情境	建議
大型 monorepo、要靠自動索引	Cursor / Claude Code
Side project、終端一把梭	Pi
本地模型、低 VRAM、要控 token	Pi
Agent 設定要進 Git（`AGENTS.md`、`.pi/`）	Pi
自建產品要嵌 Agent（SDK）	Pi
UI 調像素、邊預覽邊改	Cursor

實戰分工（很多人兩邊都裝）：主專案用 Cursor 改 UI、多檔 refactor；Pi 負責終端批次任務、長跑腳本、低成本實驗。同一目錄同一時間只讓一邊寫檔——並行時用 git worktree 隔離。

四種運作模式

Pi 不只有「開 TUI 聊天」：

模式	怎麼用	適合
Interactive（互動）	專案目錄執行 `pi`	日常對話、除錯、改 code
Print / JSON	`pi -p "分析此 repo"`、`--mode json`	腳本自動化、結構化事件流
RPC	stdin/stdout JSON 協議	非 Node 系統整合
SDK	嵌入自己的 TS 應用	自建 Agent 產品

互動模式裡還有兩個很多人愛用的即時控制：

Steering（Enter）：Agent 還在跑時，你可以立刻送新指令糾偏；目前工具執行完就切方向，不會傻等整條鏈跑完。
Follow-up（Alt + Enter）：排程下一則訊息，等當前任務完成後自動接上。

長對話別硬撐——用 /compact 壓縮舊訊息，或 /tree 開分支試另一條路，歷史都留在同一個 session 檔裡。

上下文工程：Pi 真正厲害的地方

AI 回得好不好，八成看上下文怎麼塞。Pi 的策略是：Harness 保持極簡，上下文全部可組合、可版本控制。

1. Context Files（`AGENTS.md` / `SYSTEM.md`）

Pi 啟動時會串接多層指令檔：

載入順序	路徑	用途
全域	`~/.pi/agent/AGENTS.md`	個人通用規範
父目錄	向上遞迴的 `AGENTS.md`	Monorepo 子專案繼承
當前目錄	`./AGENTS.md`	專案專屬規則

SYSTEM.md 可完全替換或追加預設 system prompt——適合鎖語言、安全邊界、角色人設。

實戰建議再配一份 APPEND_SYSTEM.md（放 ~/.pi/agent/）：跨專案行為，例如「先讀本地、危險操作先問、不確定就停下來問人」。它的權重通常高於專案 AGENTS.md。

範例（專案根 AGENTS.md）：

# Project Instructions
- 改 code 後跑 `npm run check`。
- 不要動 production 設定檔。
- 不確定時先問我。

2. Skills：按需載入的能力包

Skills 是 Markdown 檔，frontmatter 有 name 和 description。Pi 只在 system prompt 放摘要；Agent 要用 read 才載入全文——避免一次塞爆 context。

手動觸發：/skill:git-workflow。發現路徑：~/.pi/agent/skills/、.pi/skills/、.agents/skills/（專案 skills 需 trust 專案）。

3. Prompt Templates：可重用的 `/` 指令

帶參數的 Markdown 模板，例如 /review src/auth.ts 展開成完整審查 prompt。支援 $1、$ARGUMENTS 等替換。適合標準化 code review、部署 checklist。

4. Extensions：動態注入 RAG

TypeScript 模組可訂閱 context 事件，在每次 LLM 呼叫前改 message 陣列。社群 pi-local-rag 就是典型：本地 BM25 + 向量混合檢索，按 turn 注入相關 chunks，不動 system prompt，維持 KV-cache 效率。

Project Trust（安全邊界）

專案含 .pi/ 或 .agents/skills/ 時，Pi 會問你是否 trust。未信任前只載入 context files；信任後才載入專案 extensions——避免惡意 repo 配置執行任意程式碼。

為什麼 Pi 刻意不內建 MCP、子代理、Plan mode？

這不是「功能缺失」，是設計選擇：

刻意省略	為什麼	需要時怎麼辦
MCP	傳統整合可吃掉半個 context	`pi install npm:pi-mcp-adapter`
Sub-agents	避免核心膨脹、強制工作流	`pi install npm:pi-subagents`
Plan mode	不想 opinionated 規劃儀式	Prompt Template 或 `/plan` Extension
IDE 整合	專注終端 Harness	RPC / SDK 給外部嵌

官方態度很直白：Ask Pi to build it, or install a package.

套件安裝範例：

pi install npm:pi-mcp-adapter    # MCP 生態，~200 token 代理工具
pi install npm:pi-subagents      # scout → planner → worker 鏈
pi install npm:pi-web-access     # 網頁搜尋與抓取

套件選型：不要一開始裝滿排行榜

pi.dev/packages 已有 50+ 社群套件。最佳實務是 Tier 0 起步，痛點出現再加。

Tier	組合	適合
Tier 0	僅 `AGENTS.md`	小 patch、學習四工具
Tier 1	+ `pi-mcp-adapter` + `pi-subagents`	日常 feature、review 迴圈
Tier 2	+ `pi-web-access` / `pi-codex-goal` / `context-mode`	長任務、context 膨脹

pi-mcp-adapter：MCP 但不炸 context

傳統 MCP 可能一個 server 就 10k+ tokens。pi-mcp-adapter 用單一 mcp 代理工具（約 200 token）按需發現與呼叫：

mcp({ search: "screenshot" })
mcp({ describe: "chrome_devtools_take_screenshot" })
mcp({ tool: "chrome_devtools_take_screenshot", args: '{"format": "png"}' })

Server 預設 lazy 啟動（第一次呼叫才連線）。常用工具可設 directTools 升級為一級工具。

pi-subagents：子代理怎麼編排

內建 8 種角色：scout、researcher、planner、worker、reviewer、oracle 等。支援 單一、鏈式（chain）、並行（parallel） 三種模式。

實戰 prompt 範例：

Use scout to map the auth flow, then planner for an implementation plan.
Run parallel reviewers: correctness, tests, and unnecessary complexity.

注意：parallel 模式 token 成本會倍增；裝了套件也不會自動跑 reviewer——要在 prompt 或 AGENTS.md 裡明確要求。

五階段實戰工作流

Pi 沒有「唯一官方流程」，但下面這套在實戰中最穩：

Phase 0  設定層（一次性）
   AGENTS.md + APPEND_SYSTEM.md + 精選 packages
        ↓
Phase 1  任務釐清
   自然語言目標 → 大任務用 create_goal 或 planner
        ↓
Phase 2  探索（唯讀）
   scout / read+grep / web-access
        ↓
Phase 3  實作
   worker 或主 session 小步 edit
        ↓
Phase 4  驗證閉環
   bash 跑 test/lint → reviewer → 修正
        ↓
Phase 5  上下文維護
   /compact、/tree 分支、context-mode（長 session）

三個反模式請避開：

一開始裝滿熱門榜——context 與認知負擔暴增
長專案只靠對話記憶——應寫進 AGENTS.md、goal 檔或 plan.md
沒給驗證條件就「改到好」——一定要指定 test/lint 成功才算完

探索階段原則：計畫寫進檔案（plan.md、context.md），先讀本地，不足再 web，大改前先跟人確認。

安裝與第一次實戰（約 10 分鐘）

前置：Node.js ≥ 22.19.0。

# 方式 A：官方 npm（方便鎖版本）
npm install -g --ignore-scripts @earendil-works/pi-coding-agent

# 方式 B：macOS / Linux 一鍵腳本
curl -fsSL https://pi.dev/install.sh | sh

確認：

node -v    # ≥ 22.19.0
pi --help

登入模型（憑證存 ~/.pi/agent/auth.json）：

cd /path/to/your-sandbox-project   # 先用可弄髒的 side project
pi
/login

支援 Claude / ChatGPT / Copilot 訂閱 OAuth，或各廠 API Key。CI 可用環境變數，例如 export ANTHROPIC_API_KEY=...。

第一次驗證：

Summarize this repository and tell me how to run its checks.

進階試試：@README.md 附加檔案、!npm run lint 跑 shell、pi -p "Summarize" 非互動模式。

新手常見踩坑

狀況	怎麼修
`pi: command not found`	確認 npm global `bin` 在 PATH
沒 API key	在 Pi 內 `/login` 或設 env
AI 亂改重要檔	用 sandbox repo + `AGENTS.md` 限制
聊越久越糊	`/compact` 或 `/new`
想要 MCP 但沒有	`pi install npm:pi-mcp-adapter`

工具	適合誰	一句話
Pi Coding Agent	想控 context、終端 workflow、SDK 嵌入	極簡四工具 + 按需擴充，本文明星推薦
Cursor	日常 IDE 多檔編輯、UI 調整	索引與預覽強，跟 Pi 互補而非互斥
Claude Code	Anthropic 訂閱深度使用者	終端 Agent，內建功能較多、較 opinionated
pi-mcp-adapter	要用 MCP 又怕 context 爆炸	Pi 生態 MCP 首選
pi-subagents	需要 scout/reviewer 鏈	補 Pi 不內建子代理的缺口

結語：回歸極簡，但別回歸低效

Pi Coding Agent 重新定義了「AI 助手該怎麼存在於開發流程裡」——不試圖接管整個 IDE，而是當一個快、可配置、可版本控制的終端夥伴。

三個 takeaway：

極簡核心（四工具）換來 token 效率與完整上下文控制權
能力按需加（Packages / Skills / Extensions），不要一開始裝滿
跟 Cursor 分工：IDE 改 UI、Pi 跑終端批次與實驗——同一 worktree 別兩邊同時寫

若你厭倦了沉重、黑盒、硬塞工作流的 AI 工具，建議先用 sandbox 專案試一輪：到 pi.dev 安裝 → /login → 寫一份 AGENTS.md → 跑一個小任務驗證四工具閉環。覺得順了，再按需加 pi-mcp-adapter 與 pi-subagents。

PageSpeed Insights 與 Core Web Vitals 2026 完全指南

2026-07-07T02:00:00Z

網站速度不只影響使用者體驗，也與 Google 搜尋排名相關。要衡量與改善效能，PageSpeed Insights（PSI） 仍是最常用的免費工具——但 2024 年後 Core Web Vitals 已從 FID 改為 INP，很多人還在用舊觀念解讀分數。

本文整理 2026 年門檻、實地數據（CrUX）與實驗室數據（Lighthouse）的差異，以及 WordPress／靜態網站各自該優先處理什麼。若你只想先動手，可直接跳到「30 分鐘優化 Checklist」。

PageSpeed Insights 是什麼

PageSpeed Insights 是 Google 提供的免費網頁效能檢測工具，輸入網址即可取得：

實地數據（Field Data）：來自 Chrome User Experience Report（CrUX），反映真實使用者在過去 28 天內的體驗。
實驗室數據（Lab Data）：由 Lighthouse 在模擬環境中跑分，適合診斷「為什麼慢」，但不等於搜尋排名依據。

重點：Google 評估 Core Web Vitals 是否達標，看的是 實地數據第 75 百分位數（p75），不是 Lighthouse 分數。Lighthouse 90 分但 CrUX 顯示「需要改善」的情況很常見。

Core Web Vitals 2026：三項指標與門檻

2024 年 3 月起，INP（Interaction to Next Paint） 正式取代 FID，成為互動性指標。目前三項 Core Web Vitals 如下：

指標	衡量面向	良好（Good）	需要改善	不佳（Poor）
LCP 最大內容繪製	載入速度	≤ 2.5 秒	2.5–4.0 秒	> 4.0 秒
INP 互動至下次繪製	互動回應	≤ 200 毫秒	200–500 毫秒	> 500 毫秒
CLS 累積版面位移	視覺穩定	≤ 0.1	0.1–0.25	> 0.25

要通過 Core Web Vitals 評估，三項指標必須同時在「良好」門檻內（p75）。任一項落在「需要改善」或「不佳」，整體即視為未通過。

LCP：最大內容繪製

LCP 測量頁面主要內容（通常是 hero 圖、大標題或主要文字區塊）出現在螢幕上的時間。

常見拖慢原因：

伺服器回應慢（TTFB 過高）
未壓縮或未預載的大圖
阻塞渲染的 CSS / JavaScript
字型載入延遲

PSI 近年提供 LCP 子項目診斷（TTFB、資源載入延遲、元素渲染延遲），可快速判斷瓶頸在伺服器還是前端。

INP：取代 FID 的互動指標

舊版 FID 只量測「第一次」互動的延遲；INP 則看頁面上所有互動中最慢的一次，更能反映整體操作流暢度。

常見拖慢原因：

過多或過大的 JavaScript（長任務 > 50ms）
第三方腳本（廣告、追蹤、聊天外掛）
主執行緒被同步運算佔用

診斷建議：用 Chrome DevTools → Performance 錄製，在手機模擬模式下點擊選單、按鈕、表單，找出最慢的互動。

CLS：累積版面位移

CLS 衡量版面在載入過程中「意外跳動」的程度，例如廣告插入、圖片沒預留高度、字型切換（FOIT/FOUT）。

修正方向：

圖片與影片設定 width / height 或 aspect-ratio
廣告與嵌入內容預留固定空間
使用 font-display: swap 並搭配相近的 fallback 字型

實地數據 vs Lighthouse：該信哪個

	實地數據（CrUX）	實驗室數據（Lighthouse）
資料來源	真實 Chrome 使用者	模擬裝置與網路
用途	判斷是否達 CWV 門檻	找出具體優化項目
更新頻率	約 28 天滾動窗口	每次重新分析即時
新站 / 低流量站	可能顯示「沒有足夠資料」	仍可取得分數

實務流程：

先看 Search Console →「體驗」→ Core Web Vitals 報表（整站概況）。
對問題 URL 跑 PSI，確認實地數據哪一項未達標。
往下捲看 Lighthouse「診斷」與「建議」，逐項修復。
部署後等待 CrUX 更新（通常需數週）再驗證。

30 分鐘優化 Checklist

依影響力由高到低排列，適合多數內容型網站：

伺服器與快取（優先）

[ ] 啟用 HTTPS 與 HTTP/2 / HTTP/3
[ ] 使用 CDN 或邊緣快取
[ ] WordPress 站：啟用全頁快取（LiteSpeed Cache、WP Rocket 或主機內建快取）
[ ] 靜態站：確認託管商有邊緣快取（如 Cloudflare、Netlify）

圖片與字型

[ ] 轉換為 WebP / AVIF，並設定適當尺寸
[ ] 對 LCP 圖片使用 <link rel="preload">
[ ] 字型子集化，避免載入整個字型家族

JavaScript 與 CSS

[ ] 延遲載入非關鍵 JS（defer / async）
[ ] 移除未使用的 CSS 與外掛腳本
[ ] 審查第三方腳本（GA、廣告、社群外掛）

版面穩定

[ ] 所有媒體元素預留尺寸
[ ] 避免在首屏上方動態插入橫幅

WordPress 站的常見路徑

若你使用 WordPress，效能優化通常分三層：

主機：優先選支援 HTTP/2／HTTP/3、物件快取，或 LiteSpeed／同等高效 Web Server 的方案。
快取外掛：全頁快取、圖片 WebP／延遲載入、CSS／JS 延遲；Guest Mode 類功能可加速未登入訪客。
內容：精簡外掛、媒體庫定期清理「尚無關聯」圖檔（先備份）、避免首屏塞過多第三方腳本。

若考慮脫離 WordPress 的維護成本，可參考 WordPress vs Eleventy 的遷移經驗——靜態站天生在 LCP 與 INP 上有結構優勢。遷移內容時可用 eleventy-import（或先從 WP 匯出 WXR 再轉換）。

轉址與重複內容（簡記）

改版或刪文後，用主機 Redirects／.htaccess 做 301，避免 404 流失權重。
多篇搶同一關鍵字時，合併成一篇支柱文並把舊 URL 301 過來，比硬留薄文更有效。

工具對照表

工具	類型	適合用途
PageSpeed Insights	實地 + 實驗室	單頁快速檢測
Google Search Console	實地（整站）	監控通過率與問題 URL
Chrome DevTools → Performance	實驗室	深入追蹤 INP / 長任務
web-vitals JS 函式庫	自訂 RUM	送 GA4 做長期監控

常見迷思

Q：Lighthouse 滿分就代表 SEO 沒問題？
A：不一定。Lighthouse 是實驗室環境；排名相關的是 CrUX 實地數據。兩者都要看。

Q：FID 還會出現在 PSI 嗎？
A：部分舊報表或診斷可能仍提及 FID，但 Core Web Vitals 評估已改用 INP。優化時以 INP 為準。

Q：新站沒有 CrUX 資料怎麼辦？
A：先用 Lighthouse 修到合理分數，上線累積流量後再依 Search Console 調整。流量極低的頁面可能長期沒有實地數據，這是正常現象。

Q：改完多久才會在 PSI 看到改善？
A：Lighthouse 即時反映；CrUX 實地數據通常需數週才會更新。

結語

2026 年解讀 PageSpeed Insights 的關鍵字是：實地數據優先、INP 取代 FID、三項同時達標。先把 LCP 與伺服器/快取处理好，再處理 JavaScript 對 INP 的影響，最後補 CLS 的版面預留——這個順序在多數部落格與內容站上最省時間。

若你的 WordPress 站 LCP 長期卡在「需要改善」，先從主機快取與圖片著手；若已考慮遷移靜態站，本站 11ty 入門教學可作為下一步參考。

把文章從 WordPress 搬出來：eleventy-import 的匯出方式

2025-12-15T10:00:00Z

eleventy-import，終於可以把 WordPress 資料好好搬出來

11ty 的作者真的很懂這個痛點，直接自己寫了一個官方匯入工具：eleventy-import。

在真正遇到它之前，我其實也走過不少冤枉路。

一開始的想法很直覺：

👉 用 WordPress 外掛把文章匯出成 Markdown，再慢慢整理。

問題是——事情完全沒那麼單純。

為什麼一般 WordPress 匯出方式這麼痛苦？

之前試過幾個 WordPress 匯出外掛，產生出來的檔案大多有這些問題：

夾雜大量 WordPress 專用標籤
各種外掛留下來的 短代碼（shortcode）
XML / HTML 混在一起，格式不統一
有的圖片是外掛語法，還有各種奇怪的包法

最麻煩的是：

👉 這些雜物沒有固定格式，根本沒辦法用一支 script 全部清乾淨

每篇文章都像在開盲盒，例外狀況多到讓人直接放棄。

於是這件事就這樣被擱著了。

官方出手：11ty 的 WordPress 轉移教學

直到有一天，在 11ty 官網亂逛時，看到這一頁：

👉 https://www.11ty.dev/docs/migrate/wordpress/

不只寫了完整教學，作者本人還拍了一支影片，標題是「Escape From WordPress」，整個就是用意非常明顯 😂

影片在這裡：

https://www.youtube.com/watch?v=WuH5QYCdh6w

看到這裡才發現：

👉 原來 11ty 早就把「從 WordPress 逃離」這件事想好了。

使用 eleventy-import 匯出 WordPress 文章

直接執行一行指令

使用方式非常暴力，也非常爽快：

npx @11ty/import wordpress https://your-site.com/

或者如果習慣 pnpm

pnpm dlx @11ty/import wordpress https://your-site.com/

第一次看到這行指令的反應是：

不是吧？就這樣？

沒了？

結果真的就 完成了，YA。

匯出後的目錄結構

eleventy-import 會直接幫你輸出成 11ty 最愛的格式：

your_project/
  assets/
    image1
    image2

  article1.md
  article2.md

幾個我覺得「非常關鍵」的點：

每一篇文章都是 乾淨的 Markdown
所有圖片自動整理進 assets/ 目錄
文章內的圖片連結也已經幫你改好
幾乎沒有 WordPress 遺毒

一句話總結：

👉 這個輸出結果，完全就是為了「直接丟進 11ty」而設計的。

下一步：選擇 11ty Starter

文章資料已經乾乾淨淨了，接下來就是選一個起始專案。

eleventy-base-blog

GitHub：

eleventy-base

優點：

官方範例，結構清楚
幾乎沒有多餘抽象
非常適合「想自己慢慢加功能」的人
好改、不綁架設計

缺點：

功能極簡
SEO、樣式、搜尋、圖片優化都要自己補
一開始看起來有點「什麼都沒有」

eleventy-excellent

網站：

eleventy-excellent

優點：

幾乎什麼都幫你準備好了
包含 SEO、圖片處理、效能最佳化
設計完成度高，很快就能上線

缺點：

設計與架構選擇比較多是「作者的想法」
想大改時，需要先理解一整套設計哲學
對我來說，反而有點太滿了

最後選擇

一開始其實是用 eleventy-excellent，因為真的很省事。

但實際調整一陣子後發現：

👉 一定會有一些地方「不是自己想要的方式」

而要改動那些地方，反而得先拆作者原本的設計。

最後決定回頭選擇 eleventy-base-blog：

從最簡單的開始，

需要什麼，再一個一個加。

啟動 11ty，驗收成果

把剛剛匯出的文章與 assets 目錄，放進：

content/blog/

然後啟動專案：

pnpm run start

打開瀏覽器，直接進：

http://localhost:8080/文章名稱/

你會看到一件很神奇的事：

文章內容完整
圖片全部正常
但樣式幾乎全沒了

這一刻這是感動萬分！。

因為這代表：

👉 資料真的已經完全脫離 WordPress 了。

若你還在 WordPress 端，也可先用後台「工具 → 匯出」產生 WXR，再轉成 Markdown；本站實務路線是直接用 eleventy-import 一次帶走文章與圖片。

從這一刻起，是全新的開始

這樣的網站：

快到不行，幾乎是秒開
什麼功能都沒有
但結構乾淨、可控、沒有包袱

這就是取捨啊。

WordPress 的功能真的很方便，

但當你選擇 11ty，簡單也不是壞事。

用效能、掌控感，交換即插即用的便利性。

接下來，才是真正有趣的地方。我想要網站愈來愈有趣，而不是愈來愈失去興趣。

WordPress vs Eleventy：我為什麼把部落格遷到 11ty

2025-12-08T10:00:00Z

WordPress 作為全球最受歡迎的內容管理系統，已經幫助數百萬人建立了自己的網站。然而，近年來靜態網站生成器如 11ty 也逐漸受到開發者和內容創作者的青睞。這兩種工具各有優缺點，選擇哪一個取決於你的需求、技術背景和維護意願。

本文將比較 WordPress 與 11ty，從多個面向分析兩者的差異，幫助你做出最適合的選擇。

基本概念與定位

WordPress：成熟的全功能 CMS

WordPress 是一個功能完整的內容管理系統，提供完整的後端管理介面、資料庫儲存、動態內容生成等功能。它最初設計為部落格平台，但現在已經演變成一個全功能的 CMS，可以建立任何類型的網站。

11ty：現代化的靜態網站生成器

11ty（Eleventy）是一個以 JavaScript 為基礎的靜態網站生成器。它不依賴資料庫，而是將內容檔案轉換為靜態 HTML 檔案，在建置時生成完整網站。

主要差異比較

技術架構

WordPress 的動態架構

資料庫驅動：所有內容都儲存在 MySQL/PostgreSQL 等資料庫中
動態生成：每次頁面請求時，PHP 會從資料庫提取資料並動態生成 HTML
依賴關係：需要 PHP 運行環境、資料庫伺服器、Web 伺服器（如 Apache/Nginx）

11ty 的靜態架構

檔案驅動：內容以 Markdown、HTML 等檔案格式儲存
預先建置：在開發階段就生成所有靜態檔案
獨立部署：只需要靜態檔案伺服器，無需資料庫或特定運行環境

開發體驗

WordPress：視覺化編輯優先

優點：

所見即所得編輯器：古騰堡編輯器讓非技術人員也能輕鬆編輯內容
即時預覽：修改後立即在前端看到效果
外掛生態：有數萬個外掛可以快速增加功能

缺點：

學習曲線：雖然編輯簡單，但要客製化主題仍需學習 PHP、WordPress Hook 等
外掛相容性：不同外掛間可能衝突，需要花時間測試和調試

(現代 PHP 和 WordPress 也改善很多開發流程和工具了) 參考：如何使用 Herd 在本機架設 WordPress 網站

11ty：程式化開發體驗

優點：

版本控制友好：所有內容和設定都以檔案形式存在，可以用 Git 完整管理
完全客製化：從頭到尾控制每一個細節
現代開發工具鏈：可以使用 npm scripts、現代 CSS 框架、模組化 JavaScript

缺點：

學習門檻：需要基本程式設計知識
建置步驟：每次修改都需要重新建置才能看到效果

效能表現

WordPress：需要持續優化

初始載入：動態生成內容導致首次載入較慢
快取需求：需要安裝快取外掛（如 WP Rocket、LiteSpeed Cache）來改善效能
伺服器負載：高流量時需要更多伺服器資源

11ty：天生高效能

極快載入：純靜態檔案，CDN 快取效果極佳
低伺服器成本：可以使用免費的靜態託管服務
無資料庫查詢：沒有資料庫延遲問題

在相同的機器規格上，11ty會消耗較少資源，也不需要資料庫的建置，但你也可以購買專用主機，直接提升效能。

安全性考量

WordPress：常見攻擊目標

風險點：

外掛漏洞：許多安全性問題來自過時或有漏洞的外掛
PHP 環境：動態執行的本質帶來更多攻擊面
資料庫安全：需要保護資料庫免於攻擊

優點：

活躍社群：有大量安全性外掛和監控工具
定期更新：核心系統和外掛都會定期修補漏洞

11ty：本質安全

優點：

最小攻擊面：沒有資料庫、沒有動態執行，極難被入侵
內容驗證：建置時可以驗證所有內容和程式碼
相依性控制：可以精確控制所有第三方程式庫

考量點：

建置安全：需要保護建置過程和部署金鑰
第三方服務：如果整合外部服務（如表單、評論），需要注意這些服務的安全性

11ty 的好處是沒有後台登入功能，會被破解的地方就是主機本身，如果主機使用不夠安全，用什麼架構都一樣不安全。

維護成本與複雜度

WordPress：持續維護需求高

定期任務：

軟體更新：核心、主題、外掛都需要定期更新
安全性修補：監控並修補已知漏洞
效能優化：定期檢查和優化網站速度
備份管理：資料庫和檔案的備份策略

雖然都很簡單的定期更新，就是很繁雜，但外掛版本和 WordPress 版本和 PHP 版本之間的相容性需要考量。

11ty：一次性設定，長期穩定

維護內容：

內容更新：只需要編輯 Markdown 檔案
相依性更新：偶爾更新 npm 套件
重新部署：修改後重新建置和部署

內容管理與協作

WordPress：多人協作友好

角色權限系統：支援不同層級的使用者權限
即時協作：多個編輯者可以同時工作
審核流程：支援草稿、審核、發布流程

以我個人的情境來說（主要是一人維護與發文），WordPress 的角色權限與協作流程屬於「用得到很強，用不到就比較像是額外的系統功能」。相對地，我更在意的是內容變更是否能被精準追蹤與回溯。

而且你也很難追蹤另一個 WordPress 使用者動了什麼東西，改了什麼設定。

11ty：開發者導向協作

Git 工作流程：任何微小變動都清清楚楚，輕易追蹤管理版本。
內容即程式碼：內容和程式碼使用相同工具管理
版本歷史：完整的內容修改歷史記錄

適合的使用情境

選擇 WordPress 的情境

非技術使用者：如果你不熟悉程式設計，但需要快速建立網站
複雜功能需求：需要會員系統、電子商務、複雜表單等動態功能
多人協作內容：有多個內容編輯者，需要完善的權限管理
預算有限：不想花時間學習技術，希望快速上線
經常變更內容：網站內容需要頻繁更新，希望即時生效

選擇 11ty 的情境

技術背景使用者：熟悉 HTML、CSS、JavaScript，有程式設計基礎
效能至上：對網站載入速度有極高要求
安全性重視：希望最小化安全風險
長期維護考量：希望降低長期維護成本
個人/小型專案：部落格、作品集、文件網站等
版本控制需求：需要完整的內容版本歷史和協作流程

這些只是比較適合的點，並不代表這個功能一定得用某個技術才行。

實際案例分析

WordPress 適合案例

新聞網站：需要頻繁更新內容、多個編輯者協作
企業網站：需要 CMS 整合、聯絡表單、會員系統
電子商務：需要購物車、付款閘道、庫存管理
社群平台：需要用戶生成內容、評論系統

11ty 適合案例

個人部落格：內容創作者專注於寫作而非維護
產品文件：技術文件、API 文件等需要版本控制
作品集網站：設計師、開發者的個人展示網站
公司官網：簡單的企業介紹頁面，重視品牌形象

事實上 11ty 能做的事，WordPress 都做得到，但選擇 11ty 通常不是太功能上的選擇，很多是想在技術上架構上簡單透明一點。

遷移與轉換考量

從 WordPress 遷移到 11ty

優點：

大幅改善效能和安全性
降低託管成本
獲得更多控制權

挑戰：

需要將動態功能改為靜態或外部服務
失去所見即所得編輯體驗
需要學習新的工作流程

從 11ty 遷移到 WordPress

優點：

快速增加複雜功能
降低內容編輯門檻
支援更多非技術使用者

挑戰：

效能下降
維護複雜度增加
安全性風險提高

結論：沒有絕對的「最好」

WordPress 和 11ty 代表兩種不同的網站建置哲學：

WordPress 強調易用性和功能完整性，適合需要快速上線、複雜功能、或多人協作的專案
11ty 強調效能、安全性和開發體驗，適合技術背景的使用者和重視長期維護的專案

最終的選擇應該基於：

你的技術能力：熟悉程式設計嗎？
專案需求：需要哪些功能？預算多少？
維護意願：願意投入多少時間在網站維護上？
成長規劃：網站未來可能如何演變？

建議你可以先評估自己的需求，必要時甚至可以考慮混合使用兩者。例如，使用 11ty 建立主要內容網站，WordPress 作為後台內容管理系統。

無論選擇哪一個工具，重點是找到最適合自己工作流程和需求的解決方案。技術工具應該服務於內容創作，而不是成為創作的障礙。

WordPress 看很多了，來看看幾個 11ty 的網站

https://chrisburnell.com/
https://www.zachleat.com/
https://eleventy-excellent.netlify.app/

相關資源：

光輝咖碼

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

目錄

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

三種字型策略怎麼選？

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

子集化到底在做什麼？

自架子集化的實作流程

1. 保留 Latin 與站內實際 CJK 字元

2. 用工具產出 WOFF2

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

4. 把它接進 build 流程

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

常見錯誤與取捨

推薦工具／資源

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

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

目錄

先抓到你真正的 LCP 元素

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

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

1. 不要 lazy-load LCP

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

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

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

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

框架快速對照

推薦工具／資源

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

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

目錄

為什麼 GTM 會拖慢 PSI？

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

可直接複製的最小版本

timeout 要設多少？

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

延遲前先做的兩件事

先精簡 GTM container

高階方案再考慮 Worker

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

推薦工具／資源

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

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

目錄

先搞清楚：圖片最常造成兩種效能問題

決策表一：width+height 還是 aspect-ratio？

可複製：一般內文／hero

可複製：固定比例截圖容器

常見錯誤（預留會失效）

決策表二：檔案大小、顯示寬、WebP／AVIF

站內檔案預算（實務目標，非官方硬門檻）

格式怎麼選

最小可用：srcset + sizes

決策表三：手動補寬高，還是上 Eleventy 圖片管道？

推薦工具／資源

結語：圖片最佳化，就是別讓 CLS 亂跳、也別拖慢下載

Proton VPN 值得買嗎？免費版實測 + 付費版完整功能深度解析

目錄

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

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

免費版的三個主要限制

免費版 vs 付費版速度實測數據

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

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

1. Secure Core：雙重跳板防禦

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

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

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

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

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

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

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

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

💰 Proton 方案台灣地區定價估算 (以 1 USD ≈ 31.9 TWD 換算)

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

推薦資源

推薦回饋怎麼算？

總結

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

目錄

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

1. Context Files（`AGENTS.md` / `SYSTEM.md`）

3. Prompt Templates：可重用的 `/` 指令