網站字型加載方式往往是被忽視的細節，卻直接影響訪客看到內容的速度。當你使用 Google Fonts 時，瀏覽器需要向 Google 的伺服器發起跨域請求，這不僅增加 HTTP 連線數，還可能延遲最大內容繪製（LCP）的觸發時刻。若你的 H1 標題或英雄區塊文字依賴外部字型，延遲就會直接傷害核心 Web 指標（Core Web Vitals）分數。本文將拆解字型渲染策略，以及將字型本地化後如何透過預載加速的實作思路。
Google Fonts 跨域請求對效能的實際衝擊
使用 Google Fonts 時，瀏覽器在遇到字型聲明後會發起外部請求，這個過程涉及 DNS 查詢、TCP 連線建立與 HTTPS 握手。即使在高速網路環境下，單筆跨域字型請求也會消耗 100～300ms。若你的頁面載入時已經有圖片、腳本、樣式表等多筆請求在排隊，字型檔案很可能成為最後一根稻草，推遲文字首次出現的時間點。
更關鍵的是，如果 LCP 元素（通常是網誌首圖或 H1 標題）使用了 Google Fonts 但尚未載入，瀏覽器會等待，導致 LCP 分數飆升。根據 2026 年的效能監測數據，自架字型相比 Google CDN 路徑平均快 100～300ms，在行動網路上落差更明顯。
字型渲染策略的四個選項
當瀏覽器下載自訂字型時，有一個時間軸問題：要立刻用預設字型顯示文字，還是先隱藏文字等字型載入？CSS 的 font-display 屬性就是用來控制這個決策的。理解四個值的差異，能幫你針對不同情景做出最佳選擇。
font-display: auto
這是未明確設定時的預設值，瀏覽器採用自己的策略，通常表現類似 block。行為不可預測，且在不同瀏覽器上可能有差異。除非有特殊需求，否則不建議依賴此值，應改為明確指定其他值。
font-display: block
瀏覽器會完全隱藏文字直到自訂字型載入，最多等待 3 秒。若超過時限字型仍未來，就降級為預設字型。這個策略保證最終呈現的是你想要的字型，代價是短時間內頁面出現空白——俗稱「看不見文字現象」（Flash of Invisible Text, FOIT）。適合品牌標誌或特殊視覺設計必須精確呈現的場景，但對一般內文會傷害使用者體驗。
font-display: swap
立刻用預設字型顯示文字，當自訂字型準備好後「無縫切換」。這是 2026 年 WordPress 社群的推薦做法，因為訪客能立刻讀到內容，視覺上只是看到一次短暫的字型切換（Flash of Unstyled Text, FOUT）。切換時間通常在幾百毫秒內，使用者感受不明顯，卻大幅改善了可讀性。
font-display: fallback
瀏覽器先用預設字型，但給自訂字型一個 100ms 的「短時間窗口」——若 100ms 內沒下來，就放棄等待用預設字型。這種策略適合網路較不穩定的場景（比如行動 4G），或者你接受「有時候字型可能載不來」的風險。
font-display: optional
更激進的版本，不開放無限切換窗口。字型來了最好，沒來就永遠用預設字型，完全不干擾使用者體驗。適合非核心視覺元素、網路環境不穩定的場景。
對比三種載入策略的實際效果
不同的 font-display 搭配不同的字型來源，會產生截然不同的使用體驗。下表以 LCP 分數、首次可讀時間、視覺過渡現象為評估軸線，幫助你快速判斷適合的組合。
| 策略組合 | LCP 分數 | 首次可讀時間 | 視覺過渡 | 適用場景 |
|---|---|---|---|---|
| Google CDN ＋ swap | 較差（300ms+） | 慢 | 輕微 FOUT | 無特殊優化 |
| Google CDN ＋ block | 最差（3s 等待） | 最慢 | FOIT（完全隱藏） | 品牌標誌、特殊字型必須精確 |
| 本地自架 ＋ swap | 最佳 | 快 | 輕微 FOUT | 推薦做法，日常內文 |
| 本地自架 ＋ preload | 最佳 | 最快 | 無 | 高優先順序 LCP 字型 |
字型本地化的實作概念
將 Google Fonts 改為本地自架，核心做法是下載字型檔案，存放在自己的伺服器上，然後修改 CSS 指向本機路徑。WordPress 6.5 之後內建了自動下載與自架機制，不需外掛即可做到。手動做法則是透過字型轉換工具，將字型從 Google 平台下載下來，上傳到主機的 /wp-content/fonts/ 資料夾，再用自訂 CSS 聲明新的 @font-face。
本地自架的好處不只是速度。Google Fonts 涉及跨域請求與隱私法規（特別是歐盟 GDPR），將字型自架後不再向第三方發送訪客資訊，符合隱私合規。同時，你對字型的載入時機、格式、預載策略有完整控制權。
預載優化與關鍵字型優先序
當字型本地自架後，下一步是利用 <link rel="preload"> 標籤在關鍵字型上「打上優先權」，讓瀏覽器在解析頁面的早期階段就開始下載。這特別適合用在 LCP 元素——也就是頁面最大的可見文字，通常是你的首圖或 H1 標題所用的字型。
預載時不是盲目對所有字型都加，而是只對「造成效能瓶頸的那一個字型」預載。預載太多反而會搶走其他資源的頻寬。一般建議挑最重的字型（通常是 Bold 或 Medium 的拉丁字母子集），或者挑最早出現在首屏的字型。在 WordPress 裡，可以透過佈景主題的 functions.php 或客製化 wp_resource_hints 鉤子來新增預載指令。
使用 OMGF（自動優化 Google Fonts）或 WP Rocket 這類最佳化外掛，會自動偵測並新增最佳化的預載標籤，不需手動 CSS 調整。
優化成效的驗證與調整
套用這些優化後，用 Chrome DevTools 的 Network 頁籤觀察字型檔案的下載時機與大小。聚焦三個指標：首先是字型從發起請求到完全載入用了多少時間（目標在 200ms 以內），其次是字型檔案大小有沒有異常（拉丁字母子集通常在 30～80KB），再者是預載標籤有沒有真的生效（Preload 的優先權應該高於其他非關鍵資源）。
用 Google PageSpeed Insights 或 WebPageTest 跑 LCP 測試，對比優化前後的分數。若本地自架加預載後 LCP 分數還沒改善，問題可能不在字型本身，而在首屏圖片或伺服器回應延遲。這時候可以用效能火焰圖來定位真正的瓶頸。
本機自架字型、選擇適當的 font-display 值、對 LCP 關鍵字型預載，這三步組合起來就能有感地加快頁面載入。從跨域到本地、從被動等待到主動預載，是 WordPress 站長必做的效能調整。