WordPress 本機託管 Google Fonts 完整教學：加速網站又符合 GDPR 規範
把 Google Fonts 下載到自家主機託管，是同時解決「第三方請求拖慢網站」與「向 Google 回傳訪客 IP 的 GDPR 隱私爭議」的單一動作。2022 年德國地方法院…
WordPress 本機託管 Google Fonts 完整教學：速度、合規與手動實作
把 Google Fonts 下載到自家主機託管，是同時解決「第三方請求拖慢網站」與「向 Google 回傳訪客 IP 的 GDPR 隱私爭議」的單一動作。2022 年德國地方法院連續判決認定，網站未經訪客明確同意即透過 fonts.googleapis.com 回傳 IP 位址，已構成個資跨境傳輸、違反 GDPR 第 44 條。對重視速度與合規的站長來說，手動託管的價值在於完全控制字型清單與請求數量，不靠外掛。完整做法涵蓋下載、轉 WOFF2/WOFF、上傳、寫 @font-face CSS、停用主題外掛的遠端載入、再用開發者工具驗證，整條鏈跑完才算真正本機託管成功。
重點先看：本機託管 Google Fonts 的核心不在加速，而在切斷訪客 IP 回傳給 Google 的資料流；2022 年德國法院已認定此舉違反 GDPR，這才是合規導向網站非做不可的理由，速度提升只是附帶紅利。
很多教學把這件事講成單純的「加速技巧」，避談真正的觸發點。講白一點，如果你的網站只服務本地市場、又不在乎法規風險，那放任主題外掛連 網站速度慢的診斷與解法 裡提到的遠端字體，或許還撐得下去。但只要網站收得到歐盟訪客流量，或你接的客戶在意品牌合規，這件事就從「可選」變成「必做」。手動託管可以拆成可重現的步驟，OMGF 外掛與手動託管之間的取捨也有明確的判斷線，能讓你依自己的技術背景選對路線。順帶一提，速度本身也跟 Core Web Vitals 核心效能指標 直接掛鉤，本機託管會影響其中幾項評分。
為什麼要在 WordPress 本機託管 Google Fonts：速度與 GDPR 雙重理由
把 Google Fonts 放到自家主機，到底解決了什麼？答案是同時解兩件事：一是把 fonts.googleapis.com 與 fonts.gstatic.com 的遠端請求收回自家伺服器，減少 DNS 查詢與外部連線時間；二是切斷訪客 IP 回傳給 Google 的資料流，這正是歐洲法院判定 Google Fonts 違反 GDPR 的核心爭議點。兩個理由疊起來，才是本機託管真正值得做的全貌，單講速度只說了一半。
速度面的邏輯很直觀。每多一個遠端字體請求，就多一次 DNS 解析與下載，Google 官方的 PageSpeed Insights 與 GTmetrix 都會把字體列為優化項目，建議名稱像是「Avoid multiple page redirects」「Reduce font size」「Ensure text remains visible during webfont load」這類 [來源：〈Google PageSpeed Insights〉〈https://pagespeed.web.dev/〉〈2026〉]。當你用測試工具跑網站，看到 fonts.googleapis.com 與 fonts.gstatic.com 出現在請求清單，那就是字體在跟遠端要資源。這部分可以對照 網站速度測試工具推薦 與 WordPress 網站加速必備外掛 一起看，把整體 網站速度優化的整體策略 拼起來。
合規面才是多數人忽略的重點。透過 Google Fonts 載入字型時，訪客的 IP 位址會被傳送到 Google 伺服器，歐盟法院認定未經明確同意即構成個資傳輸。德國幾個聯邦地方法院在 2022 年起陸續判決網站敗訴，賠償金額雖不高，但律師費用與商譽成本讓不少品牌站長警覺。判決背後的法律邏輯有兩層。第一層是 GDPR 第 44 條的跨境傳輸禁止原則：個人資料原則上不得傳輸到歐盟以外的第三方，除非有適足性認定或適當保護措施。IP 位址在歐盟法院的判例體系裡被明確歸類為個人資料，這點早在早期 cookie 案件就已確立，因此 fonts.googleapis.com 取用 IP 的瞬間，跨境傳輸就已完成。第二層是 ePrivacy 指令與各國施行法的同意要求：在終端使用者設備存取或儲存資訊，原則上需要事先告知並取得同意。載入 Google Fonts 觸發瀏覽器發出請求、把 IP 送到 Google 伺服器，恰好落在這條規範的射程內，這也是判決核心法條來源。
合規風險的實際型態分成三種，理解差異才知道要不要本機託管。第一種是賠償金本身，金額通常偏低，單一案件多落在數百歐元這個量級，對大型企業不痛不癢。第二種是律師函與訴訟費用，德國的法律制度容許專門發函索費的實務操作，被告往往要負擔對方律師費，這部分金額遠高於賠償金，是實際的財務壓力來源。第三種是商譽與合規審計成本，當品牌把隱私合規當成採購或合作的前置條件，任何被判決敗訴的紀錄都會在盡職調查階段浮現，影響合作機會。把三層風險加總，合規導向的品牌站才會把本機託管當成必做項目。可控面則是本機託管的副效益：你能決定要載入哪些字重，避免主題或外掛預設拉一整套字型家族。切換到本機前，先盤點目前主題與外掛用了哪些 Google 字體，避免託管了用不到的檔案，這個動作也能順便釐清 技術性 SEO 完全指南 裡會提到的資源浪費問題。盤點資源的同時，也別忘了回頭檢查XML Sitemap 對 SEO 的作用是否還涵蓋所有頁面，確保 Google 能完整爬到改動後的結構。
講個常見情境。一個用 Astra Pro 主題評測 加 Elementor 打造的品牌形象網站，字體設定看似乾淨，實際跑開發者工具卻往往發現有四、五個字重在輪流請求 Google。站長一開始可能只想裝外掛了事，但只要網站背後有歐盟市場的經銷商或客戶，合規問題立刻變成第一優先。這種情境下的正解是手動只留 Regular 400 與 Bold 700，請求數通常能砍掉一半以上。所以別把本機託管當單純效能任務，它的真正位置在合規工程裡。
- 速度面：每多一個遠端字體請求就多一次 DNS 解析與下載，PageSpeed Insights 與 GTmetrix 都會把字體列為優化項目。
- 合規面：訪客 IP 會經由 Google Fonts 傳送到 Google，未經同意即構成個資傳輸，歐盟法院認定違反 GDPR。
- 可控面：本機託管後你能決定載入哪些字重，避免主題或外掛預設拉一整套字型家族。
- 事前盤點：切換本機前先查清楚主題與外掛用了哪些 Google 字體，避免託管用不到的檔案。
手動託管 vs OMGF 外掛：三個維度幫你決定走哪條路
能手動託管 Google Fonts，為什麼還要考慮 OMGF 外掛，又該怎麼選？如果你只求快速上線、不想碰 CSS，OMGF 能在幾分鐘完成本機託管；如果你要精準控制字重清單、不想多裝外掛、或主題外掛組合複雜需要手動排除衝突，手動託管才是長期乾淨的選擇。兩者不是誰取代誰，而是不同情境下的正解。
把選擇拆成三個維度來看，會比憑感覺決定更踏實。上手門檻方面，OMGF 安裝即用，手動流程則要經過下載、轉檔、上傳、寫 CSS 共四個環節，每一步都會卡到一點 CSS 基礎語法入門 與 FTP 上傳的操作。控制粒度方面，手動能只留 Regular 400 與 Bold 700 兩個字重，外掛預設可能載入更多，這也是追求極致效能時手動勝過外掛的關鍵。維護成本方面，手動託管若搭配 Astra 主題免費版教學 的子主題寫 CSS，主題更新不會被覆蓋，外掛則需跟著版本更新。
| 維度 | OMGF 外掛 | 手動本機託管 |
|---|---|---|
| 上手門檻 | 安裝即用，幾分鐘完成 | 下載/轉檔/上傳/寫 CSS 共四步 |
| 字重控制 | 預設可能帶入多個字重 | 可精準只留 Regular 400 + Bold 700 |
| 外掛負擔 | 多一層 PHP 處理，但輕量 | 零外掛，最直接的請求路徑 |
| 合規審計 | 適合一般站點快速達標 | 適合需要逐項交代字型清單的審計 |
| 主題更新影響 | 外掛獨立，需跟版本更新 | 子主題寫 CSS 則不受影響 |
OMGF 本身輕量，在 WordPress.org 外掛庫有數十萬次安裝的規模 [來源：〈OMGF (Optimize My Google Fonts) on WordPress.org〉〈https://wordpress.org/plugins/host-webfonts-local/〉〈2026〉]，對不想碰程式碼的站長是合理選項。但對極致追求請求數的人來說，外掛預設往往連帶載入用不到的字重，這正是手動仍勝過外掛的關鍵差異。另一個常被拿來搭配的是 Disable and Remove Google Fonts 外掛，它支援主流主題外掛組合但不保證全部覆蓋 [來源：〈Disable and Remove Google Fonts on WordPress.org〉〈https://wordpress.org/plugins/disable-remove-google-fonts/〉〈2026〉]。決策建議很簡單：新手或時間有限選 OMGF；有經驗、追求最小請求數、或合規審計需求高的站長選手動。這條判斷線也適用於你評估 WordPress 必裝外掛清單 時的原則，能用設定解的就不要靠外掛疊外掛。
四象限決策矩陣：把你的情境套進來選路線
三維度比較適合理解差異，真正做決定時，用「字體策略的重要性」與「團隊技術維護能力」兩個軸線畫出的四象限更實用。這個矩陣把絕大多數實務情境收進四個區塊，對號入座就能看到推薦路線，省下在兩個方案之間反覆搖擺的時間。
| 象限 | 字體策略重要性 | 團隊技術能力 | 推薦路線 | 典型情境 |
|---|---|---|---|---|
| 第一象限 | 高（品牌辨識、合規審計） | 高（有 CSS 與子主題維護能量） | 手動本機託管 + 子集化 | 品牌形象站、跨國企業官網、有隱私長官把關的單位 |
| 第二象限 | 高 | 低（無人維護 CSS） | OMGF 外掛代勞 | 委外接手後內部無技術人力、合規壓力大但人手不足 |
| 第三象限 | 低（字體只是錦上添花） | 低 | 保留遠端載入或改用系統字體 | 小型內容站、本地市場、合規無壓力 |
| 第四象限 | 低 | 高 | 系統字體優先，閒暇再評估本機託管 | 技術力強但字體非重點、流量極大的工具站 |
這個矩陣的判讀方式是由上而下。先問自己字體策略在這個專案裡有多重要：如果字體承載品牌辨識或合規審計責任，重要性就高；如果只是讓版面好看、換不換差別不大，重要性就低。再問團隊有沒有人能長期維護 CSS 與字體檔，包含主題更新後重新檢查、字型家族調整、子集化重新產檔這類後續工作。兩個答案交會的象限，就是建議路線。落點在第三或第四象限的網站，本機託管的邊際效益很低，強行實作反而增加維護負擔；落點在第一象限的網站，手動託管能同時滿足品牌與合規雙重需求，值得投入工程資源。
第一步：從 Google Fonts 下載需要的字型（只挑會用到的字重）
要從哪裡下載 Google Fonts，又該下載哪些檔案？做法是到 fonts.google.com 搜尋目標字型，點進字型頁面後按 Download family 下載整包，但實際部署時只保留會用到的字重，通常是 Regular 400 與 Bold 700，其餘字重不要帶上網站，才能把請求數與檔案體積壓到最低。
以 Noto Sans TC 思源黑體繁中版為例，這是中文網站最常用的免費開源字型，採 SIL Open Font License 1.1，可直接商用。操作流程是進入 Google Fonts 搜尋 Noto Sans TC，點選字型進入詳細頁，再按右上角 Download family，瀏覽器就會下載一個壓縮檔。下載回來先解壓縮，下一個章節轉檔會用到。如果想多了解字型選擇的脈絡，可以參考 中文字體選擇與推薦 與 網頁字體 Webfont 完整指南，能幫你判斷這套字型適不適合自己的品牌調性。
有一點必須先講清楚：中文 web font 體積天生比英文字體大很多，因為字元數量級完全不同。每多載入一種字重等於多一個請求，建議全站只用一個字型家族加兩個字重。挑字重與後續壓縮是控制體積的兩個關鍵。實務上常見的做法是，正文用 Regular 400、標題用 Bold 700，這兩個字重涵蓋九成以上的視覺層級需求，不需要 Light、Medium、SemiBold 這類中間值。很多人會貪心地想一次載五個字重，結果行動裝置跑分直接掉一截，這在 英文字體推薦下載 與 排版與字體設計技巧 的討論裡也看得到類似的體積陷阱。
- 進入 Google Fonts 搜尋目標字型，例如 Noto Sans TC。
- 點選字型進入詳細頁，按 Download family 下載整包壓縮檔。
- 解壓縮後，只挑出會用到的字重（建議 Regular 400 與 Bold 700）。
- 其他字重暫時擱著，不要一起帶上網站。
字體轉檔：用 Transfonter 產出 WOFF 與 WOFF2
下載的字型檔要轉成什麼格式才能用在網頁上？用 Transfonter 這類線上字體轉換工具，把從 Google Fonts 下載的字型轉成 WOFF 與 WOFF2 兩種格式即可。WOFF2 壓縮率最高，是現代瀏覽器支援度最廣的首選格式；WOFF 作為舊瀏覽器備援。轉檔時只勾選會用到的 Regular 與 Bold 字重，其他選項維持預設就能開始轉換。
WOFF2 的壓縮率明顯高於 TTF 或原始 OTF，支援度已涵蓋絕大多數現代瀏覽器 [來源：〈WOFF 2.0 - caniuse〉〈https://caniuse.com/woff2〉〈2026〉]。實際操作是打開 Transfonter 官網，點 Add Fonts 上傳剛下載的字型檔，在 Formats 勾選 WOFF 與 WOFF2，其餘選項用預設值，按 Convert 開始轉換。轉完點 Download 下載，資料夾裡會有 Regular 與 Bold 各一組 woff / woff2，共四個檔案。這四個檔案就是等等要上傳到 WordPress 主機推薦與評測 裡你選的那台主機上的內容。
轉檔時有兩個小坑要避開。第一，記得只勾選實際會用到的字重，避免產生多餘檔案，這跟前面下載時的挑字重原則一致。第二，若轉出的檔案仍然過大，PageSpeed Insights 跑出本機端字體過大的警告，可改用 fontsquirrel 重新轉檔，它對字體體積的壓縮通常更積極，操作流程跟 Transfonter 差不多。轉檔工具皆為免費線上服務，不需安裝本機軟體，這對不想在電腦裝一堆工具的人很友善。順帶一提，字體轉檔概念跟 圖片壓縮工具推薦、WebP 等圖片格式比較 是相通的，都是用對格式換更小的體積，WordPress 圖片優化指南 的思維可以直接搬過來用。
- WOFF2 壓縮率最高、現代瀏覽器支援度高，是首選格式。
- WOFF 作為舊瀏覽器備援，與 WOFF2 一起產出。
- 轉檔時只勾會用到的字重（Regular 400 與 Bold 700），避免產生多餘檔案。
- 檔案過大就改用 fontsquirrel 重新轉檔，壓縮通常更積極。
- Transfonter 與 fontsquirrel 都是免費線上服務，不用在電腦裝本機軟體。
第三步：把字體上傳到 WordPress 並用 CSS 套用到網站
字體檔要放進 WordPress 哪個位置，CSS 又該怎麼寫？把四個字體檔上傳到 wp-content/uploads/fonts/ 資料夾，可透過主機商檔案管理員或 FTP 軟體。接著在 WordPress 後台的附加 CSS 或子主題的 style.css 寫入 @font-face 宣告，指向本機字體路徑並套用到 body 與標題，記得把 yourdomain.com 換成自己的網域。
上傳路徑統一放 wp-content/uploads/fonts/，方便管理且不與其他檔案混淆。上傳方式通常有兩種，第一種是主機商提供的檔案管理員工具，圖形化介面比較容易上手，不過不一定每家都有；第二種是用 FTP 軟體連線到主機後上傳，這部分可以對照 WordPress FTP 檔案上傳教學 的步驟。完整路徑範例是 https://yourdomain.com/wp-content/uploads/fonts/NotoSansTC-Regular-Alphabetic.woff2，把 yourdomain.com 換成自己的網域名稱，網域有啟用 SSL 憑證安裝教學 就用 https，沒有就用 http（強烈建議補上 HTTP 換 HTTPS 攻略，字體走 https 才不會被瀏覽器擋混合內容）。驗證方法很直接：把字體網址貼到瀏覽器網址列，能下載就代表路徑正確。
加入 CSS 有兩種方法，擇一即可。第一種是後台「外觀 > 自訂 > 附加的 CSS」，這是 WordPress 預設功能，每個網站都找得到；第二種是子主題的 style.css，推薦這個方式，因為主題更新時附加 CSS 也可能被主題改動，子主題則獨立存在不會被覆蓋。以 Astra Pro 主題完整教學 為例，套用 Astra 子主題後，在「外觀 > 佈景主題編輯器 > style.css」加上字體 CSS。如果你還沒裝子主題，可參考 WordPress 佈景主題安裝教學 的流程先建一個。@font-face 裡 src 的 url 必須填完整 https 網址，字型家族名稱與 font-weight 要對應你上傳的 Regular 400 / Bold 700。
底下是一段可直接套用的 @font-face 範本，把 yourdomain.com 換成你的網域、把檔名對應你實際轉出的檔名即可。這段程式碼的作用是先讀取本機字體路徑，再套用到 body 與標題。看不懂也沒關係，照著改網域與檔名就能用。如果你想把 CSS 基礎補起來，搭配 CSS Box Model 觀念 與 SASS 預處理器教學 會更扎實。
@font-face {
font-family: 'Noto Sans TC';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url('https://yourdomain.com/wp-content/uploads/fonts/NotoSansTC-Regular-Alphabetic.woff2') format('woff2'),
url('https://yourdomain.com/wp-content/uploads/fonts/NotoSansTC-Regular-Alphabetic.woff') format('woff');
}
@font-face {
font-family: 'Noto Sans TC';
font-style: normal;
font-weight: 700;
font-display: swap;
src: url('https://yourdomain.com/wp-content/uploads/fonts/NotoSansTC-Bold-Alphabetic.woff2') format('woff2'),
url('https://yourdomain.com/wp-content/uploads/fonts/NotoSansTC-Bold-Alphabetic.woff') format('woff');
}
body { font-family: 'Noto Sans TC', sans-serif; }
h1, h2, h3 { font-family: 'Noto Sans TC', sans-serif; font-weight: 700; }
這段範本套上去之後，還有一個常被忽略的體積優化手段：字體子集化（subsetting）。原理是字體檔內部其實收錄了成千上萬個字元的描點資料，但你的網站實際用到的字元往往只是其中一小部分。子集化就是把用不到的字元描述從檔案裡剔除，只留下真正會出現在頁面上的字。對英文網站效果有限（英文字母就那幾十個），對中文網站卻可能是體積差距最劇烈的一環，因為一套繁中字型動輒收錄上萬字元，而你全站實際用到的可能只有幾千個。
子集化有兩條路線。第一條是靜態子集，先把要保留的字元清單準備好，再用 fontsquirrel 的 Expert 模式或 pyftsubset 這類工具產出只含這些字元的字體檔，檔案會明顯縮小，但每次新增內容用到新字元就得重新產檔，維護負擔較高。第二條是動態子集，利用 CSS 的 unicode-range 屬性，把字體依字元區段切成多個小檔，瀏覽器只在頁面實際用到該區段時才下載對應檔案。Google Fonts 的動態子集就是走這條路，本機託管時可以照搬這個做法，只是要自己切分檔案並寫好對應的 @font-face。對流量大、字元用量穩定的內容站，靜態子集投報比最高；對內容變動頻繁、字元難以預估的站，動態子集比較省事。
子集化前後的體積差異會直接反映在 PageSpeed Insights 的「Reduce font size」項目。這個優化與 WordPress 圖片優化指南 的核心觀念相通：資源越大、載入越久，能砍掉的部分就該砍掉。子集化搭配前面只留兩個字重的策略，中文網站的字體總體積有機會壓到原本的幾分之一。不過要留意一個邊界：子集化若過度激進，把某些偶爾才出現的字元也剔除了，那些字元就會退回系統字體顯示，造成同一段文字裡出現兩種字型的混排，這在視覺上會很突兀。建議子集化時保留一個安全邊際，把常用標點、罕用字一併納入，避免補救成本高於體積收益。
子集化的字元清單怎麼決定：三種來源與各自的風險
做靜態子集時，最關鍵的決策是「保留哪些字元」。字元清單太大，體積壓不下來；字元清單太小，會出現混排破綻。實務上有三種來源可以組合使用。第一種是教育部頒布的常用字與次常用字表，涵蓋日常中文閱讀的絕大多數字元，是較為保守的安全選項，幾乎不會出現缺字。第二種是從自家網站實際內容採集，把所有文章、頁面、選單的文字去重後彙整成清單，這種做法最貼合實際用量、體積最小，但每次新增內容用到清單外的字元就得重新產檔。第三種是通用漢字區段，直接保留 Unicode 的 CJK 區塊或其中的常用子集，介於前兩者之間。
三種來源的取捨各有適合的站點類型。內容穩定、極少新增的官網，用第二種從自家內容採集最划算，產檔一次就能用很久。內容頻繁變動、由多位編輯發文的大型內容站，用第一種常用字表比較安全，避免新文章冒出清單外的字元導致混排。電商或工具型網站，商品名稱或介面文字常出現特殊符號、外來語、數字符號，這類站建議把常用字表加上自家採集兩條來源合併，再補上拉丁字母、數字、常用標點的全形半形版本。無論選哪一種，產出子集後都應該跑一次完整的網站預覽，逐頁檢查有沒有混排字型出現，這是驗收子集化成果的唯一可靠方法。
切斷主題與外掛的遠端 Google Fonts 連線
本機託管完成後，為什麼開發者工具還看得到 fonts.googleapis.com？因為很多佈景主題與外掛預設會自行連線 Google Fonts，你本機託管只解決了一部分。要徹底切斷遠端請求，得針對個別主題與外掛關閉其內建的 Google Fonts 載入，例如 Astra 與 Elementor 都有對應設定，或搭配 Disable and Remove Google Fonts 外掛處理。
先用瀏覽器開發者工具 Network 面板篩選 font，檢查是否仍有 fonts.googleapis.com 或 fonts.gstatic.com 的請求。Astra 主題可透過子主題函式或 Astra Pro 設定停用預設 Google Fonts，相關細節可對照 用 Astra 打造形象網站。Elementor 可在設定中關閉 Google Fonts 載入，操作脈絡跟 Elementor 頁面編輯器教學、Elementor Pro 購買與功能指南 一致。如果你用其他主流編輯器，Elementor 外掛推薦、Divi 自訂字體上傳教學、WordPress 頁面編輯教學 也能找到對應的字體管理位置。
要老實說的是：不同主題外掛的停用方法不一，沒有萬用解。理論上可用函式去 dequeue 字體，但前提是先找到主題或外掛的字體 handle ID，每個軟體的放置位置又不同，這對沒接過 WordPress 原始碼的人負擔不小。實務上，如果你不想逐一找 ID，Disable and Remove Google Fonts 外掛支援主流組合但不保證全部覆蓋 [來源：〈Disable and Remove Google Fonts on WordPress.org〉〈https://wordpress.org/plugins/disable-remove-google-fonts/〉〈2026〉]。停用後務必清除瀏覽器與伺服器快取再重新驗證，否則會看到舊的快取結果誤判失敗，這跟 快取 Cache 運作原理 講的機制是同一回事。
- 先用 Network 面板篩選 font，確認有沒有 fonts.googleapis.com 或 fonts.gstatic.com 的請求殘留。
- Astra 主題走子主題函式或 Astra Pro 設定，把預設的 Google Fonts 關掉。
- Elementor 直接在設定裡關閉 Google Fonts 載入。
- 其他主題外掛組合若不好逐一排查，交給 Disable and Remove Google Fonts 外掛統一處理。
- 停用後務必清掉瀏覽器與伺服器快取，再回頭重新驗證，避免看到舊快取誤判。
font-display 屬性深入解析：swap、optional、block、auto 的取捨
前面那段 @font-face 範本裡藏了一個關鍵屬性 font-display: swap，它決定了字體在下載完成前後的文字顯示行為。這個屬性看似只是細節，卻直接影響使用者看到的「文字閃爍」與「空白等待」，進而牽動 Largest Contentful Paint（LCP）與 Cumulative Layout Shift（CLS）這兩項 Core Web Vitals 核心效能指標。本機託管把字體收回自家主機後，font-display 才有真正發揮空間，因為你對字體檔的大小、數量、載入順序有完整控制權。
font-display 共有四個值，各自的行為差異可以用一段「字體下載期間，文字怎麼顯示」來概括。auto 是交給瀏覽器決定，多數情況等同 block；block 會先隱藏文字最長三秒（不可見期），等字體下載完才顯示，使用者看到的常常是空白後突然跳出文字；swap 會立刻用系統字體顯示文字，字體下載完再無縫替換，使用者全程看得到內容；optional 會在極短時間內嘗試載入字體，若沒趕上就用系統字體定案，背後可能繼續下載並快取，供下次造訪使用。這四種行為對應不同的體驗取向，沒有絕對的最佳解。
| font-display 值 | 下載期間顯示 | 適用情境 | 主要風險 |
|---|---|---|---|
| auto | 瀏覽器決定（多為 block） | 不確定時的預設 | 行為不可預期 |
| block | 隱藏文字最長三秒 | 字體是品牌辨識核心、不可妥協 | 空白等待損害 LCP |
| swap | 立刻用系統字體再替換 | 一般內容站、追求可讀性 | 替換瞬間的字型跳動（FOUT） |
| optional | 極短嘗試，失敗即用系統字 | 行動裝置、弱網、字體為點綴 | 多數訪客根本看不到自訂字體 |
對中文網站來說，swap 幾乎是安全牌。中文 web font 體積偏大，第一個訪客常常得等一段時間才下載完，用 swap 可以讓內容先以系統黑體或楷體顯示，避免畫面長時間留白。swap 的副作用是替換瞬間的字型跳動，這個現象稱為 FOUT（Flash of Unstyled Text），幅度通常可接受。如果你的網站把字體當作品牌靈魂，完全無法接受替換跳動，才考慮 block，但要意識到這會讓 LCP 數字變難看。optional 適合字體只是錦上添花的情境，例如只在標題用的裝飾性英文字體，此時多數訪客看到系統字也無妨。
判斷該用哪個值的簡單原則是看「字體在設計裡的份量」。份量重、無法妥協就 block；份量中、追求可讀就 swap；份量輕、純點綴就 optional。把這個判斷與前述字重挑選合起來看，字體策略就有一致的邏輯：先決定哪些字重非留不可，再決定這些字重在下載前後怎麼顯示。這兩層決策都寫進 @font-face，本機託管的字體表現才會穩定。
preload 與 preconnect：把字體載入順序排到最前面
字體檔放在本機、@font-face 也寫好之後，還有一道順序問題要處理：瀏覽器什麼時候才開始下載這些字體檔。預設情況下，瀏覽器要等解析完 CSS、發現頁面用到某個自訂字體，才會回頭去抓字體檔，這段等待會拖慢文字真正套用自訂字型的時間。preload 就是把關鍵字體檔提早到頁面一開始就下載，告訴瀏覽器「這個檔案等等一定會用到，先抓起來放著」。對用在大標題或首屏文字的字體，preload 的收益最明顯，因為這些文字直接算進 LCP。
preload 的寫法是在 head 加一行 link 標籤，rel 設為 preload、as 設為 font、加上 crossorigin 屬性，href 指向本機字體檔。crossorigin 不可省略，否則 preload 下載的檔案會跟 @font-face 實際取用的不是同一份快取，等於白抓。本機託管的好處在於這些 link 標籤指向自家網域，不再需要對 fonts.googleapis.com 做 preconnect（preconnect 的作用是提早建立到第三方網域的連線，本機託管後字體已經跟網頁同源，連線成本本來就低）。
preload 用得精準才有價值，亂用反而浪費頻寬。判斷哪些字體該 preload 的原則是「是否出現在首屏、是否為 Largest Contentful Paint 元素」。首屏標題字體值得 preload，頁尾或彈窗才用到的字體就別 preload，否則只是把用不到的檔案搶先下載，拖慢真正關鍵的資源。把 preload 與 font-display: swap 搭配，等於一方面提早抓檔、一方面先用系統字顯示，雙管齊下把文字可讀時間壓到最短。這部分若手動處理太繁瑣，WP Rocket 快取外掛完整設定 提供了字體預先載入的自動化選項，能把 preload 規則交給外掛管理。
preload 落地時有兩個技術細節容易踩雷。第一個是 crossorigin 屬性必須與 @font-face 的行為一致，預設要寫 crossorigin（等同 anonymous），若字體伺服器有特殊 CORS 設定才需要調整。少了這個屬性，瀏覽器會把 preload 下載的檔案與 @font-face 實際取用的視為兩份不同資源，等於抓了第二次，preload 形同失效。第二個是 preload 數量要克制，瀏覽器對高優先序資源有並行下載上限，一次 preload 太多字體會互相排擠，反而讓最該先抓的 LCP 字體排到後面。實務上同時 preload 的字體檔不超過兩個為原則，通常是 Regular 400 與 Bold 700 各一個 woff2 檔。
開發者工具驗證：本機字體到底有沒有生效
怎麼確認網站已經完全改用本機字體、沒有殘留遠端請求？在有標題與內文的頁面按右鍵「檢查」開啟開發者工具，切到 Network > All 並搜尋 font。若看到的是來自你自己網域的字體請求、且不再出現 fonts.googleapis.com，就代表本機託管成功；若仍殘留遠端請求，多半是快取沒清乾淨或主題外掛還沒停用。字體載入與頁面渲染密不可分，這也牽涉到 Google 怎麼處理動態渲染的 JavaScript SEO 問題，本機字體配合得當能讓初次渲染更穩定。
務必在有 h1/h2 與 p 標籤的頁面測試，才看得到字體請求，空白頁或純圖片頁面不會觸發字體載入。Network 面板搜尋 font 可快速過濾出所有字體相關請求，點擊請求項目可查看來源網址，確認是否指向本機路徑。若仍連到遠端，依序排查：瀏覽器快取、伺服器快取、主題外掛的 Google Fonts 停用設定。這三道關卡清完還有殘留，就要回去檢查是不是另一個沒注意到的外掛在偷連。搭配 PageSpeed Insights 與 GTmetrix 跑一次，字體優化相關的提醒項目應明顯減少，這也是 延遲載入提升網站速度 之外，另一個會直接影響 爬取預算優化策略 與 站內 SEO 優化攻略 表現的細節。
說到底，驗證這一步常被省略，但它是判斷到底有沒有做成功的唯一方法。實務上常見的失誤是上傳完字體就收工，結果開發者工具一開，遠端請求還是一整排，原因是主題根本沒吃到那段 CSS。所以這一步是「做了才算數」的驗收關卡，不能只是順便看一下。想長期追蹤字體優化後的索引與點擊變化，把 Google Search Console 接起來看報表，比憑感覺判斷更可靠。
上線前檢查表：十個項目跑完才能放心部署
把驗證步驟整理成可逐項打勾的檢查表，能在上線前一次抓齊所有遺漏，避免上線後才在debug。底下這十個項目涵蓋檔案、路徑、CSS、請求、效能、合規六個層面，建議照順序跑一遍。
- 四個字體檔（Regular woff2/woff、Bold woff2/woff）皆已上傳到 wp-content/uploads/fonts/。
- 把字體檔網址貼到瀏覽器網址列，能正常下載，確認路徑與權限無誤。
- @font-face 的 src 網址使用完整 https，font-family 名稱與 font-weight 對應實際檔案。
- CSS 寫在子主題 style.css，主題更新不會覆蓋。
- 開發者工具 Network 面板篩選 font，不再出現 fonts.googleapis.com 或 fonts.gstatic.com 請求。
- 清除瀏覽器快取與伺服器快取後重新驗證，結果一致（排除快取干擾）。
- https 頁面所有字體請求皆走 https，無混合內容警告。
- PageSpeed Insights 行動與桌機分頁各跑一次，字體相關提示項目明顯減少。
- LCP 與 CLS 數值與優化前對比，確認無退化或明顯改善。
- 逐頁預覽含標題、正文、選單的頁面，確認無混排字型、無缺字。
這十項跑完若有任何一項未過，先回到對應章節排查再上線。第十項的逐頁預覽尤其常被省略，因為它需要人工檢視、無法自動化，但子集化或路徑錯誤造成的混排、缺字，只有人工眼睛看得出來。把這張檢查表與前面的七步流程、疑難排解表放在一起，整個本機託管從實作到驗收就有完整的作業地圖。
什麼情況不該本機託管：誠實畫出邊界
本機託管被講成萬靈丹，但它確實有不適用的情境，硬套反而徒增負擔。第一種是字體用量極度零散的小型內容站，全站只用一個系統字體其實就足夠，連自訂字體都不必，這種站本機託管一個檔案都是多餘。第二種是團隊完全沒有人能維護 CSS 與字體檔，這時與其放著沒人管的本機檔案過時腐化，不如交給 OMGF 外掛統一處理。第三種是網站本身已經極度依賴 Google Fonts 的動態子集機制，硬要改成靜態本機檔案，反而失去動態子集按需下載的優勢，這種情況下保留遠端載入搭配合規同意橫幅，可能是更務實的折衷。
合規面的取捨也要分清楚層級。GDPR 的爭議核心是「未經同意把訪客 IP 傳給 Google」，這在收得到歐盟流量的網站是實質風險。若你的網站服務範圍完全不碰歐盟市場，且當地法規對第三方字體請求沒有同等要求，那麼合規動機就弱很多，本機託管的價值會回到純粹的速度與可控性。這不是叫你忽略合規，而是提醒合規壓力有地域差異，決策前先確認你的訪客組成與適用法規，免得為了一個不存在的風險耗費不成比例的工程成本。
行動優先時代的字體策略：把字體體積當行動流量問題來處理
字體策略不能脫離「多數訪客來自行動裝置」這個現實。當全球行動流量已佔整體網站流量的多數，而 Google 又早已全面採用行動優先索引（mobile-first indexing），用行動版頁面作為索引與排序的主要依據，字體在行動裝置上的表現就直接關係到排名。行動裝置的網路條件、CPU 運算能力、字體快取空間都與桌機有落差，桌機上跑得很順的字體設定，搬到中階手機加上 4G 環境可能完全變樣。本機託管在行動場景的價值更明顯，因為它能確保字體檔走自家 CDN 或主機的路徑，傳輸距離可控，不受 Google 字體 CDN 節點調度的影響。
行動裝置上對字體策略要採取比桌機更嚴格的標準。桌機可以接受載入三個字重，行動版應該精簡到一個正文用字重加一個標題用字重；桌機可以容納較大的字體檔，行動版則應該把字體子集化做到位，只保留實際用到的字元。font-display 在行動版的選擇也偏向 swap 或 optional，因為行動裝置上的空白等待對使用者體驗的傷害更直接，訪客常常直接關掉頁面。檢視行動表現的方法是用 PageSpeed Insights 的行動分頁跑一次，特別注意 LCP 與 CLS 兩項，這兩項是字體影響最深的指標。行動字體策略也與 延遲載入提升網站速度 的整體思維相通，都是把有限頻寬與運算資源留給首屏關鍵內容。
- 行動版字重精簡到一個正文用、一個標題用，桌機可放寬。
- 行動版字體子集化務必做，否則體積會拖垮行動跑分。
- 行動版 font-display 偏向 swap 或 optional，避免空白等待造成跳出。
- 用 PageSpeed Insights 行動分頁驗證 LCP 與 CLS，這兩項受字體影響最深。
- 本機託管搭配自家 CDN，能讓字體檔的傳輸距離在行動場景可控。
字體優化優先序評分卡：把力氣花在報酬最高的地方
字體優化有很多手段，但報酬差異很大。把常見手段依「對 Core Web Vitals 的影響」與「實作成本」兩個維度攤開，能幫你排出先後順序。影響大、成本低的動作要先做；影響大、成本高的次之；影響小的不必急。這個評分卡是把字體相關的優化選項整理成可比較的形式，比憑直覺決定更踏實。
| 優化手段 | 對 Core Web Vitals 影響 | 實作成本 | 建議優先序 |
|---|---|---|---|
| 只留 Regular 與 Bold 兩個字重 | 高（減少請求與體積） | 低 | 最優先 |
| 字體本機託管（切斷遠端） | 中（合規 + 連線成本） | 中 | 第二 |
| font-display: swap | 高（改善 LCP 體感） | 低 | 最優先 |
| 字體子集化 | 高（中文體積劇減） | 中高 | 第三 |
| preload 首屏字體 | 中（提前下載） | 低 | 第二 |
| CDN 推送字體到邊緣 | 中（縮短下載距離） | 低（若已有 CDN） | 第二 |
從評分卡可以看出，影響最大、成本最低的兩個動作是「只留兩個字重」與「font-display: swap」，這兩項應該在第一天就完成。本機託管與 preload 屬於中段，做完前面兩項再來做。子集化雖然影響高，但成本也高，建議等基礎打好、確認子集化的維護流程跑得順再投入。排序的另一個好處是，當你時間有限、只能做一兩件事，照這個表挑報酬最高的動作，總產出會比東做一點西做一點來得紮實。
本機託管之外：搭配快取外掛把字體優化做到位
字體已經本機託管了，為什麼 PageSpeed 還是提到字體優化？因為本機託管解決的是「外部請求」問題，但字體的預先載入（preload）、font-display: swap、快取策略這些仍需靠 WordPress 快取外掛來處理。像 WP Rocket 這類工具能補上本機託管做不到的最後一哩路，兩者搭配才能把字體相關的效能分數拉滿。網頁速度對實際轉換的影響有公開案例佐證：日本電商 Rakuten 24 投入 Core Web Vitals 優化後，每位訪客營收提升 53.37%、轉換率提升 33.13% [來源：〈web.dev (Google) - Why does speed matter?〉〈https://web.dev/articles/why-speed-matters〉〈2026〉]。同一份案例資料裡，Vodafone 的 LCP（Largest Contentful Paint）改善 31%，帶動銷售額提升 8% [來源：〈web.dev (Google) - Why does speed matter?〉〈https://web.dev/articles/why-speed-matters〉〈2026〉]。LCP 與字體的關係特別密切，因為首屏大標題文字若套用自訂字體，字體下載完成前那個元素就不會算作完成繪製，直接拖住 LCP 數字。這兩個案例說明了效能分數不是面子工程，而是會折現的商業指標。要知道這些分數怎麼算、又卡在哪一關，先弄懂網頁速度是怎麼定義的，才知道 preload 與 swap 真正補上的是哪段時間。
本機託管與快取外掛是互補關係，不是二選一。WP Rocket 可處理字體預先載入、快取規則與延遲載入等進階設定 [來源：〈WP Rocket – Preload fonts〉〈https://docs.wp-rocket.me/article/1716-preload-fonts〉〈2026〉]。font-display: swap 讓文字先以系統字體顯示，避免字體載入時的空白閃爍（FOIT），這個屬性已經寫進前面那段 @font-face 範本裡。快取外掛的選擇可對照 WordPress 快取外掛推薦比較、WP Rocket 快取外掛完整設定，搭配 CDN 網站加速機制 還能把字體檔推到邊緣節點，縮短各地訪客的下載距離。整體速度的基礎還是主機，這部分可參考 虛擬主機完整指南、虛擬主機類型比較、Cloudways 雲端主機教學，依流量與預算挑選。
退一步看整件事的位置。本機託管是字體優化的一環，不是全部。優質 WordPress 主機是整體速度的基礎，字體優化建立在主機回應速度之上。新手可從共享主機起步，例如 Bluehost 虛擬主機教學、A2 Hosting 主機評價、SiteGround 主機評測 都是不錯的入門選項；流量大或追求穩定者考慮 VPS 或雲端主機。字體之外，圖片、JS、CSS 也都會吃效能分數，把 SEO 友善網站架構 與 Rank Math SEO 外掛教學、WordPress SEO 外掛推薦、WordPress 架站與 SEO 優化、WordPress SEO 必做設定 串起來看，才不會顧此失彼。想用 Fonts Ninja 找靈感可看 Fonts Ninja 字體辨識工具，想換主題可參考 WordPress 佈景主題推薦，資安防護別忘了 WordPress 資安防護外掛評比，DNS 與網域設定則對照 DNS 網域指向設定 與 網域申請購買指南，小工具與側邊欄可看 WordPress 小工具與側邊欄設定。
回顧一下整條鏈：下載只挑會用到的字重、轉成 WOFF2/WOFF、上傳到 wp-content/uploads/fonts/、用 @font-face 套用、停用主題外掛的遠端載入、開發者工具驗證、再補上快取外掛的 preload 與 swap。七步走完，字體這塊才算穩下來。合規導向的品牌站做完這套，訪客 IP 不再經由字體流向 Google，合規審計時也有一份能逐項交代的字型清單，速度分數的提升則是順帶拿到的好處。
疑難排解檢查表：本機託管常見失敗與對應解法
本機託管的步驟不算複雜，但每一步都有人踩雷。把最常回報的失敗情境與對應解法整理成檢查表，能在出問題時快速定位，省下逐項猜測的時間。這張表涵蓋路徑、權限、CSS 載入、主題外掛衝突、快取、混合內容這幾個主要失敗類型，涵蓋了實務中絕大多數的回報案例。
| 症狀 | 最可能原因 | 對應解法 |
|---|---|---|
| 字體檔網址貼到瀏覽器打不開 | 路徑錯誤或檔案沒上傳到正確資料夾 | 核對 wp-content/uploads/fonts/ 是否存在、檔名是否與 CSS 一致 |
| 字體檔能下載但頁面沒套用 | @font-face 的 src 網址與實際路徑不符，或 font-family 名稱對不上 | 逐字核對 src url 與 font-family，留意大小寫與副檔名 |
| 開發者工具看到 403 Forbidden | 主機對字體資料夾設了存取限制，或權限設定過嚴 | 檢查資料夾權限（通常 755）與主機的 hotlink 保護規則 |
| 字體在 http 頁面載入、https 頁面失效 | 混合內容（mixed content）被瀏覽器擋下 | @font-face 的 src 一律用完整 https 網址 |
| 改完 CSS 畫面沒變 | 瀏覽器或伺服器快取沒清 | 清除瀏覽器快取、清除快取外掛、必要時加 cache-busting 參數 |
| Network 仍看到 fonts.googleapis.com | 主題或某個外掛仍在遠端載入 | 逐一停用外掛定位元兇，再用對應設定或 Disable and Remove Google Fonts 處理 |
| 子主題 CSS 沒生效 | 子主題未正確排隊（enqueue），或父主題樣式覆蓋 | 確認 functions.php 有 wp_enqueue_style 子主題樣式表，且順序在父主題之後 |
| PageSpeed 仍提示字體過大 | 字重過多或未做子集化 | 只留 Regular 與 Bold，再評估子集化或換用更積極的轉檔工具 |
這張表的用法是對照症狀直奔解法，不必從頭排查。多數失敗集中在路徑、快取、混合內容這三類，先把這三項排除通常能解掉七成問題。剩下三成屬於主題外掛的個別衝突，需要靠逐一停用定位，這也是 Disable and Remove Google Fonts 這類外掛存在的價值：在你不想逐一找 handle ID 時，它提供一條快速兜底的路徑。把這張表與前面的七步流程放在一起看，整個本機託管的失誤點就有一張完整地圖可循。
常見問題
為什麼要在 WordPress 本機託管 Google Fonts？
把字體檔放回自家伺服器，既可減少對 fonts.googleapis.com 的遠端請求、提升載入速度，也能停止把訪客 IP 傳給 Google，這正是 GDPR 判決關注的爭議點。
本機託管 Google Fonts 對 GDPR 合規有幫助嗎？
有。2022 年起德國多起法院判決認定，未經同意經由 Google Fonts 回傳 IP 已構成個資跨境傳輸，違反 GDPR。本機託管切斷了這條資料流，是合規導向網站的直接解法。
Google Fonts 要轉成什麼格式才能用在網頁上？
轉成 WOFF2 與 WOFF 兩種即可。WOFF2 壓縮率最高、現代瀏覽器支援度最廣，是首選；WOFF 作為舊瀏覽器備援，用 Transfonter 或 fontsquirrel 都能免費線上轉檔。
OMGF 外掛和手動本機託管哪個比較好？
新手或想快速上線選 OMGF，安裝即用；想精準只留 Regular 400 與 Bold 700、或合規審計需求高，選手動。兩者差別在字重控制粒度與外掛負擔。
WordPress 字體要上傳到哪個資料夾？
建議統一放 wp-content/uploads/fonts/，方便管理且不與其他檔案混淆。可透過主機商檔案管理員或 FTP 軟體上傳。
如何用 CSS 讓 WordPress 套用本機字體？
在後台「附加的 CSS」或子主題 style.css 寫入 @font-face，src 指向本機字體的完整 https 網址，再用 font-family 套用到 body 與標題即可。
主題更新會覆蓋我加的字體 CSS 嗎？
若 CSS 寫在子主題的 style.css，主題更新不會覆蓋。若直接改父主題檔案，則會在更新時被洗掉，所以建議走子主題。
本機託管 Google Fonts 真的能提升網站速度嗎？
能減少遠端 DNS 與下載時間，但 preload、font-display: swap、快取策略仍需快取外掛處理。本機託管是基礎，搭配 WP Rocket 才能把分數拉滿。
font-display 該設成 swap 還是 block？
多數中文內容站建議 swap，讓文字先以系統字體顯示、字體下載完再替換，避免長時間留白。只有當字體是品牌辨識核心、完全無法接受替換跳動時，才考慮 block，但要承擔 LCP 變差的代價。
中文字體檔太大有什麼壓縮方法？
兩個方向：一是只留 Regular 與 Bold 兩個字重，避免一次載入整套字型家族；二是做字體子集化，把用不到的字元描述剔除，可選靜態子集（一次產檔）或動態子集（搭配 unicode-range 按需下載）。
哪些網站不適合本機託管 Google Fonts？
三種情況：只用系統字體就夠的小站、完全沒人能維護 CSS 與字體檔的團隊、以及重度依賴動態子集機制的網站。若網站完全不碰歐盟市場、當地也無同等法規要求，合規動機較弱，本機託管的價值會回到純速度考量。
不想本機託管，改用同意橫幅合規嗎？
技術上可行，實務上是折衷方案。在訪客同意前完全暫停載入 Google Fonts，同意後才發出請求，能符合 ePrivacy 與 GDPR 的同意要求。但這依賴同意管理平台正確運作，且首屏文字在同意前會以系統字體呈現，視覺跳動明顯。本機託管的優勢在於不需訪客同意即可載入自訂字體，體驗更順暢，合規也更直接。
字體檔放本機後，還需要搭配 CDN 嗎？
看訪客的地理分布。若訪客集中在單一地區、主機就在該區，CDN 對字體的邊際效益有限。若訪客分散多國或跨洲，CDN 能把字體檔推到各地邊緣節點，縮短下載距離，對行動裝置與 LCP 的幫助最明顯。CDN 不改變本機託管的合規價值，只是進一步壓低傳輸時間。
子主題的 style.css 與後台附加 CSS，字體該寫在哪？
優先寫子主題的 style.css。附加 CSS 雖然方便，但有些主題在更新或切換自訂選項時會清空或覆蓋附加 CSS 的內容，穩定性低於子主題。子主題獨立存在，主題更新不影響，是長期維護字體 CSS 的正解。兩者只能擇一，重複寫會造成規則衝突。