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 字型檔，改由自己管理的主機提供字型資源。這能移除原本對 Google 字型服務的請求，網站其他第三方服務仍須另外盤點。

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

重點摘述

• 本機託管將字型檔與相關 CSS 改由自己管理，減少對外部字型服務的依賴。
• 效能結果取決於傳輸量、子集、快取與主機；英文與中文網站都要前後比較。
• 可選 OMGF、系統字型或手動託管，依品牌與維護需求決定。
• 移除遠端字型請求只處理這一條資料流，整站法遵仍要另行評估。
• 驗證各頁字型來源、缺字與版面位移，並分別檢查桌面和手機。

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

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

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

本機託管能減少外部字型依賴；是否加快載入，仍需測量。下面會一步步帶你做。如果你想先建立字型的整體概念，可以參考 網頁字體 Webfont 完全指南。

遠端字型為什麼涉及個人資料傳輸

遠端字型載入會讓訪客裝置連到字型服務商，因此也要納入網站的資料處理盤點。GDPR 是否適用，要看組織、服務對象與資料處理活動，不能只靠主機所在地判斷。

適用 GDPR 的網站，需確認資料處理目的、合法基礎及告知義務；涉及境外傳輸時，還要另外檢查相關規則。改成本機託管可以移除對 Google 的字型請求，但不會一併解決分析工具、廣告或影音嵌入的資料流。

先盤點第三方請求，再確認法規適用範圍與合法基礎，才能判斷字型載入方式是否需要調整；單靠一個外掛的合規宣傳，不足以完成整站評估。

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

網站經營者位於台灣，不代表一定排除 GDPR。向歐盟境內個人提供商品或服務，或監測其行為的情境，仍要檢查地域適用範圍：

• 你向歐盟境內個人提供商品或服務，或監測其行為：非歐盟組織也可能落入 GDPR 的地域適用範圍；只有偶然出現歐洲訪客，並不當然代表 GDPR 適用（見 European Commission 的說明）。
• 你在做品牌形象、走國際市場：可整理字型與其他第三方服務的資料流，回應客戶的隱私要求。
• 你單純想讓網站更快：先比較目前載入量與候選方案，再決定是否更換託管方式。

把隱私盤點與效能測量一起做，比直接拆掉所有字型更有效率。自架會增加檔案、快取與版本管理工作；使用外部服務則保留第三方依賴，兩者都需要維護。

先診斷：網站載入了哪些字型

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

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

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

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

1. 打開 Chrome 開發者工具的 Network 面板，先用 Font 類型篩選，再到 All 檢查 Google Fonts 的 CSS 網域，重新整理頁面，看列出來幾個請求、每個檔案多大、來自哪個網域。
2. 勾選 Disable cache再重新整理一次，觀察未使用瀏覽器快取時的請求；這仍是你當下的裝置與網路條件，不能代表所有新訪客。
3. 用 PageSpeed Insights 跑一次，查看診斷、要求樹狀圖與實際字型請求；報告項目名稱可能隨 Lighthouse 版本調整。

請求數要連同檔案大小、用途與 unicode-range 一起看。多個小型字元分片可能比一個完整字型更省傳輸；不要只用請求數判斷主題或外掛是否浪費資源。

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

字型大小取決於字元範圍、格式、字重與可變軸，不能用固定 KB 數代表所有英文或中文字型。記錄實際載入檔案後，可以從以下角度比較：

不要因為是英文字型就忽略多餘字重，也不要因為是中文字型就排除本機託管。保留合適的子集與快取，往往比檔案放在哪裡更值得先檢查。

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

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

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

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

實作時間與網站載入速度是兩件事。手動託管可能花較多維護時間，但不代表載入比較慢；選擇時要同時考慮品牌、效能與管理能力。

路線一：用 OMGF 管理本機 Google Fonts

OMGF 可下載並重寫它偵測到的 Google Fonts 資源，並提供字重、子集與預載控制。免費版和 Pro 的偵測範圍不同，請先檢查網站實際使用的載入方式（見 OMGF 在 WordPress.org 的頁面）。

啟用後仍需查看掃描結果。若字型由 JavaScript、內嵌樣式或其他非標準途徑加入，可能需要 Pro 功能或調整來源設定。

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

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

• Font-display：依文字顯示與版面穩定性選擇 swap 或 optional，並測量替換時的跳動。
• Preload：只預載首屏需要且測量後有幫助的字型，避免與主要圖片爭用頻寬。
• Subsets：保留內容需要的字元範圍，包含姓名、符號與多語內容；刪除子集後要測試缺字。

免費版可處理基本本機託管；Pro 另有較深的載入偵測、多站網路與自訂 CDN 等功能。是否需要付費，應由漏掉的實際請求與維護需求判斷。

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

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

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

Disable and Remove Google Fonts 能停用它支援的主題與外掛字型來源，目前也提供 Font Audit 檢查頁面。部分第三方樣式仍可能需要手動處理；啟用後要檢查字型回退與殘留請求。

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

系統字型堆疊讓瀏覽器依序尋找裝置已安裝的字型，最後使用通用字型。實際字型會隨作業系統、版本、語言與使用者設定變化，不宜假設每台 Android 或 Windows 都裝有同一套字型。

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

• 不必下載 Web Font，可減少字型相關傳輸；對 Core Web Vitals 的實際影響仍要測量。
• 移除 Google Fonts 第三方請求，但網站上的分析、影音或其他第三方服務仍要各自盤點，不能據此宣稱整站法遵問題歸零。
• 沿用裝置字型，可減少 Web Font 下載，但不同裝置的字寬與行高仍可能不同。
• 減少字型檔維護，不用自行散布這些系統字型檔，仍需測試排版與外掛新增的遠端字型。

內容站可先測試系統字型是否滿足閱讀與品牌需求，再決定要不要維持指定 Web Font。把不同裝置的實際畫面放在一起比較，比只看設計稿更有用。

以下是可作為起點的繁體中文系統字型堆疊，請依網站受眾測試後調整順序：

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

瀏覽器會依字型可用性與字元覆蓋範圍選擇回退字型。只寫 font-family 不會自動下載字型，但若網站另有同名字型的 @font-face 宣告，仍可能觸發下載；需一併檢查。

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

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

如果你不想依賴任何外掛、或你的字型需求比較特殊（例如用了 Google Fonts 之外的商業字型），可走手動路線；先確認授權允許網頁嵌入、轉檔及自行託管。這條路比較長，但換來的是完全的控制權。

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

1. 取得字型檔：從 Google Fonts 下載你需要的字型，確認授權，並只保留實際用到的字重，別整個家族抓下來。你也可以用 google-webfonts-helper 這類工具產生指定字重的下載包。
2. 轉成 woff2：依 caniuse 的資料，WOFF2 適用於目前常見瀏覽器；實際壓縮幅度取決於字型，仍需對照受眾的瀏覽器版本。除非你要支援非常老的瀏覽器，否則只提供 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 換成你的本機字型名稱，再停用原本載入 Google Fonts 的來源。單改 font-family 不會自動移除舊的 CSS 或預載請求。

可變字型：在同一檔案中提供支援的字重範圍

可變字型可在一個檔案內提供字重或寬度等變化軸。字重軸可以透過 font-weight 選擇，但可用範圍由字型決定；斜體、字元子集或不同樣式仍可能需要其他檔案。

若使用多個靜態字重，可比較它們的總下載量與相同覆蓋範圍的可變檔。只用單一字重時，可變字型未必更小；Google Fonts 是否提供可變版本，也要逐套確認。

以下範例只適用於實際支援 100 至 900 字重的檔案；路徑與範圍都要換成你的字型資料：

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

font-weight 範圍宣告不會替檔案增加原本沒有的變化軸。靜態字型也能接收 CSS 字重數值，但瀏覽器會選擇可用字重或合成效果，與可變字型內插不同。

使用前請比對目標瀏覽器支援、字元涵蓋與實際檔案大小，再測試粗細切換及回退。可變字型提供設計彈性，是否節省傳輸則由用到的樣式決定。

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

WOFF2 的 MIME type 應為 font/woff2。載入失敗時，先分清楚 HTTP 403 權限、404 路徑、CORS 與字型解析錯誤；不能都歸因於 MIME。需要調整時，可由管理者檢查 Apache 的 AddType font/woff2 .woff2 或 Nginx 的 font/woff2 woff2; 設定。

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

中文網站的關鍵：保留合適的字元子集

中文是否適合本機託管，重點是實際字元與分片策略。將原本的分片換成完整 CJK 字型，可能增加傳輸；保留相同分片，則是另一種比較。

Latin 字型也可能包含大量重音字與符號，CJK 字型則可能涵蓋更多漢字。完整檔案的大小不能代表每頁下載量，應查看瀏覽器實際取得哪些分片。

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

中文網站的務實建議

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

• 中文內文可先評估系統字型堆疊，讓讀者裝置使用既有中文字型，通常能省下可觀的字型傳輸，但仍要檢查品牌與跨平台顯示。
• 如果一定要用特定中文字型，可評估子集化（subsetting）並只保留需要的字元。實際縮減幅度取決於字型與字元集，新內容加入新字時也要更新子集。
• 英文字型也要比較實際字重、子集與傳輸量；品牌標題使用指定字型時，可先從這部分測試。

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

子集化只保留需要的字元，能縮減字型檔，但必須考慮搜尋結果、使用者留言、商品名稱與未來新增內容。缺少的字元需要合適的 fallback。

FontTools 的 pyftsubset 可依你提供的文字或 Unicode 清單產生子集；它本身不會自動爬完整個網站。先整理靜態與動態內容需要的字元，再產生字型及測試回退；新字缺漏不必然成方塊，還取決於其他字型能否補上。

另一種做法是使用常用字集合或多個 unicode-range 分片。常用字集合可能漏掉姓名與罕見字，因此內容擴充後仍需檢查覆蓋範圍，不能當成永久免維護。

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

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

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

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

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

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

• swap：經極短的阻擋期後顯示 fallback，字型可用時替換；可能造成版面位移。
• optional：只給字型短暫機會；未及時可用時，這次瀏覽維持 fallback。瀏覽器也可能依連線狀況調整下載。

若需要最終套用品牌字型，可測試 swap；若接受此次瀏覽維持 fallback，可評估 optional。如果你對版面配置的穩定性很在意，記得同時處理 排版設計實戰技巧裡的 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 的 unicode-range 字元分片、英文自架），那至少要加上 preconnect，提前跟那個網域建立連線，省掉後續的 DNS 與交握時間。preconnect 跟 preload 是不同的事，preconnect 是「提早認識對方」，preload 是「提早把東西拿過來」，別混為一談。

若字型與頁面完全同源，就不需要為同一來源另設 preconnect。自行管理的 CDN 若使用不同來源，仍可測試是否需要連線提示。

做完之後怎麼驗證？打開 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。手動加入程式碼時，可放在子主題或自訂外掛；也可使用支援的字型管理功能，避免直接修改父主題。

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

坑三：把安裝當成驗收。OMGF 免費版與 Pro 的偵測範圍不同，另有 iframe 等第三方內容可能繼續載入字型。依掃描結果與 Network 面板找出來源，再決定調整設定或嵌入方式。

坑四：快取外掛讓你以為沒改善。你改了半天、跑了 PageSpeed 卻沒變快，結果是快取外掛還在送舊的 HTML。測試前先清快取，並依主機、CDN 與外掛文件清除對應快取；無痕視窗不會清除伺服器快取，?nocache 也不是所有系統通用的繞過方式。快取設定本身可以參考 WP Rocket 完整設定教學，它是這類問題最常見的來源。

坑五：把系統字型堆疊想得太簡單。很多人停用 Google Fonts 之後，發現中文顯示變醜了，就以為這條路不行。其實是 fallback 字型沒設好，瀏覽器回退到一個你不想要的中文字型。好的系統字型堆疊要明確指定優先順序，並在實際平台檢查字寬、行高與缺字；最終仍由瀏覽器依可用字型選擇。

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

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

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

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

整理字型後，留下來源、設定與測量紀錄，之後更換主題或外掛時就有依據可以比對。

接手網站時，字型請求可列入資源盤點，但請求數本身不足以判斷整站維護品質。把它與圖片、JavaScript 和主機回應時間一起檢查。

如果你在執行過程中遇到網站速度的其他瓶頸，例如圖片沒壓、快取沒設好、主機太慢，字型優化只是其中一環，歡迎把整體的 網站速度變慢的診斷與解法當成下一個功課。依量測結果逐項改善，並留下前後對照紀錄。