同一套字型，過去要為了 Regular、Medium、Bold、Italic 各載一個檔案，網頁一開就是五六個字型請求排隊。可變字型（Variable Fonts）把這些變化全收進單一檔案，靠 CSS 滑桿般地調出任意字重與樣式。WordPress 從 6.1 起把可變字型納進 theme.json，區塊主題與字型庫都吃得下這套格式，問題是多數教學只示範英文字型一鍵套用，碰到繁體中文、頁面建構器、效能實測就沒了下文。
這篇談的是把可變字型真正導入 WordPress 並調校到能上線的完整路徑：從 theme.json 註冊、font-variation-settings 控軸、到中文字型那個沒人提的肥大檔案陷阱。可變字型 WordPress 的導入不難，難在判斷「這個站到底該不該用」，以及用了之後怎麼不讓首屏變慢。
可變字型到底解決了什麼問題
可變字型是把多種字重、寬度、傾斜度收進單一字型檔的技術，瀏覽器載入一個檔案就能在範圍內取出任意樣式。傳統做法相反，每個樣式都是獨立檔案，Roboto 光是 Thin 到 Black 加上斜體就有 12 個檔，全用上等於 12 個 HTTP 請求。
這項技術 2016 年由 Google、Apple、Adobe、Microsoft 共同推出，核心概念叫「軸」（axis）。每個軸是一條可連續調整的滑桿，常見的有：
- wght（字重）：對應 CSS 的
font-weight，傳統字型只能落在 100、200 到 900 的整百刻度，可變字型可以給到 1 至 1000 之間任意值，例如 532。 - wdth（寬度）：對應
font-stretch，控制字身的寬窄。 - slnt（傾斜）/ ital（斜體）：控制字身傾斜或切換正斜體。
- opsz（光學尺寸）：依字級自動微調字形細節，需用
font-variation-settings控制。
對網站的好處集中在三點。第一是效能，請求數與傳輸量下降；CreativeThemes 的整理指出，同時用到多種樣式的網站，把多個靜態檔換成單一可變字型，總字型檔案量常能砍掉 50% 到 80%。第二是設計彈性，字重不再被鎖在固定刻度，品牌想要的 625 也調得出來。第三是響應式排版，可以用 font-weight: clamp() 讓字重隨視窗平滑縮放，不會出現靜態字型那種一階一階的跳動。
要注意這些效能數字的前提是「西文字型」。一個英文可變字型常落在 100 到 300 KB 之間，省得漂亮；中文字型完全是另一回事，後面會專門談。
WordPress 從哪一版開始支援可變字型
WordPress 6.1（2022 年 11 月）把可變字型支援正式併進 theme.json 系統，第一個內建示範是 Twenty Twenty-Three 佈景主題。在那之後的預設主題，例如 Twenty Twenty-Five，本身就帶了 Manrope 與 Fira Code 兩個可變字型。
判斷自己的站能不能用，先看兩件事。一是 WordPress 版本要在 6.1 以上，現行版本早就遠超過這個門檻。二是佈景主題型態：區塊主題（Block Theme，帶 theme.json 與網站編輯器的那種）走 theme.json 與字型庫這條官方路線最順；傳統主題或用 Elementor、Bricks 這類頁面建構器搭建的站，則多半要靠主題本身的字型功能或手動寫 CSS，路徑不同但一樣可行。
格式上，雖然 .ttf 與 .otf 也能當可變字型，網頁實務一律優先用 .woff2。這是 2018 年成為 W3C 推薦標準的高度壓縮格式，所有現代瀏覽器都支援，檔案最小、解壓最快。下載字型時若同時看到 VariableFont 字樣與 .woff2 副檔名，那就是要的檔。
在 theme.json 裡註冊一個可變字型
區塊主題註冊可變字型的關鍵，在於 fontFace 裡的 fontWeight 要寫成「範圍字串」而不是單一數字。傳統字型寫 "fontWeight": "400"，可變字型則寫 "fontWeight": "100 900"，中間一個空白，這個空白就是告訴 WordPress 這個檔涵蓋從 100 到 900 的整段字重。
把字型檔放進子主題的 assets/fonts/ 資料夾後，theme.json 的 settings.typography.fontFamilies 裡加一段：
{
"name": "Source Sans 3",
"slug": "source-sans-3",
"fontFamily": ""Source Sans 3", sans-serif",
"fontFace": [
{
"fontFamily": "Source Sans 3",
"src": ["file:./assets/fonts/SourceSans3VF-Upright.woff2"],
"fontWeight": "100 900",
"fontStyle": "normal"
}
]
}
斜體要另外給一個 fontFace 物件，指向斜體檔、fontStyle 改成 italic，字重範圍照舊。也就是同一個字型家族底下可以掛多個 fontFace，正體一個、斜體一個。
註冊完，在 styles 區段指定哪裡套用。例如全站內文用 Source Sans 3、標題用另一個字型並指定字重 600：
"styles": {
"typography": {
"fontFamily": "var:preset|font-family|source-sans-3"
},
"elements": {
"heading": {
"typography": { "fontWeight": "600" }
}
}
}
這裡有個容易踩的雷。若你用的是子主題，而父主題（例如 Twenty Twenty-Five）本來就註冊了 Manrope、Fira Code，子主題的 theme.json 最好把這些字型也一併重新宣告一次。原因是父主題日後更新可能改動字型檔路徑，子主題不重新宣告，這些字型會從字型庫介面消失，或在更新後失效。看起來重複，實際是在固定路徑、保住可用性。
字型實際載入不出來時該檢查什麼
theme.json 註冊了卻在前台看不到字型，最常見的原因是前台 CSS 沒有對應的 @font-face 宣告把字型「綁定」到元素上。theme.json 管的是編輯器與區塊樣式系統，某些主題情境下，前台仍需要一份明確的 CSS。
實務上會在主題裡放一份字型 CSS，內容是標準的 @font-face：
@font-face {
font-family: 'Source Sans 3';
src: url('./assets/fonts/SourceSans3VF-Upright.woff2') format('woff2');
font-weight: 100 900;
font-style: normal;
font-display: swap;
}
注意這裡的 font-weight: 100 900 同樣是範圍寫法，跟 theme.json 對齊。font-display: swap 是這段的重點：它讓瀏覽器在字型還沒下載完時，先用系統替代字型把文字顯示出來，等可變字型到位再換上。換字的瞬間會有一下字體跳動，業界稱為 FOUT（Flash of Unstyled Text），但比起讓使用者盯著空白（FOIT），swap 在效能與體驗之間是比較穩的折衷。
再把這份 CSS 透過主題的 wp_enqueue_style 掛進前台與編輯器，並用 add_editor_style 讓編輯器也吃到同一份規則，編輯畫面與前台才會一致。如果某個字型是首屏標題會立刻用到的關鍵字型，可以額外在 <head> 加一行 <link rel="preload"> 提前抓，減少首屏的字體跳動。
用 font-variation-settings 調出標準屬性之外的軸
字重、斜體這些已經有對應 CSS 屬性（font-weight、font-style）的軸，直接用那些屬性最乾淨。但像光學尺寸 opsz、寬度以外的自訂軸，就得靠 font-variation-settings 這個低階屬性，用四個字母的軸標籤加數值來控制：
.hero-title {
font-variation-settings: "wght" 720, "opsz" 48, "slnt" -6;
}
這個屬性有個常被忽略的坑：它必須一次寫完所有要設定的軸，只想改其中一個值時，整串都得重寫，否則沒寫到的軸會被重設回預設值。解法是改用 CSS 自訂屬性（CSS 變數）把每個軸拆開管理：
:root {
--wght: 400;
--slnt: 0;
}
.title {
font-variation-settings: "wght" var(--wght), "slnt" var(--slnt);
}
.title:hover {
--wght: 720;
}
這樣 hover 時只動 --wght 一個變數，其他軸維持不變。可變字型最受設計師喜歡的純 CSS 動畫，靠的就是這套：給元素一個 transition，再讓 font-variation-settings 或字重變數在不同狀態間切換，字重就會平滑地從細變粗，不需要任何 JavaScript 或圖片。
還有一個 cr0ybot 整理過的進階技巧，適用於 Recursive 這類有多個非字重軸（如 MONO 單線、CASL 休閒度、CRSV 草書）的字型：在 theme.json 裡用同一個字型檔，但為每種想要的組合各定義一個獨立的字型家族名稱，每個家族用不同的 fontVariationSettings 鎖定軸值。這樣使用者在編輯器字型選單裡就能直接選「Recursive 單線版」「Recursive 草書版」，不必手動拉軸。這是目前繞過「網站編輯器尚未提供軸滑桿介面」這個限制的務實做法。
繁體中文可變字型的現實：檔案肥大是最大關卡
談到中文，可變字型的效能優勢會直接反轉，這是所有英文教學都跳過、卻是台灣站最該先想清楚的一點。原因在字數量級。一套西文字型涵蓋的字符是數百個，可變字型檔常在數百 KB 以內；一套涵蓋常用繁體中文的字型，光是字符就上萬，單一字重的靜態 .woff2 動輒 3 到 7 MB，把多個字重包成可變字型檔，體積只會更可觀。
換句話說，西文可變字型「一個檔取代六個檔」省下來的傳輸量，到了中文這邊，可能變成「一個巨檔比你原本只載一兩個字重還重」。如果你的中文網站本來就只用 Regular 跟 Bold 兩個字重，硬上一個內含完整字重範圍的中文可變字型，首屏反而更慢。
務實的判斷是這樣。中文站要導入可變字型前，先問自己有沒有同時用到三個以上字重、或需要連續調整字重做動畫；用不到的話，傳統做法載入兩個靜態字重通常更輕。真要用，幾乎一定得搭配子集化（subsetting）：用工具把字型裁切成只含網站實際會出現的字（例如固定的選單、標題、品牌字），把檔案壓到合理大小，再以 font-display: swap 與 unicode-range 分段載入。繁體中文可變字型目前可選的字型家族也比西文少很多，導入前先確認手上的字型確實提供可變版本，而非只有靜態多字重包。
用頁面建構器或字型庫，不寫程式的導入路徑
不是每個站都跑區塊主題，台灣大量 WordPress 站是用 Elementor、Bricks 或商業主題搭的。這些情境下導入可變字型，主要有兩條不碰程式碼的路徑。
第一條是 WordPress 內建的字型庫。在網站編輯器的字型管理介面裡，可以上傳本機字型檔，包含可變字型的 .woff2，也能瀏覽並安裝 Google Fonts 裡的可變字型，安裝後該字型就會出現在區塊與全站樣式的字型選單。這條路最適合用區塊主題、又不想動 theme.json 的人。
第二條是主題本身的字型功能。不少商業主題把可變字型上傳做成圖形介面，例如進到主題的自訂字型模組，按上傳可變字型，分別指定正體與斜體檔，命名儲存後，這個字型就會出現在主題排版設定的字型清單裡，後續在 Customizer 或建構器直接選用。各家主題的選項名稱與位置不同，但邏輯都是「上傳檔案、命名、在排版設定挑選」這三步。
不論走哪條，導入後務必回到實機檢查字重是否真的生效。圖形介面常只暴露固定幾個字重選項，若你需要的是非標準字重或軸調整，最後一哩仍可能得用主題的自訂 CSS 欄位補一段 font-variation-settings。
對 WooCommerce 商店與內容站的實際取捨
對跑 WooCommerce 的商店站，字型一致性會直接連到品牌觀感與轉換。商品標題、價格、按鈕、內文若各自字重不一，畫面會顯得鬆散；可變字型讓你用單一檔案把整套字重梳理整齊，標題用 700、價格用 600、內文用 400，全部來自同一個字型，視覺更統一，理論上還省下多檔請求。
但取捨也在這裡。商店頁元素多、圖片重，首屏本來就吃緊，若主力是中文字型，前面講的肥大問題會直接咬掉你想省的那點請求數，甚至拖慢加入購物車前的等待。比較穩的做法是：西文或數字密集的元素（價格、型號、英文品牌名）用西文可變字型發揮彈性，中文內文則維持子集化後的靜態或精簡可變字型，兩者分工，而不是全站塞一個大而全的中文可變字型。
內容型網站的考量單純些，重點在閱讀體驗與 CLS（版面位移）。字型載入造成的尺寸落差會讓文字區塊在 swap 那一刻跳動，影響的不只觀感，也牽動網站體驗指標。可變字型本身不會消除 CLS，仍要靠 font-display 策略、適當的 fallback 字型尺寸調校、以及對關鍵字型做 preload 來壓低位移。
導入前先回答這三個問題
可變字型 WordPress 的導入，技術門檻其實不在語法，theme.json 註冊一段、CSS 綁定一段就跑得起來。真正決定要不要用、好不好用的，是導入前的三個判斷。
第一，這個站會同時用到幾個字重與樣式？三個以上、或需要連續調整與動畫，可變字型才划算；只用 Regular 加 Bold，傳統靜態字型更簡單也更輕。第二，主力字型是中文還是西文？西文放心用，中文先把子集化方案想好，否則省請求數省不過肥大檔案的代價。第三，這個站走的是區塊主題、頁面建構器，還是商業主題？路徑不同，但字型庫、theme.json、主題自訂功能三條路至少有一條走得通。
把這三題答清楚，再回到 theme.json 或字型庫去動手，導入會順很多。先在測試環境裝好、用實機量過首屏與字體跳動，確認效能沒有反向惡化，再推上正式站，這個順序能讓可變字型真的成為加分項，而不是另一個拖慢網站的字型檔。