網頁字體 Webfont 指南：中文字型選擇與載入優化

重點摘述

• 網頁字體（webfont）是透過 @font-face 把字型檔下載到瀏覽器再渲染的技術，它讓你脫離系統預設字、做出真正的品牌質感。
• 中文字型要涵蓋的字形通常比拉丁字型多，完整字型檔可能明顯較大；實際大小會受字形範圍、格式、字重與子集化方式影響。
• 想同時顧質感與速度，主要方向是：選對字、做子集化（subsetting）、用對 font-display 與載入策略。

設計師交出一版美到不行的視覺稿，字體優雅、字距精準，客戶一看就買單。結果網站上線，手機打開來，畫面空白了一段時間才蹦出文字，接著字型又「啪」地閃一下換成正式字體。訪客心裡只剩一個念頭：這網站是不是壞了。

字體是網站效能優化時常被低估的變數之一。它不像圖片那樣顯眼，卻可能延後最大內容繪製（Largest Contentful Paint, LCP），或在替換字型時造成版面位移（Cumulative Layout Shift, CLS）。目前的 Core Web Vitals 是 LCP、互動至下一次繪製（Interaction to Next Paint, INP）與 CLS；INP 已在 2024 年 3 月取代 FID，指標組合的演進見 web.dev 的 Core Web Vitals 說明。

這篇會把網頁字體從底層運作、中文字型的特殊難題、載入優化到資源挑選一次講清楚。不管你是自己架站的創業者、接案設計師，還是顧 SEO 的行銷人，看完都能動手把字體效能拉起來。如果你之前完全沒碰過 CSS，可以先把CSS 入門全攻略看過一遍，回來會更順。

先給一個觀念定位，這篇不是教你「怎麼把字型弄漂亮」，漂亮是設計師的事。這裡要談的是在質感和速度之間找到平衡點的工程判斷。每一個掛上去的 webfont 都是一筆效能負債，你的任務是讓這筆負債付出最小代價、換回最大價值。很多團隊之所以字體出問題，不是不懂技術，而是從來沒把字體當成效能變數來管理。設計師只管好不好看、工程師只管能不能跑、行銷只管排不排得上，沒有人對「字體下載成本」負責。結果就是一個頁面默默掛了多套完整字型，LCP 悲劇卻沒人發現。希望你看完這篇，能成為團隊裡那個把字體帳算清楚的人。

Webfont 是什麼：和系統字到底差在哪

所謂的 webfont，不是某一種字型品牌，而是一種把字型檔當成網頁資源下載的技術。用 CSS 的 @font-face 宣告字型名稱、檔案位置、格式，瀏覽器遇到用到這個字型的文字時，就會去把檔案抓下來渲染。

未載入網頁字型時，瀏覽器會依 font-family 清單、已安裝字型與通用字族選擇可用字形。不同平台的結果可能不同；新細明體、標楷體、蘋方或微軟正黑體是否存在，以及讀起來是否清楚，都要依目標環境測試。

webfont 解決的就是這件事：只要瀏覽器支援而且字型檔成功載入，網站就能減少不同系統預設字型造成的差異。仍要準備合適的 fallback，因為網路、瀏覽器設定或字型服務異常時，正式字型不一定能載入。Google Fonts 是常見的免費開源字型庫之一。

但代價很明確：要下載字型檔。下載就要時間、要頻寬，也會和其他關鍵資源競爭下載優先順序。中文字型通常涵蓋更多字形，因此這個代價往往比拉丁字型明顯。接下來這段就是關鍵。

網頁字型格式：優先評估 WOFF2，依環境提供備援

談到 webfont，很多人只知道「要一個檔案」，但檔案格式本身會直接影響壓縮率和下載速度。市面上有四種常見格式，每一種的壓縮技術和瀏覽器支援度都不同。

這張表為什麼特別把 WOFF2 標出來？因為它使用 Brotli 壓縮，通常能比 WOFF 進一步縮小檔案。實際節省幅度取決於字型的輪廓、字形數量、hinting、可變軸與子集化方式，不能直接用固定比例推算 LCP。

WOFF2 已廣泛支援於現代瀏覽器。仍有舊環境需求時，依訪客資料與專案支援範圍確認，必要時在 src 提供 WOFF2 和 WOFF 候選，讓瀏覽器選擇可用來源：

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

一般現代網站可優先使用 WOFF2，但其他格式是否需要保留取決於相容性與授權。src 列出多個備援格式，不代表瀏覽器會把所有候選都下載；要以實際請求判斷成本。

中文字型為什麼是效能殺手

只含基本拉丁字母與符號的子集，通常需要較少字形。教育部《常用國字標準字體表》收錄 4,808 字，可看出中文內容的覆蓋需求；實際網站還可能使用人名、異體字、標點與其他語文，字型檔大小須依涵蓋範圍與字形資料量檢查。

完整繁體中文字型即使轉成 WOFF2，仍可能比拉丁字型子集大很多。叫訪客的手機下載一整套字型，只為了把少量標題字從系統字換成品牌字，往往不划算；實際檔案大小應直接檢查所選字型與字重。

而且中文的問題還不只檔案大。內容持續更新的網站不一定能預先知道每一頁會用到哪些字，固定子集太小可能頻繁 fallback，直接載完整字集又可能傳送大量頁面沒用到的字形資料。

下載字型會增加資源需求，但系統字也能有合適的視覺與閱讀品質。先決定字型在頁面中的用途，再比較子集、字重、備用字與載入策略，不必把質感和速度當成只能二選一。

CJK Unicode 區塊：子集化必備的技術地圖

要精準地把中文字型子集化，需要了解 CJK（中日韓）字元在 Unicode 裡的分布。Unicode 把中文字元分散在好幾個區塊，每一個區塊對應一個編碼範圍。知道這些範圍，就能告訴字型工具「只裁出這些區塊」，而不是盲目地抓全部字元。

下表列出部分常見 CJK 相關區塊。範圍內碼位數不等於已指派字元數，也不代表某套字型支援的字形數；保留範圍應由真實內容決定。

這張表實際怎麼用？假設你的站是科技內容，除了 CJK Unified Ideographs（U+4E00 到 U+9FFF）、Halfwidth and Fullwidth Forms（U+FF00 到 U+FFEF）與 CJK Symbols and Punctuation（U+3000 到 U+303F），也要依實際內容保留基本拉丁字母、一般標點、注音或其他用到的區塊。先把字型實際切成對應的子集檔，再在 @font-face 裡用 unicode-range 描述各檔涵蓋的字元，瀏覽器才會依頁面文字下載需要的檔案；unicode-range 本身不會裁小字型檔。

另一個實戰技巧是「頻率分析子集化」。用工具掃描網站所有文章內容，統計每個字的出現頻率，然後只把最常見的那幾千字做成子集。以一個文字密集的內容站為例，統計後往往會發現少數幾千個字就涵蓋了頁面絕大部分的文字，這時針對這組常用字做一個專門的子集檔，體積會遠小於完整字型。實際數字因站而異，建議自己跑一次掃描再決定子集範圍。

可自行掃描內容規劃子集。Google Fonts 的 CSS 回應會依字型與請求提供適合的資源，CJK 字型常使用 unicode-range 分片；這不同於每頁即時重建字型。文字固定時，CSS API 的 text= 可要求指定字元子集，但必須包含所有會使用的字元，內容改變後也要更新。

中文字型怎麼選：黑體、明體、圓體的實戰判斷

挑中文字型，第一個要決定的不是「哪一款好看」，而是這個字型要用在什麼場景。不同用途，判斷標準完全不一樣。下面這張表把常見的中文字體分類整理出來，可以對著自己的需求挑：

正文優先檢查辨識、間距與長文閱讀，標題也可以考慮品牌表現。黑體或明體都不會自動帶來權威感；應用代表性中文、英數、標點與目標裝置比較，再決定用途。

如果想看更具體的字體推薦，可以參考完整的中文字體設計指南，裡面有必藏字體的詳細評比，涵蓋思源黑體、思源宋體、方正系列等。英文搭配的字型挑選，則可以參考英文字體推薦這篇，襯線、非襯線到手寫體都收齊了。

特別提一個新手常踩的坑：很多人以為「字型越多越豐富」，一個頁面同時掛黑體、明體、圓體、手寫體多套字型。先不講視覺混亂，額外下載也可能拖慢 LCP。建議盡量限制字型家族數量，例如一套正文、一套標題或裝飾；能用一套搭配字重變化去創造層次更好。這個觀念在做排版設計時特別重要。

font-display 五種策略，哪一種最適合你

font-display 是 @font-face 的描述符，決定字型尚未可用時的文字顯示與替換時序。它管理阻擋期、交換期與失敗後的備用字行為，不是保證字型下載速度的開關。

它有五個值，這裡直接給實戰判斷，不要背規格：

若正文優先避免文字隱藏，swap 是常見起點，因為瀏覽器會先用備用字顯示內容。載入速度可能影響使用體驗與離開機率，但不同網站的幅度不會相同（見 web.dev 的〈Why does speed matter?〉）。swap 的代價是 FOUT（Flash of Unstyled Text，無樣式文字閃爍），字型替換時可能閃動或造成位移，後面會再處理。

什麼時候用 block？只有當字型是品牌辨識核心、文字量很少，而且測試後確定短暫隱藏可接受時，才值得考慮。例如 Hero 區的少量品牌標準字。不要把整頁正文都設成 block，否則字型載入期間可能出現 FOIT，行動裝置上尤其痛苦。

optional 是一個很特別的值，它只有極短的阻擋期且沒有交換期；如果字型未及時可用，這次頁面檢視就會繼續使用備用字。對純裝飾用的手寫體或特殊字型來說可能很合理，因為沒有也不影響閱讀。

FontFace API：用 JavaScript 精準控制字型載入時機

CSS 的 font-display 已能處理許多顯示策略。若需要以程式載入字型、確認狀態或協調特定介面，可使用 CSS Font Loading API；不要為了等待字型而把原本可閱讀的正文整頁擋住。

FontFace API 屬於 CSS Font Loading Module，能讓你用程式碼創建、載入、監聽字型。語法像這樣：

const font = new FontFace('Noto Sans TC', 'url(/fonts/noto-sans-tc.woff2) format("woff2")', {
  display: 'swap'
});

font.load().then(() => {
  document.fonts.add(font);
  console.log('字型載入完成');
}).catch((error) => {
  console.error('字型載入失敗', error);
});

這段程式碼會創建一個 FontFace 物件，然後載入它。載入成功後，把字型加到 document.fonts 集合，網頁就能使用這個字型。而且因為這是非同步的，你可以在 .then() 裡做任何你想要的後續處理，比如更新 UI 狀態、發送分析事件、或者觸發其他動畫。

FontFace API 的實戰用途主要有三個：

• 條件式載入：依實際功能需求決定是否使用裝飾字型，不能只以手機類別推定網路較慢。
• 狀態處理：在需要精確字型尺寸的畫布或編輯介面確認可用狀態，正文仍保留可讀 fallback。
• 協調載入：依量測安排非關鍵字型；不要把首屏字型延後到 JavaScript 才發現。

FontFace API 已廣泛支援於現代瀏覽器，仍應依目標環境檢查並提供 CSS 或系統字備援。是否照顧舊版瀏覽器是專案支援決策，不能只憑某產品退役就排除所有使用情境。

如果字型已透過 @font-face 宣告，不需要再建立一個指向相同資源的新 FontFace 物件；可改用 document.fonts.load()、document.fonts.check() 或 document.fonts.ready 操作既有字型。CSS 與 Font Loading API 可以搭配使用；是否產生額外網路請求還會受 URL、快取與瀏覽器實作影響，不能一概說一定下載兩次。

把字型檔變小：子集化與 unicode-range

前面提過，中文字型最大的痛點是「檔案大、但實際用到的字很少」。子集化（subsetting）就是直接解決這件事的技術：把字型檔裡用不到的字元全部砍掉，只留下你真正需要的。

完整中文字型通常會包含大量單一頁面用不到的字形；只保留實際需要的常用國字與英數符號後，檔案可明顯縮小。實際壓縮結果取決於字型本身的設計、保留字元、字重與工具參數，不能用固定容量或比例概括，建議用 pyftsubset 之類的工具實測。

子集化有兩種做法，要分清楚：

• 靜態子集：在網站建置階段，用工具（例如 pyftsubset、fonttools）把字型檔預先裁切成固定字集。適合內容變動不大的形象網站、登入頁。優點是快、穩定，缺點是字集固定，碰到頁面出現子集外的字就會 fallback 到系統字。
• 分片子集：預先把字型切成多個檔案，以 unicode-range 描述範圍，再由瀏覽器依頁面文字下載需要的分片；Google Fonts 的一般 CSS 回應採用這類機制。它不同於伺服器依每一頁內容即時重建字型；真正的動態子集需要服務端支援，內容變動時也要正確更新。

unicode-range 是 @font-face 的描述符，用來限制該字型面的適用字元範圍。當頁面需要以該字型呈現範圍內字元時，瀏覽器才可能下載對應檔案。它不會替原檔裁切，也不是按照「中文版、英文版」頁面標籤直接選擇語言包。

這個手法在多語系網站特別有用。假設你同時經營中英文版，與其一次載一包包含所有語系的超大字型，不如拆開來，讓英文訪客只下載需要的拉丁字型子集、中文訪客才下載子集化過的中文檔。對響應式設計的多語系站來說，這是值得優先評估的做法。

字型效能預算：如何設定可驗證的資源上限

談到字型優化，很多網站只是「能小就小」，沒有設定明確的效能目標。即使字型檔縮小，LCP 仍可能受伺服器回應、資源發現時間、網路狀況與 LCP 元素類型影響，因此不能只看檔案大小判斷成效。

要真正把字型優化做到位，可以設定「字型效能預算」，限制每頁使用的字型家族、字重、請求數與傳輸量，再以實測 LCP 驗證。LCP 的官方「良好」門檻是在第 75 百分位數達到 2.5 秒以內（依 web.dev 的 LCP 文件）；但無法從這個門檻直接換算出通用的字型 KB 上限或「佔 LCP 比例」。下面是一個不綁死數字的預算框架：

這張表是規劃方法，不是官方標準。實際上限要根據自家訪客裝置、網路條件、快取命中率與 LCP 元素實測。假設內容型網站同時載入正文黑體和標題明體，就應比較保留兩套字型的體驗價值，以及刪減字重、子集化或改用系統字後的 LCP 與 CLS 差異。

設定預算的好處是讓優化有明確的成功標準。不是抽象地「盡量小」，而是先在代表性的測試環境量出基準，再訂出專案自己的傳輸量與 LCP 上限。當設計師想用某套商業字型時，團隊就能用實際檔案與測試結果決定要刪減字重、子集化或換字型。

字型預算應根據實際裝置、網路、快取與瓶頸調整。地區或行動裝置比例只能提供背景，不能直接推定連線一定快或慢。用可重複的 lab 測試定位問題，再以有資料時的 field 指標觀察使用者體驗。

預載入、preconnect 與 CDN：從傳輸層加速

子集化把檔案變小了，接下來要想的是「怎麼讓這個變小的檔案更快送到訪客手上」。這裡有兩個層面：下載時機和下載路徑。

用 preload 提前下載關鍵字型

字型通常在樣式與使用文字確定後才被請求。rel="preload" 可提前發現確定需要的字型，但它不會遵守 unicode-range 的按需下載判斷；對分片中文字型，誤把每個分片都預載可能反而浪費頻寬。只預載首屏確定會用的少數資源，並比較 Network 請求與 LCP。

寫法像這樣：

<link rel="preload" href="/fonts/noto.woff2" as="font" type="font/woff2" crossorigin>

字型 preload 的 URL、資源類型與 CORS 模式應和正式字型請求一致，通常需要 crossorigin，即使同源也要注意。設定不合可能讓預載資源無法重用；以 Network 與瀏覽器提示確認，不預設每種失配都必然下載兩次。

用 preconnect 提早建立連線

如果你的字型放在第三方網域（例如 fonts.googleapis.com），瀏覽器可能要先做 DNS 查詢、TCP 交握與 TLS 協商。用 preconnect 可以讓瀏覽器在還沒實際要下載字型前，就先建立連線（見 web.dev 的 resource hints 說明）：

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Google Fonts 的 CSS 由 fonts.googleapis.com 提供，字型檔通常由 fonts.gstatic.com 提供，因此若確定首屏會使用，對這兩個來源設定正確的 preconnect 可減少連線建立等待。

依訪客分佈評估 CDN 與快取

如果訪客分布跨多個地區，可以評估透過 CDN（內容傳遞網路）提供字型檔。CDN 可從邊緣節點提供快取資源，減少部分訪客回源的網路距離；實際改善幅度取決於 CDN、快取命中、主機位置與訪客網路。CDN 的原理和挑選，可以參考CDN 網站加速專文，這裡不重複展開。

可變字型：用檔案支援的軸範圍控制外觀

可變字型可以在同一個字型資源內提供一個或多個變化軸，例如字重、寬度或光學尺寸。它只支援檔案定義的軸與範圍，不是任何字重都能取得；分片、斜體與其他字型資源也可能仍需分開下載。

對中文 webfont 來說，可變字體特別值得比較。靜態字體通常要為每個字重載入不同檔案，可變字體則能用一個檔案涵蓋一段字重範圍；它有機會降低總下載量，但效果取決於實際檔案、使用字重與子集化結果，不能套用固定比例。

使用標準字重軸時，可先用 font-weight 配合 @font-face 宣告的範圍；需要直接控制軸時再用 font-variation-settings。例如 Source Han Sans 可變版本提供字重變化，但 CSS 能選的範圍應依實際檔案。動態改字重時也要檢查可讀性、位移與減少動態效果的偏好。

當然可變字體不是沒有代價。它的單一檔案通常比單一字重的靜態檔大，如果網站只用一個字重，硬上可變字體反而可能不划算。沒有固定的「三個字重」門檻，應把實際會載入的靜態檔總量，和子集化後的可變字體檔案直接比較。Noto Sans TC（重量軸 100 到 900）和 Noto Serif TC（重量軸 200 到 900）都已在 Google Fonts 上以可變字體形式提供，想嘗試可以直接從這兩套入門。選用之前，記得確認目標瀏覽器支援度；若仍要照顧舊版環境，就準備靜態字型檔當退路。

FOUT、FOIT 與 CLS：字體載入的三大體驗瑕疵

字型載入過程中會出現三種讓訪客不舒服的視覺瑕疵，一定要知道名字和成因，才有辦法對症下藥。

FOIT（Flash of Invisible Text，不可見文字閃爍）：在字型交換期之前，瀏覽器可能暫時隱藏使用該字型的文字。font-display: block 會保留一段短阻擋期；實際時間由瀏覽器決定。弱網環境下，過長的空白文字會明顯傷害閱讀體驗。

FOUT（Flash of Unstyled Text，無樣式文字閃爍）：瀏覽器先用系統備用字顯示文字，等字型下載完再替換。這正是 font-display: swap 的行為。替換的瞬間，字寬、字高、行距可能都會變動，畫面會「跳」一下；對文字型 LCP 元素而言，字型顯示策略也可能影響 LCP 時序，不能把 FOUT 視為與 LCP 完全無關。

字型切換若讓文字換行或推動其他元素，可能產生計入 CLS 的非預期位移。CLS 衡量頁面生命週期中的位移，不是字型閃一下的名稱，也不只有載入時才會發生。它是 Core Web Vitals 之一，但不能用單一數值推算排名。

怎麼把 CLS 壓下來？核心原則是讓備用字和正式字的尺寸越接近越好。實務上有幾個做法：

• 選擇在目標平台可用、尺寸與排版較接近的備用字，實測中文與英數混排。
• 評估 font-size-adjust 等尺寸調整方式；預設指標為 x-height，較新的語法也有 CJK 寬高指標，需核對支援。它不會自動讓所有字寬、換行與垂直度量相同。
• 為已知佈局保留合理空間，但避免固定高度裁切放大或長文字；以位移記錄確認改善。

這些做法可用來降低字型替換的位移，改善幅度要實測。若剩餘位移來自圖片、廣告或動態內容，也需要處理相應來源。 延伸可參考Core Web Vitals SEO。

無障礙考量：字型不只是為了好讀

談到字型，多數人只想到「好不好看」或「好不好讀」，但從無障礙設計（a11y）的角度，字型選擇會直接影響某些訪客能不能順利使用你的網站。

目前的 W3C Recommendation 是 WCAG 2.2（Web Content Accessibility Guidelines）；其中有幾條與文字呈現直接相關的準則：

• 1.4.4 Resize Text（AA）：除字幕與文字圖片等例外，文字放大至 200% 時不應失去內容或功能；不代表 CSS 一律禁止 px。
• 1.4.12 Text Spacing（AA）：適用的文字間距被覆寫到規定值時，內容與功能不能遺失；並非要求網站內建一組調整控制項。
• 1.4.3 Contrast (Minimum)（AA）：一般文字 4.5:1，大型文字 3:1，另有例外；AAA 的較高對比要求屬 1.4.6，分別為 7:1 與 4.5:1。

SC 1.4.12 的重點不是要求網站預設採用固定間距，而是當使用者把行高、段落後距、字母距與字距覆寫到指定測試值時，不得流失內容或功能。測試值如下：

WCAG 本身沒有規定正文字級的最小值。實作上應確保使用者把文字放大到 200% 時，內容與功能仍然完整；相對單位通常較容易做出可伸縮版面，但使用 px 本身不會自動構成違規，真正的問題是放大後出現裁切、重疊或功能流失。

除了這些基本要求，還有針對特殊需求的考慮：

• 閱讀障礙：沒有一套字型能保證適合所有 dyslexia（失讀症）讀者。應優先確保字形容易區辨、間距可調、行長合理，並讓使用者能覆寫字型；若這是核心受眾，應以實際使用者測試判斷。
• 螢幕閱讀器：螢幕閱讀器主要依 DOM、文字內容與無障礙樹朗讀，不會因字型外觀「設計化」就改變底層文字。不過低辨識度字形仍會傷害使用螢幕放大或以視覺閱讀的使用者，因此不可過度犧牲可讀性，也不要用圖示字型取代有語意的標籤。
• 色彩對比：雖然這不是字型本身的問題，但字型和背景的對比度必須符合 WCAG AA 等級（正常文字至少 4.5:1）或 AAA 等級（正常文字至少 7:1）。很多時候，不是字型不好讀，是對比度不夠。

如果需要驗證網站是否符合 WCAG，可以用 axe DevTools 或 WAVE 這類無障礙檢測工具協助找出部分問題，更多工具可查 W3C WAI 的檢測工具清單。自動檢測無法涵蓋所有準則；文字縮放、spacing 覆寫、閱讀順序與實際可用性仍需要人工測試。

現代 CSS 字型屬性：OpenType 特性在中文的應用

多數人用 CSS 字型屬性只知道 font-family、font-size、font-weight，但現代 CSS 還有許多能啟用字型內建功能的屬性，這些功能來自 OpenType 規範（見 MDN 的 OpenType 指南）。

font-variant-numeric 是其中實用的一個。它能控制數字的顯示方式，比如：

.stats {
  font-variant-numeric: tabular-nums;
}

在字型支援 tnum 時，tabular-nums 讓各個數字字形使用相同前進寬度，便於同位數資料對齊。它不會讓三位數與四位數的總寬相同，也不能保證任何數值更新都不位移。

另一個常用的是 font-feature-settings，它能直接操作 OpenType 的 feature tag。比如說，某些字型提供「連字」（ligatures）功能，讓特定字元組合顯示成特殊設計：

font-feature-settings: "liga" 1;

在所選字型提供對應功能時，這會請求標準連字。需要標準與自由連字時，可使用下例；有專用的 font-variant 屬性時，通常優先使用較易讀的寫法。

font-feature-settings: "liga" 1, "dlig" 1;

dlig 是 discretionary ligatures（自由連字），是設計師額外設計、預設關閉的連字組合。

CJK 字型也有重要的 OpenType 功能，例如比例寬度、直排與在地化字形；是否可用要看字型實作，不能概括成中文功能較少而不實用。下列標籤則常見於英數排版：

• smcp：小型大寫字母（small caps）
• c2sc：小型大寫字母（從大寫轉成）
• onum：舊式數字（oldstyle figures）
• tnum：表格數字（tabular figures）

如果你的網站有很多數據視覺化、表格或報表內容，而且所選字型支援，tnum 會很實用。

要注意的是，font-feature-settings 是一個「低階」屬性，它直接操作 OpenType tag，語法不直觀。如果 CSS 提供了專用屬性（像 font-variant-numeric），優先用專用屬性，只有在需要特殊功能時才用 font-feature-settings。

免費與付費字型資源怎麼挑

市面上字型資源很多，這裡把最值得用的整理出來，幫你省下比較的時間。

Google Fonts 是常見起點。它提供 CDN、子集機制與 HTTPS，只要貼一段 <link> 就能用。繁體中文字型可利用網站的語言與書寫系統篩選器查看現有選擇，其中 Noto Sans TC 和 Noto Serif TC 是常見的開源字型。

Adobe Fonts 提供個人與商業用途的字型授權，網頁使用須依有效方案與 web project 嵌入方式。這不授權直接把字型檔複製到自己的伺服器；若需自行託管，可向字型廠商確認另行授權。採用前核對目前方案、訂閱狀態與專案交接條件。

如果你的品牌需要獨特的字型（非開源、非 Google／Adobe 提供），就要向字型廠商確認並購買適用的商業授權。成本與品牌獨特性因字型和方案而異；買之前一定要確認條款是否允許 webfont 嵌入、自行託管，以及授權範圍與計費方式。

一個常被放過的免費資源是系統字。如果只追求「乾淨、好讀、快速」，不強求品牌專屬字型，可以使用 macOS 的 PingFang TC、Windows 的 Microsoft JhengHei，並搭配通用 sans-serif fallback；使用裝置上已安裝的字型不需額外下載。對很多內容型網站來說，這其實是性價比很高的選擇，尤其當網站的主訴求是資訊傳遞而非視覺衝擊。

WordPress 站長的 webfont 實戰

WordPress 的主題、編輯器和外掛都可能加入字型，適合從實際輸出盤點來源，再決定要在哪一層調整。

WordPress 處理字體的常見痛點是：佈景主題和外掛可能各自載入 Google Fonts 或重複的字重，造成不必要的外部 CSS 與字型請求。用 PageSpeed Insights 或 DevTools 盤點實際請求後，再移除重複或未使用的字型，才能知道對 LCP 的真實影響。

實戰上有三條路可以選：

1. 本機託管 Google Fonts：在授權允許下，把原本的字型檔放到自己伺服器，用 @font-face 載入。好處是能自行控制子集、快取與第三方連線；但本機託管不保證一定更快，也不等於網站自動符合 GDPR，仍要依整體資料處理方式評估。完整的做法寫在WordPress 本機託管 Google Fonts這篇，一步步帶你做。
2. 用外掛自動優化：如果不想動程式碼，有些效能外掛能把 Google Fonts 改成本機託管，或為仍使用的第三方來源加入 resource hints；本機字型不需要對 Google 網域加 preconnect。選外掛時注意別裝太多功能重疊的，可以參考WordPress 外掛推薦清單。裝外掛的方法看這篇外掛安裝教學。
3. 佈景主題層級控制：不少現代佈景主題（例如 Astra）本身就提供字體優化選項，讓你在後台直接選字型、調字重，不必手改 CSS。Astra 的操作可以看Astra 主題教學。用 Divi 架站的人，則可以照Divi 的自訂字型上傳流程把品牌字型掛上去。

不管走哪條路，記得一件事：優化完之後要用測量工具驗證。用網站速度測試工具跑一次，看字型請求數量、下載量、LCP 有沒有改善。沒有測量，就不會知道優化到底有沒有效。如果你的站整體偏慢，不只是字體問題，建議把網站速度這條線的細節和網站慢的診斷解法一起對照著看。

進階技巧：讓字體和快取、延遲載入聯手

字體優化做到一個程度，會發現它和其他效能技術是環環相扣的。單獨看字體能擠出的空間有限，但把它放進整體效能策略裡，效果會疊加。

對內容不會原地更改、以版本或 hash 更名的字型檔，可評估較長的 Cache-Control，例如一年。瀏覽器是否保留快取仍受容量、清除與快取政策影響；不能保證訪客只下載一次，也要確保更新時不繼續引用舊檔。 延伸可參考網站快取指南。

非關鍵區域若使用獨立的裝飾字型，可評估在需要時才建立或套用對應字型。僅把元素放到畫面外，不代表瀏覽器會自動延後字型下載；以 Intersection Observer 或 Font Loading API 控制時，也要避免遲來換字造成位移。 延伸可參考Lazy Loading 延遲載入指南。

圖片與字型都可能使用有限的下載資源。比較壓縮圖片、調整字型與其他改善前後的時序，找出真正影響 LCP 的項目，不能保證兩種優化一起做就會達到特定分數。 延伸可參考圖片壓縮工具推薦、WordPress 圖片優化。

把字型放回整個頁面觀察：下載、快取、字型替換與其他資源互相影響。一次小修改也可能解決主要瓶頸，但應以量測判斷，避免只為移除工具提示而新增更多設定。

常見的地雷與迷思

這裡整理幾個反覆出現的字體相關錯誤，幫你少走冤枉路。

迷思一：字型越多越有設計感。前面講過了，字型家族應盡量精簡，只保留有明確用途的正文、標題或裝飾字。掛太多字型容易造成視覺混亂、增加下載量與維護成本。

迷思二：貼上 Google Fonts 的 <link> 就一定是最快。Google Fonts 目前產生的嵌入範例通常包含對 gstatic.com 的 preconnect，也會用 unicode-range 分片；固定文字還可用 text= 最小化請求。但仍要只選實際需要的家族與字重，並在目標環境比較第三方託管和本機託管，不能預設其中一種一定更快。

桌機安裝、網頁嵌入、自行託管與轉換格式可能有不同授權。使用商業字型前核對取得的條款；開源字型也要遵守再散佈、授權附帶與保留名稱等要求，不能把任何已購買字型都直接轉成網頁資源。

迷思四：字型只影響美觀，不影響效能。字型載入可能影響 LCP 與 CLS。Google 在 Search Central 的說明中指出，良好的 Core Web Vitals 有助於搜尋成功與使用體驗，但頁面體驗只是眾多因素之一，相關性更高的內容仍可能排名較前。不能宣稱跳出率或停留時間會直接回饋排名，也不能把字型優化當成排名捷徑。它本質上是效能與閱讀體驗工作；想理解更完整的 SEO 脈絡，可以從WordPress SEO 全攻略看起。

迷思五：已經用了系統字，就不用管字體優化。系統字確實零下載，但很多佈景主題或外掛會在你不知情下偷掛 webfont。定期用瀏覽器開發者工具的 Network 面板，篩選 Font，看看你的頁面實際載了哪些字型檔。很多時候會嚇一跳。要是查到字型檔卻對不上畫面上的文字，再用網頁字型辨識工具在頁面上點出字體名稱與字重，來源就對得上了。

迷思六：字型只管好不好看，不用管閱讀性。字型、字級、行高與段落留白會一起影響閱讀體驗，但不能把停留時間或完讀率直接稱為 Google 排名訊號。正文字級與行高也沒有適用所有裝置的固定數字，應依字型特性、版面寬度、語言與實機閱讀測試調整。選字型時若不一起考慮這些排版參數，再漂亮的字也很難發揮價值。

字型策略決策矩陣：什麼情況用什麼做法

前面講了這麼多技術，這一張決策矩陣幫你整合成「什麼情況用什麼做法」。不是每個網站都需要可變字體或動態子集化，關鍵是匹配你的網站類型和需求。

這張表的核心邏輯是：問自己「這個網站的成功關鍵是什麼？」如果是品牌形象，就願意為字型付出更多下載成本；如果是速度和轉換，就盡量用系統字和最小化的 webfont；如果是內容型網站，就平衡閱讀性和速度，用開源字型加子集化。

另一個維度是「流量規模」。高流量站縮小每次回應的傳輸量，累積後可能降低 CDN 頻寬成本；但檔案大小不會直接改變請求次數。這時候字型子集化和壓縮不只是效能問題，也是成本問題。建議定期做字型審查，看有沒有冗餘的字重或沒在用的字型可以移除。

怎麼診斷字體效能問題：DevTools 實戰

要確認網站是否有字體問題，可以用 Chrome 開發者工具走一次診斷流程，直接查看實際載入的字型檔、請求時序與版面位移。

第一步，打開你要檢查的頁面，按 F12 或在頁面按右鍵選「檢查」打開 DevTools，切到 Network 分頁。在資源類型篩選按鈕裡選 Font，重新整理頁面。你會看到這一頁載入的所有字型檔清單，每個檔案的 Size、Time、Waterfall 都一目了然。重點看總共載入哪些家族與字重、各有多大、是否重複，以及下載時間落在瀑布圖的哪個位置；沒有適用所有網站的固定請求數或單檔容量門檻。

第二步，切到 Performance 分頁，按錄製鈕跑一次頁面載入。錄完後對照 Network track 的字型請求、Main track 的 Render／Paint 事件與 LCP 標記，判斷字型是否延後文字繪製。如果 LCP 元素是使用 webfont 的標題，就進一步比較字型請求與該元素繪製的時序。

第三步，用 Lighthouse 跑一次報告（DevTools 裡的 Lighthouse 分頁，或直接用 PageSpeed Insights 線上版）。自 Lighthouse 13 起，舊的「Ensure text remains visible during webfont load」稽核已移到 Font display insight；若出現提示，應檢查 font-display 與 fallback 策略，而不是一律套用同一個值（見 Chrome Developers 的稽核說明）。

第四步，檢查 CLS。在 DevTools 的 Performance 分頁使用 Live metrics 與 Layout shifts track，查看位移分群、受影響元素與可能原因。Web Vitals Chrome 擴充功能已在 2025 年停止支援，相關功能已整合到 Performance 面板（見 Chrome Developers 的公告）。如果位移集中在字型替換的瞬間，再調整備用字與 font-size-adjust。

這四步走完，對自己網站的字體健康度會有清楚的數字依據，不再憑感覺判斷。測試時應固定裝置與網路節流條件，視需求停用快取或另外測試冷、暖快取，並重複執行；桌機和手機也要分開測，因為兩者的實際結果可能不同。想知道更多測速工具的比較，可以看網站速度測試工具這篇的完整評比。

字體優化行動清單：七步把字型效能拉起來

講了一整篇，給你一份能照著做的行動清單。這是評估網站字體健康度時會走的流程：

1. 盤點：查看字型請求、使用位置、字重、大小與時序。
2. 刪減：移除沒有實際用途的家族與重複來源。
3. 比較字重：依需要選擇靜態或可變檔案，量測實際傳輸量。
4. 規劃字集：在授權允許下做子集或使用分片，檢查缺字與新增內容。
5. 選顯示策略：比較文字隱藏、替換與備用字的取捨，不一律套 swap 或 block。
6. 評估資源提示：僅預載確定需要的關鍵字型，對必要外部來源使用 preconnect，核對 CORS。
7. 驗證體驗：檢查字型切換、文字放大與 CLS；有足夠 field 資料時，核對第 75 百分位的 CLS 是否在 0.1 以內。

完成後留下基準與結果，新增字型或更換主題時再核對。這份流程提供檢查方式，不代表自動達到某個業界水準或通過全部效能與無障礙要求。

字體這件事，本質上是「用最少的下載成本，換最大的視覺質感」。它真正考驗你的，是在設計和效能之間做理性取捨的判斷力，CSS 語法反而是最簡單的一環。這種取捨能力，其實就是好的網頁設計和好的UI／UX的核心。當你把字體、色彩（見網站配色指南）、版面（見網頁版面設計）這幾個變數都調到平衡，網站的整體質感自然會出來，而且不必拿速度去換。

把字體當成網站的基礎建設來管理，能減少不必要的下載與版面位移。打開網站的 DevTools，先看看實際載入了哪些字型檔，再決定要刪減、子集化或調整載入策略。

新站可以提早記錄字型用途、來源、授權、字重和載入策略，讓後續變動有依據。即使初始規劃完整，新增內容與功能後仍要再次測試。 延伸可參考WordPress 快速架站、Astra 品牌網站搭建。