WordPress 本機託管 Google Fonts 教學：加速合規

本機託管 Google Fonts 是什麼？先把核心觀念講清楚

其實不少人都有過這種經驗：網站已經上了快取外掛、圖片也壓過了，PageSpeed Insights 的分數卻仍不理想。這時可以從 Network 面板確認 Google Fonts 是否形成額外請求或延後文字顯示，而不是先假設它一定是主要瓶頸。

本機託管 Google Fonts（local hosting Google Fonts）講白了就一句話：把字型檔從 Google 的伺服器，搬到你自己的網站伺服器上。原本瀏覽器要跑去 fonts.googleapis.com 拿 CSS、再跑去 fonts.gstatic.com 下載 woff2 字型檔，現在全都在你自己的網域底下完成，一個第三方請求都不發。

這件事在英文圈已經講了好幾年，中文圈卻還是被嚴重低估。不少 WordPress 站長聽到「字型也會拖累速度、還可能踩到隱私法規」的第一反應都是：蛤，字型？對，字型。而且這個問題通常不是出在你挑的字型，而是出在你不知道自己同時載入了幾套。

重點摘述

• 本機託管 Google Fonts 就是把字型檔從 Google 搬到你自己的伺服器，零第三方請求。
• 兩個常見考量：減少第三方字型依賴，以及避免字型請求把訪客 IP 等連線資訊送往 Google。
• 英文站幾乎無腦該做；中文站要想清楚，因為中文字型檔太大，本機託管反而可能更慢。
• 三條路線選一條：OMGF 外掛（最省事）、完全停用改系統字型（最快、最推薦給中文站）、手動自架 woff2（完全控制）。
• 做完一定要驗證：Network 面板看請求是否符合預期，並分別檢查桌面與行動裝置資料。

兩個你必須現在就正視的理由

第一個是效能。Google Fonts 的常見載入方式會向不同網域取得 CSS 與字型檔，可能增加連線與渲染成本；瀏覽器快取、preconnect、字型大小與原本的主機速度都會影響結果，因此本機託管不保證更快。web.dev 在〈Why does speed matter?〉（2026）指出速度會影響使用者體驗與轉換，實際改善仍要以前後測為準。

第二個是隱私與法遵。網站向 fonts.googleapis.com 或 fonts.gstatic.com 取得資源時，Google 會收到 IP 位址、要求的網址與瀏覽器相關資訊；Google 表示 Fonts API 不會設定 cookie，也不會把這些資料用於個人資料建模或定向廣告。是否符合 GDPR，仍要看網站適用範圍、處理目的與合法基礎；本機託管則能避免這一段對 Google 的字型請求，相關說明見 Google Fonts 的隱私 FAQ（2026 年 8 月查閱）。

把字型搬回自己家，這兩個問題一次解決。下面會一步步帶你做。如果你想先建立字型的整體概念，可以參考 網頁字體 Webfont 完全指南。

為什麼歐洲一連串判決，讓全世界 WordPress 站長急著搬字型

2022 年德國慕尼黑地方法院曾在特定個案中，認定網站透過遠端 Google Fonts 傳送訪客 IP 位址而欠缺適當合法基礎。這是一項地方法院個案，不能直接推論所有網站或所有司法管轄區都必然違法；是否需要同意，也要看是否有其他適用的合法基礎。

關鍵不在於 Google 拿這些 IP 做了什麼，而在於「傳輸這件事本身就發生了」。你不需要證明 Google 有沒有偷看、有沒有拿去打廣告，光是「訪客的個人資料離開了你的網站、進到了第三方的伺服器」，在沒有合法基礎的前提下，就已經踩線。

這起案件讓遠端字型的資料傳輸成為合規檢查項目之一。與其用單一判決製造恐慌，更實際的做法是盤點第三方請求、確認適用法規與合法基礎，再決定是否改成本機託管。

台灣站長該不該緊張？務實的視角

台灣不是 GDPR 的直接管轄區，所以你今天不會因為這件事收到德國法院的傳票。但是有幾個情境，你還是會想在這裡先處理好：

• 你向歐盟境內個人提供商品或服務，或監測其行為：非歐盟組織也可能落入 GDPR 的地域適用範圍；只有偶然出現歐洲訪客，並不當然代表 GDPR 適用（見 European Commission 的說明）。
• 你在做品牌形象、走國際市場：一個連字型隱私都處理好的網站，在供應鏈盡職調查時就是加分，這在接外單時特別有感。
• 你單純想讓網站更快：就算完全不考慮隱私，本機託管對速度也是淨正向，這個理由就夠了。

實務上的建議是這樣：不要被「GDPR 求償」嚇到亂拆一通，而是把它當成一個契機，順手把字型載入這塊長期被輕忽的效能債務一次清乾淨。對台灣站長來說，速度那條理由通常比法規那條更實際，但兩者的解法是同一個。退一步想，把第三方依賴降到最低本來就是一種穩健的網站經營策略，今天出問題的是 Google Fonts 的隱私爭議，明天可能是另一個第三方資源。養成「能用本機資源就用本機資源」的習慣，你的網站會比同業更抗折騰。

先別急著動手：用一分鐘診斷你的網站到底背了幾包字型

這是最多人跳過、卻最該先做的一步。在動手優化之前，先搞清楚你到底載入了多少字型，否則你只是在優化一個你根本不了解的系統。

以一個律師事務所的 WordPress 網站為例：網站是用一套市售輕量主題搭配頁面編輯器拉起來的，字型設定看似乾淨，實際打開開發者工具卻會發現有四、五個字重在輪流跟 Google 要資源，主題招牌字型、編輯器預設字型、再加幾個外掛各自帶進來的，全疊在一起。站長自己完全不知道，因為後台看起來什麼都沒設定。

這就是 WordPress 字型問題最棘手的地方：沒有任何單一來源，是疊加的。主題貢獻一份、頁面編輯器貢獻一份、表單外掛貢獻一份、快取外掛可能又多包一層，最後你的首頁同時跟 Google 要六、七個字型檔，而你以為你只選了一個字體。

診斷三步驟：任何人都能做

1. 打開 Chrome 開發者工具的 Network 面板，篩選 fonts，重新整理頁面，看列出來幾個請求、每個檔案多大、來自哪個網域。
2. 勾選 Disable cache再重新整理一次，這才是訪客第一次造訪時的真實載入狀況，不是你被快取過的版本。
3. 用 PageSpeed Insights 跑一次，查看診斷、要求樹狀圖與實際字型請求；報告項目名稱可能隨 Lighthouse 版本調整。

做完這三步，你大概會得到三種結果之一：只有一兩個字型請求（恭喜，你主題很節制）、五六個以上（最常見，疊加效應）、或是數十個（通常是某個外掛把整套字型家族都拉進來了）。

一個字重到底要花你多少？把成本算清楚

很多人對「多載入一個字重」沒有感覺，因為後台不會告訴你代價。這裡把它換算成你看得懂的數字。以一個常見的英文字型為例，每個字重的 woff2 檔案大約落在這個區間：

項目	英文字型（單字重）	中文字型（完整檔）
單一檔案大小	20 到 40 KB	3 到 12 MB
載入五個字重	約 100 到 200 KB	根本不可能這樣載
額外的 CSS 請求	1 個跨網域請求	視分片策略而定
對 LCP 的影響	視載入策略與快取而定	視字型檔大小、分片與預載策略而定

看出問題了嗎？英文字型就算你偷懶載了五個字重，總共也不過一兩百 KB，本機託管之後更是無痛。但中文字型只要載一個完整檔，就是英文字型的幾百倍。回過頭，後文會強烈建議：中文走系統字型、英文才考慮本機託管，兩套邏輯不能混為一談。

先記下你看到的數字，做完後面優化之後再回來量一次，你才會知道到底改善了多少。沒有前後對比，所有「變快了」的感覺都只是主觀。完整的測量工具比較可以看 網站速度測試工具。

三條路線，挑一條走：本機託管、完全停用，還是手動自架

診斷完之後，你會面對一個關鍵抉擇。很多人一頭栽進「本機託管」，結果發現對自己的網站根本是殺雞用牛刀，或反過來，明明該徹底停用卻只做了一半。下面用一張表幫你想清楚：

你的情況	建議路線	核心邏輯
品牌視覺強烈依賴特定字型（例如用了某個主題的招牌字型，或設計稿指定）	本機託管（OMGF 或手動）	保留視覺一致性，但把請求搬回自己家
網站以中文內容為主，英文字型只是裝飾	完全停用 Google Fonts，改系統字型	中文本來就不該靠 Google Fonts，系統字型更快更省事
訪客幾乎都在歐洲、或你有合規壓力	本機託管（任何一條都行，重點是零第三方請求）	法遵是硬需求，不是選配
純部落格、個人站、不在乎視覺一致性	完全停用	用系統字型堆疊，零成本零風險
已經有完整的字型資源、懂一點 CSS	手動自架 woff2	完全控制，沒有外掛依賴

下面會把三條路線分別講清楚，你照自己的情況對號入座就好。在深入每一條之前，先用一張表把三條路線的代價擺在一起比，你會更清楚自己在交換什麼：

路線	速度提升	實作難度	視覺忠實度	長期維護
OMGF 本機託管	中高	低（裝外掛）	高，保留原字型	低，偶爾重掃
完全停用改系統字型	最高	極低（一鍵）	中，改用各平台原生字型	極低
手動自架 woff2	高	中高（要寫 CSS）	最高，完全自訂	中，主題更新要留意

這張表要傳達的重點只有一個：速度與控制力往往反向。最慢、最麻煩的手動路線給你最大的控制權；最快、最省事的系統字型路線則要求你放棄對視覺的絕對控制。沒有哪一條是「正確答案」，只有「適合你現況的答案」。把你的品牌需求、技術能力、可投入的維護時間攤開來，答案就會浮現。

路線一：用 OMGF 外掛，五分鐘把字型搬回自己家

絕大多數 WordPress 站長，這條路線就夠了。OMGF（全名 Optimize My Google Fonts）做的事很單純：掃描你的網站，把所有跟 fonts.googleapis.com 要的 Google 字型，自動下載到你的伺服器、改寫 CSS 指向本機路徑、順便幫你處理 font-display 與預載（見 OMGF 在 WordPress.org 的頁面）。

換句話說，你不用手動下載字型、不用改 @font-face、不用管路徑，外掛幫你把前面診斷出來的那一整串第三方請求，全部本土化。

設定時要特別注意的三個地方

OMGF 裝起來雖然是傻瓜模式，但有幾個設定強烈建議你手動確認，否則優化效果會打折：

• Font-display 設定：選 swap。這代表瀏覽器會先用系統字型把文字顯示出來，等字型下載完再替換，避免訪客盯著空白等字型。
• Preload 設定：開啟預載，但只針對頁面實際用到的字型預載，不要預載整個字型家族，否則反而拖慢初始載入。
• Subsets（子集）：如果字型支援多語系，只勾你實際用到的子集（例如 latin），不要把 cyrillic、greek 全勾進來，那些你用不到的字形只是在浪費頻寬。

OMGF 適合的人是：想保留 Google Fonts 的視覺效果、但又不想處理 CSS 細節、也不想再跟第三方伺服器打交道。它的免費版對中小型網站已經足夠，付費 Pro 版多了多站網路支援與更細的控制。

如果你的站是用 Astra 這類主題架的，搭配 Astra Pro 完整教學裡的主題設定一起調，字型這塊通常很快就能收拾乾淨。

路線二：直接停用 Google Fonts，改用系統字型堆疊

這是實務上最推薦、卻最少人認真考慮的路線。很多時候，你根本不需要 Google Fonts，尤其是中文內容網站。

Disable and Remove Google Fonts 這個外掛做的事更簡單：直接把 WordPress 主題與外掛注入的 Google Fonts 連結整個移除，讓網站回退到系統字型。裝了、啟用、結束，沒有任何設定頁面。

系統字型堆疊為什麼常常是更好的選擇

「系統字型堆疊」（system font stack）的意思是，你不用任何字型檔，直接讓瀏覽器用使用者作業系統內建的字型來顯示文字。Windows 用微軟正黑體或新細明體、macOS 用蘋方、Android 用 Noto Sans CJK、iOS 一樣是蘋方。

這條路線的好處是壓倒性的：

• 不必下載 Web Font，可減少字型相關傳輸；對 Core Web Vitals 的實際影響仍要測量。
• 移除 Google Fonts 第三方請求，但網站上的分析、影音或其他第三方服務仍要各自盤點，不能據此宣稱整站法遵問題歸零。
• 讀者體驗更一致，文字會用讀者自己裝置上最熟悉的字型顯示，銳利、清晰、不模糊。
• 零維護成本，不用管字型授權、不用更新字型檔、不用擔心外掛衝突。

說真的，如果你經營的是內容站、部落格、知識型網站，讀者來看的是你的文字內容，不是你用了多漂亮的字體。把字型這層裝飾拿掉，換來的是更快的速度與更穩定的法遵狀態，這個交換幾乎永遠划算。

給你一個可以直接抄的繁體中文系統字型堆疊，把它放進你的 CSS，每個主流平台都會回退到該平台上最好的中文字型：

body {
  font-family:
    -apple-system, BlinkMacSystemFont,
    "Microsoft JhengHei", "PingFang TC", "Noto Sans TC",
    "Segoe UI", Roboto, sans-serif;
}

這段寫法的邏輯是：macOS 與 iOS 會優先用蘋方（PingFang TC）、Windows 會用微軟正黑體（Microsoft JhengHei）、Android 與其他平台回退到 Noto Sans TC，最後才是通用 sans-serif。訪客完全不用下載任何字型檔，文字卻能在每個平台上都用最銳利、最適合螢幕顯示的字型呈現。

中文網站尤其該認真考慮這條路線，原因後文會詳細講。如果你想深入了解中文字型的選擇邏輯，可以參考 中文字體設計指南。

路線三：手動自架 woff2，完全控制、完全負責

如果你不想依賴任何外掛、或你的字型需求比較特殊（例如用了 Google Fonts 之外的商業字型），那就走手動路線。這條路比較長，但換來的是完全的控制權。

四個步驟，從零到本機託管

1. 取得字型檔：從 Google Fonts 下載你需要的字型，記得只挑實際用到的字重，別整個家族抓下來。你也可以用 google-webfonts-helper 這類工具產生指定字重的下載包。
2. 轉成 woff2：依 caniuse 的資料，現代瀏覽器全部支援 WOFF 2.0 格式，它的壓縮率比 woff 高出約三成，檔案更小、載入更快。除非你要支援非常老的瀏覽器，否則只提供 woff2 就夠了。
3. 上傳到主題或子主題目錄：放在 /wp-content/themes/你的主題/fonts/ 之下，建議用子主題（child theme）以免主題更新時被覆蓋。如果你對檔案傳輸不熟，WordPress FTP 教學有完整的步驟。
4. 寫 @font-face 規則：在你的 CSS 裡宣告字型來源，記得加上 font-display: swap。一個最小的範例長這樣：

@font-face {
  font-family: 'MyFont';
  src: url('/wp-content/themes/child/fonts/myfont.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

寫好之後，到主題或 CSS 入門相關的樣式設定裡，把原本指向 Google Fonts 的 font-family 換成你的本機字型名稱，就完成了。

可變字型：用一個檔案搞定所有字重

走手動路線時，有一個現代的選擇能讓你大幅降低請求數，那就是可變字型（variable fonts）。傳統字型是「一個字重一個檔案」，你用到 Regular、Medium、Bold 三個字重，就要下載三個 woff2、發三個請求。可變字型把所有字重打包進同一個檔案，透過 font-weight 的數值（例如 400、500、700）或 font-variation-settings 來動態切換。

對本機託管來說，這個好處是雙重的：第一，請求數從好幾個縮成一個；第二，總檔案大小通常比「多個靜態字重加起來」還小，因為字型之間共用了大量資料。Google Fonts 已經為多數熱門字型提供了可變版本，下載時選 variable 那個選項就行。

使用方式跟一般 @font-face 幾乎一樣，差別只在你可以自由指定任何字重數值：

@font-face {
  font-family: 'MyVarFont';
  src: url('/wp-content/themes/child/fonts/myvarfont.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-display: swap;
}

font-weight: 100 900 這行是告訴瀏覽器，這個字型支援從 100 到 900 之間的任何字重。之後你在 CSS 裡寫 font-weight: 350 或 font-weight: 720 都能正常顯示，這在傳統靜態字型是做不到的。

可變字型的限制是舊版瀏覽器支援較弱，但 2026 年的現在，主流瀏覽器都已經完整支援，除非你的流量分析顯示有顯著比例的非常舊瀏覽器，否則這幾乎是穩賺的選擇。一個常見的誤解是以為可變字型檔案會比靜態字型大很多、拖累載入，實際上單一可變字型檔通常只比一個靜態字重稍大，卻能取代四五個字重的需求，整體下載量反而是大幅下降的。把帳算清楚，你就會發現這個取捨幾乎沒有缺點。

手動路線最常被略過的一個細節：MIME type

很多人 woff2 上傳了、CSS 也寫了，字型卻載入失敗，打開 Network 看到一個 403 或是「wrong MIME type」的錯誤。原因多半是伺服器沒有正確回報 woff2 的 MIME type。正確的設定是 font/woff2，Apache 伺服器可以在 .htaccess 加一行 AddType font/woff2 .woff2，Nginx 則在 mime.types 確認有 font/woff2 woff2; 這條。

這個坑不踩過一次很難記得，因為錯誤訊息不明顯，你會以為是路徑錯了而檢查半天。

中文網站的特殊難題：Noto Sans TC 一顆十幾 MB，本機託管反而更慢

這是最值得講、也是中文圈教學幾乎都跳過的一段。本機託管 Google Fonts 對英文字型是淨賺，對中文字型卻可能是淨虧，關鍵就在字型檔的大小。

英文字型只有 26 個字母加符號，一個字重通常 20 到 40 KB，本機託管幾乎零負擔。但中文字型要涵蓋成千上萬個漢字，一套 Noto Sans TC 的完整字型檔可以高達 10 MB 以上。你把這種怪獸搬到自己伺服器上、還沒做任何處理就叫瀏覽器下載，那根本是把原本「跟 Google 要一個聰明的分片字型」換成「下載一整顆十幾 MB 的巨獸」，速度只會更慢。

Google Fonts 的部分 CJK 字型 CSS 會用 unicode-range 切成多個子集，瀏覽器只下載頁面字元需要的分片；這不是伺服器為每一頁即時產生專屬字型。自行本機託管時如果只放一個完整字型檔，可能失去原有分片優勢；若保留相同的子集 CSS 與檔案，則不一定會失去。

中文網站的務實建議

所以對中文內容站，建議非常明確：

• 中文內文可先評估系統字型堆疊，讓讀者裝置使用既有中文字型，通常能省下可觀的字型傳輸，但仍要檢查品牌與跨平台顯示。
• 如果一定要用特定中文字型，可評估子集化（subsetting）並只保留需要的字元。實際縮減幅度取決於字型與字元集，新內容加入新字時也要更新子集。
• 英文字型可以安心本機託管，因為檔案小、效益明確。很多品牌的 logo、標題用的是英文字型，這部分該搬就搬。

子集化怎麼做？兩條務實路線

子集化的意思是「把字型檔裡你用不到的字元全部砍掉，只留下實際會出現在你網站上的字」。對中文字型來說，這個動作的效益是巨大的，因為一套完整字型動輒收錄兩三萬個漢字，但你整個網站實際用到的可能只有兩三千個。

常見的工具有兩類。第一類是掃描你整個網站的 HTML 與 CSS，統計實際出現的字元，然後產生只包含這些字的字型檔，例如 fonttools 的 pyftsubset、或是 font-spider 這類工具。優點是徹底，缺點是每次新增大量內容都要重跑一次，否則新字會顯示成方塊。

第二類是依頻率切分的「常用字子集」，例如只保留教育部公布的常用國字。這種做法不用掃描網站、也不用定期重產生，但覆蓋率不是百分之百，偶爾會遇到缺字。對內容可控的小站，第一類比較精準；對內容會持續擴增的站，第二類比較省事。

不管哪一類，前提都是你已經評估過「真的需要這個中文字型嗎」。如果系統字型就能滿足你的視覺需求，子集化這層工完全可以省下來。把工花在內容上，通常比花在字型調校上更划算。

「本機託管 Google Fonts」不是一刀切的建議。英文與中文網站都要比較第三方快取、自己主機、字型大小、分片與實際使用字重，才不會優化完反而變慢。

載入策略：font-display、preload、preconnect 三件事別搞混

字型搬到本機之後，還有最後一哩路：怎麼讓瀏覽器用最聰明的方式把它載進來。這裡有三個常被搞混的概念，搞錯任何一個，你的優化都會打折扣。

font-display：決定文字在字型載入前長什麼樣

font-display 這個 CSS 屬性控制的是「字型還沒下載完之前，瀏覽器要怎麼顯示文字」。最常用的兩個值：

• swap：立刻用系統字型顯示文字，字型下載完再替換。會出現「未套用樣式的文字閃一下」（FOUT），但訪客永遠看得到內容，不會盯著空白。
• optional：如果字型在極短時間內下載完成就用，否則就用系統字型，而且後台下載完也不替換。對追求穩定體驗的站很適合。

實務上的預設選擇是 swap，因為對 SEO 與使用者體驗來說，內容能被看見永遠優先於視覺完美。如果你對版面配置的穩定性很在意，記得同時處理 排版設計實戰技巧裡的 fallback 字型大小，讓替換時的跳動最小化，這也直接影響 CLS 分數。

preload：提前下載關鍵字型

<link rel="preload"> 是告訴瀏覽器「這個資源很重要，請提早開始下載」，對關鍵字型來說可以明顯縮短「文字套用樣式」的時間。WP Rocket 的預載功能就是做這件事。

但 preload 有一個很多人踩的坑：字型的 preload 一定要加 crossorigin 屬性。原因是字型檔預設是用 CORS（跨來源資源共享）的方式抓取，如果你的 preload 沒有宣告 crossorigin，瀏覽器會發起兩次請求：一次沒有 CORS（給 preload 用）、一次有 CORS（給實際的 font-face 用），結果 preload 的下載根本被浪費掉，等於沒做。

正確的寫法：

<link rel="preload" href="/wp-content/themes/child/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin>

這個細節官方文件有寫，但教學文章很少提，結果就是一堆人「加了 preload 卻沒變快」，搞半天是少了那個屬性。

preconnect：跟你決定保留的第三方打交道

如果你評估過後決定某些字型還是要從第三方載入（例如中文用 Google 的動態子集、英文自架），那至少要加上 preconnect，提前跟那個網域建立連線，省掉後續的 DNS 與交握時間。preconnect 跟 preload 是不同的事，preconnect 是「提早認識對方」，preload 是「提早把東西拿過來」，別混為一談。

不過，既然你已經決定本機託管了，preconnect 通常就用不上，因為你根本沒有第三方要連。這也是本機託管的額外好處之一，連這層優化都省了。

做完之後怎麼驗證？打開 PageSpeed Insights 與 Network 看這三個訊號

優化做完不代表完工，驗證才是閉環。沒有量測的優化，跟沒做差不多。具體要看三件事：

1. 第三方字型請求歸零：打開 Network 面板，篩選 fonts.googleapis.com 與 fonts.gstatic.com，應該一個請求都沒有。如果還有殘留，多半是某個外掛或主題檔又把 Google Fonts 注入回來了，回頭查 OMGF 的掃描結果或 Disable 外掛的涵蓋範圍。
2. LCP 與 CLS 的變化：用 PageSpeed Insights 跑一次，跟優化前的數據對比。LCP（最大內容繪製）通常會因為少了第三方請求而改善，CLS（累計版面配置位移）則要看你的 font-display 與 fallback 字型設得好不好，swap 設不好有時會讓 CLS 變差，這是正常的取捨。
3. 第三方請求與渲染成本是否下降：查看 PageSpeed Insights 當下版本提供的診斷與要求樹狀圖。字型搬回本機後，Google Fonts 請求應消失，但總載入量與渲染時間未必同步改善。

如果你之前從來沒量過，建議把優化前後的截圖存下來。這不是為了炫耀，是為了下次主題或外掛更新把字型又偷偷加回來時，你有對照組可以及時發現。這類回退很常見，因為主題更新會覆寫你手動改的檔案。

別只在桌面測，行動裝置才是主戰場

PageSpeed Insights 有桌面與行動兩個分頁，兩者都要檢查，並優先處理實際受眾常用的裝置。Search Console 的 Core Web Vitals 也會分開呈現行動與桌面資料。Mobile-first indexing 指的是 Google 主要用手機版內容建立索引，不代表只有行動分數才是排名訊號；Core Web Vitals 本身也只是眾多排名訊號之一。

實務上，不少案例在桌面測出漂亮的分數，一到行動裝置就破功，主因就是那幾個第三方字型請求在慢速網路下變成致命的瓶頸。本機託管對行動裝置的改善幅度，往往比桌面更大，這也是推薦這件事的另一個務實理由。把你的驗證流程固定成「行動優先」，才不會在錯的戰場上自滿。

更完整的網站速度診斷與改善思路，可以搭配 網站速度的實戰拆解與 WordPress 速度優化一起看，字型只是拼圖的一塊。

常見踩坑：這些細節值得先記下來

這段不是教學，而是實務上常見的教訓。這些坑很容易被忽略，先記下來就能少走冤枉路。

坑一：子主題沒用，主題更新把改動全蓋掉。很多人直接改主題原始檔，下次主題一更新，@font-face 規則、CSS 修改全部消失，字型又跑回 Google。永遠用子主題或自訂外掛來放你的字型相關程式碼，這是 WordPress 的基本衛生習慣。

坑二：preload 加了 crossorigin，字型還是載不進來。檢查你的字型檔是不是真的回傳了正確的 CORS 標頭。有些伺服器預設不允許跨來源存取字型，你 preload 寫得再正確也沒用。本機託管理論上同網域不會有這問題，但如果你用了 CDN，記得檢查 CDN 的 CORS 設定。這部分跟 CDN 網站加速的設定有關。

坑三：以為裝了 OMGF 就天下太平。OMGF 很強，但它只能處理「透過標準方式載入」的 Google Fonts。如果某個外掛是用很奇怪的方式把字型塞進來（例如 inline 在 JavaScript 裡），OMGF 可能掃不到。所以「裝完外掛」不等於「驗證完成」，一定要回到 Network 面板親眼確認請求歸零。

坑四：快取外掛讓你以為沒改善。你改了半天、跑了 PageSpeed 卻沒變快，結果是快取外掛還在送舊的 HTML。測試前先清快取，或用無痕視窗、加上 ?nocache 參數來繞過。快取設定本身可以參考 WP Rocket 完整設定教學，它是這類問題最常見的來源。

坑五：把系統字型堆疊想得太簡單。很多人停用 Google Fonts 之後，發現中文顯示變醜了，就以為這條路不行。其實是 fallback 字型沒設好，瀏覽器回退到一個你不想要的中文字型。好的系統字型堆疊要明確指定優先順序，讓每個平台都回退到該平台上最好的中文字型，而不是任由瀏覽器自己決定。

坑六：WooCommerce 與特定外掛有自己的字型管線。如果你跑的是購物網站，WooCommerce 以及一些結帳、表單、彈窗外掛，常常會自行載入它們專屬的字型或圖示字型（icon font）。你用 OMGF 或 Disable 處理掉主題的 Google Fonts 之後，這些外掛自帶的字型請求可能還在。所以購物網站做完優化，務必連結帳頁、購物車頁、產品頁都各跑一次 Network 檢查，不要只看首頁。首頁乾淨不代表全站乾淨，這是電商站最常被低估的死角。

下一步行動方案：五步把字型這塊收拾乾淨

讀完不等於做完。接下來這五步是建議的具體行動順序，你今天就可以開始：

1. 花一分鐘做診斷：打開 Network 面板，數一下你的網站現在有幾個 Google Fonts 請求、總共多大。把這個數字記下來。
2. 判斷你的情況屬於哪一條路線：對照前面的決策表，你是該本機託管、該完全停用、還是該手動自架？選一條，不要三心二意。
3. 動手執行那一條路線：裝外掛的就裝外掛、要寫 CSS 的就寫 CSS、要停用的就停用。一次只做一條，不要同時混用多種方法，否則出了問題你不知道是哪一條造成的。
4. 回去量一次 Network 與 PageSpeed：確認第三方字型請求歸零、LCP 改善、CLS 沒有惡化。把這次的數字跟第一步的對比。
5. 把驗證結果記錄下來：下次主題或外掛更新之後，回頭跑一次同樣的檢查，確保字型沒有被偷偷加回來。這是一個需要長期維護的衛生習慣，不是做一次就永遠好的設定。

字型這件事，說大不大、說小卻真的會吃掉你的速度分數與法遵分。把它收拾乾淨之後，你會發現網站整體的「乾淨度」提升了一個檔次，不只是分數好看，而是那種「每個請求你都說得出來源」的踏實感。這種踏實感，就是一個成熟 WordPress 站跟一個拼裝車站最大的差別。

把字型當成網站健康檢查的固定項目吧：接手一個新站時，第一件事就是打開 Network 面板，數一下字型請求。這個動作花不到一分鐘，卻能瞬間看出這個站過去是被細心照料、還是被層層外掛堆疊起來的。字型的乾淨程度，其實就是網站維護品質的一面鏡子。你把這面鏡子擦亮，往後所有速度相關的優化都會有事半功倍的基礎。

如果你在執行過程中遇到網站速度的其他瓶頸，例如圖片沒壓、快取沒設好、主機太慢，字型優化只是其中一環，歡迎把整體的 網站速度變慢的診斷與解法當成下一個功課。一步步來，你的網站會越來越快、越來越穩。