Divi 自訂字體上傳教學:3 步驟搞定格式轉換
Divi 自訂字型上傳完整教學:解析 OTF/TTF/WOFF/WOFF2 格式差異與轉檔流程,從 Visual Builder 上傳到 Theme Builder 全域套用、font-display 與 preload 設定、中文字型子集化與除錯驗證一次講清楚。
作者:褚崇名(Sliven)
本頁目錄
- 為什麼 Divi 內建字型庫,滿足不了真正的品牌站
- 上傳之前,先搞懂四種網頁字型格式
- 字體授權:比格式轉換更容易踩雷的一關
- 把 OTF 與 TTF 轉成 WOFF2 的實作流程
- Divi 自訂字型上傳:Visual Builder 裡的三個動作
- 動作一:打開任一文字模組的 Design 標籤
- 動作二:點選「Upload Font」
- 動作三:套用到模組,字型即刻可用
- 從單一區塊到全站套用:Theme Builder 與子主題的角色
- 自己託管還是走 CDN:自訂字型的兩條路
- 自訂字型為什麼會拖垮 Core Web Vitals
- 中文字型千萬別整包上傳:子集化才是正解
- 消除文字「閃一下」:font-display 與預載入設定
- 選一個「算得上來」的回退字型
- 字體上傳後出問題:一份排查清單
- 收尾:把自訂字型做對的六步走法
想像一下這個畫面:你花了兩個禮拜,用 Divi 把一個品牌官網從無到有拉出來,配色、間距、圖片全部到位,前後對比測試也跑過了。你興沖沖地把預覽連結丟給客戶,對方看了三秒,回了一句:「看起來跟我上週看過的另一個網站好像。」
問題往往不在配色,也不在版面。問題出在字型。Divi 內建的字型庫雖然齊全,但那是「所有人都拿得到」的資源,當你的競爭對手也用同一套 Google Fonts 時,你的品牌辨識度從第一眼就被歸零。字型是品牌的聲音,它在你開口之前就先替你說話了。
核心重點:Divi 上傳自訂字型的核心動作僅有三步。第一步,進 Visual Builder 開啟任一文字模組的 Design 標籤。第二步,點 Font Family 下拉選單裡的「Upload Font」。第三步,選好檔案與字重後套用。但真正決定成敗的,是上傳之前的格式轉換與授權確認,以及上傳之後的 font-display 與預載入設定。這篇會把三步驟連同前後所有該注意的事一次講清楚。
為什麼 Divi 內建字型庫,滿足不了真正的品牌站
先說結論:Divi 內建的字型庫對九成的入門專案來說綽綽有餘。它接了 Google Fonts 的完整目錄,也允許你在 Theme Options 裡為 body 與 heading 各指定一套字型。如果你做的是一個在地咖啡館的介紹頁、一個活動 landing page,內建字型完全夠用,沒必要自找麻煩。
但「夠用」跟「有辨識度」是兩件事。實務上常見許多網站,配色用心、圖片精挑,卻因為字型跟隔壁競品一模一樣,整體看起來就是「哪裡都看得到的網站」。這種感覺很微妙,訪客說不出哪裡怪,但你就是很難記住它。對一個打算長期經營的品牌來說,這種「面目模糊」其實是比載入慢更隱性的傷害,因為它一點一滴吃掉的是品牌被想起來的機會。
若品牌規範指定特定字型,可先確認授權是否允許網頁嵌入,再依網站架構選擇 Divi 自訂字型、佈景主題設定、外掛或 @font-face。Divi 上傳是其中一種管理方式,不是唯一選項。
這件事之所以比「換個漂亮字體」更值得看重,是因為字型承擔的品牌工作量,往往比配色還大。你可以把一個網站的配色全部抽換掉,僅需字型還在,品牌的氣質就還在;反過來,一旦字型換掉,整個品牌的個性會瞬間變樣。這樣看來,建議在動手改配色之前,先把字體與排版的底層邏輯想清楚,再回頭處理品牌色。順序錯了,後面的調整會事倍功半。
說穿了,自訂字型不是「讓網站變漂亮」的化妝品,而是「讓品牌可以被辨識」的基礎建設。這也是為什麼它值得你花一篇文章的篇幅,好好搞懂格式、授權與效能這三件事。
上傳之前,先搞懂四種網頁字型格式
很多人卡在上傳這一步,問題很少出在 Divi 本身,多半出在手上的字型檔案格式不對。在你點下那個「Upload Font」按鈕之前,先花三分鐘認識四種你一定會遇到的格式。這三分鐘會幫你省下後面三小時的除錯時間。
Divi 接受的字型格式有四種:OTF、TTF、WOFF、WOFF2。它們對應的是字型技術演進的四個階段,先後順序有其意義。搞懂這層差異,你才知道該上傳哪一個。
| 格式 | 全名 | 設計目的 | 壓縮 | 適合 Divi 上傳嗎 |
|---|---|---|---|---|
| OTF | OpenType Font | 桌面排版與印刷 | 無壓縮 | 可以,但檔案偏大 |
| TTF | TrueType Font | 較早期的桌面字型 | 無壓縮 | 可以,但檔案偏大 |
| WOFF | Web Open Font Format | 專為網頁設計的壓縮容器 | 有壓縮 | 舊版瀏覽器相容需求才使用 |
| WOFF2 | WOFF version 2 | 新一代網頁字型,Brotli 壓縮 | 壓縮率最高 | 首選格式 |
這裡的關鍵差異是「壓縮」。OTF 與 TTF 是為桌面排版設計的,它們要把字型送進印刷廠,所以保留了完整的曲線資料與提示(hinting)資訊,檔案自然大。一個英文 Regular 字重,TTF 動輒 80 到 200KB;一個中文 Regular 字重,TTF 可以膨脹到 5 到 20MB。把這種檔案丟上網站,等於強迫每一個訪客下載一整個印刷級的字型檔。
WOFF 與 WOFF2 則是專為網頁而生的。它們本質上是把同一套字型曲線「打包壓縮」過的容器,WOFF2 用的還是 Google 的 Brotli 演算法,壓縮率比 WOFF 再高一截。實務上,一個 WOFF2 檔案大約比原始 TTF 小三成以上,而且現代瀏覽器(Chrome、Edge、Firefox、Safari 全部)都已經原生支援。換句話說,你沒有任何理由在 2026 年的網站上還優先用 TTF。
2026 年面向現代瀏覽器的網站,通常準備 WOFF2 就夠了;若專案明確需要支援不相容 WOFF2 的舊版瀏覽器,再補 WOFF 備援。Divi 允許你為同一個字型家族上傳多個格式,是否需要備援應由瀏覽器支援範圍決定(見 web.dev 的字型優化指南,2026 年 7 月)。
字體授權:比格式轉換更容易踩雷的一關
格式選錯,頂多字型顯示不出來,修一下就好。授權搞錯,可能是一封律師函的問題。這一關被絕大多數教學跳過,但對做品牌站的人來說,它才是最該被認真對待的。
字型授權不是「我買了就能用在任何地方」這麼單純。同一家字體廠商通常會把授權拆成好幾種,每一種對應一種使用情境:
- Desktop 授權:讓你在設計軟體裡用這套字型做海報、做簡報、做印刷品。它不包含把字型檔案放到公開網站上讓任何人下載的權利。
- Webfont 授權:才是允許你用 @font-face 把字型嵌入網站的那種。它通常會綁定「每月頁面瀏覽量」或「網域數量」來計價。
- App 授權:給手機 App 內嵌字型用,跟網站是兩條授權線。
- OFL 與免費授權:SIL Open Font License(OFL)這類開源條款,明確允許商用與網頁嵌入。Google Fonts 上的字型幾乎都是 OFL,這也是它們可以直接拿來用的原因。
最容易出事的情境是這個:設計師在公司電腦裡裝了一套商業字型做印刷物,客戶看了很喜歡,順手把同一個字型檔拿去做網站。這時候你拿到的,是一份 Desktop 授權的檔案,它的 EULA(終端使用者授權協議)裡很可能寫著「禁止 web embedding」或「禁止 @font-face 使用」。你把它上傳到 Divi,技術上完全跑得動,但合約上你已經違約了。
那實務上會怎樣?老實說,真正常見的狀況是字體廠商透過爬蟲發現你用了它的字型,接著寄一封「補差價升級為 Webfont 授權」的帳單給你。金額通常是 Webfont 授權的定價,有時會加一筆追溯費用。對小網站來說,這是一筆完全可以避免的支出。
實務上的判斷標準很簡單,給你當參考:來源不明的字型檔,預設當成「不能上網」;明確標示 OFL 或 Apache License 的,可以放心用;商業字型,一定要回頭翻它的 EULA,找到「web embedding」或「@font-face」相關條款,確認你的使用量落在授權範圍內。如果你打算長期經營這個品牌站,這一步省不得。
把 OTF 與 TTF 轉成 WOFF2 的實作流程
確認授權沒問題之後,接下來就是格式轉換。大多數字體廠商賣給你的是 OTF 或 TTF 檔,現代網站通常要先轉成網頁用的 WOFF2。這一步不難,但有幾個細節會影響成品品質。
實務上常用的轉檔工具有三個,你可以依喜好挑一個:
| 工具 | 類型 | 優點 | 注意事項 |
|---|---|---|---|
| Transfonter | 開源線上工具 | 免費、支援 base64 與子集、產出 CSS | 大量檔案時要分批處理 |
| Font Squirrel Webfont Generator | 免費線上工具 | Expert 模式可調子集、字距、提示 | 商業字型需確認授權允許轉換 |
| CloudConvert | 通用格式轉換站 | 介面直覺、支援多種格式互轉 | 無字型專屬的子集功能 |
轉檔的標準流程是這樣的:
- 準備好授權允許網頁使用的原始字型檔,通常是一個或多個字重的 OTF/TTF。
- 到 Transfonter 或 Font Squirrel,把檔案上傳。
- 選擇 WOFF2;若專案明確支援舊版瀏覽器,再一併輸出 WOFF。
- 若要做中文字型的子集化(這是中文站的大重點,下面會專門講),在子集欄位填入你要保留的字元。
- 下載轉好的壓縮檔,確認其中有 woff2 與示範 CSS;需要舊版備援時才保留 woff。
有一個觀念要特別提醒:轉檔本身是中性的技術動作,但它不能讓你「洗白」授權。如果你的原始字型不允許網頁嵌入,把它轉成 WOFF2 再上傳,違約的性質完全一樣。轉檔解決的是「格式不相容」這個技術問題,不是「沒有授權」這個法律問題。兩件事不要混為一談。
還有一個小細節:轉出來的檔案命名,建議保留字型家族名與字重,例如 BrandSans-Regular.woff2、BrandSans-Bold.woff2。Divi 在上傳時會問你這組字型的名稱與權重,命名清楚可以幫你之後在 Theme Builder 裡少很多對照的工夫。這種「現在多花三十秒,未來省三十分鐘」的習慣,在多站維護的時候特別有感。
Divi 自訂字型上傳:Visual Builder 裡的三個動作
前置作業全部到位之後,真正的上傳其實非常快。Divi 把自訂字型的入口,藏在每一個文字相關模組的 Design 標籤裡,這也是很多人一開始找不到它的原因。整個流程可以拆成三個動作,照著做就行。
動作一:打開任一文字模組的 Design 標籤
進入 Visual Builder 之後,隨便點開一個有文字的模組。Text 模組、Heading 模組、Button 模組、Blurb 模組,任何一個帶有「Text」設計區塊的模組都可以。進去之後切到 Design 標籤,展開 Text(或 Heading Text、Button Text,視模組而定)這一組設定。你會看到一個 Font Family 的下拉選單。
如果你對 Divi 5 的新介面還不熟,建議先讀過Divi 5 介面的深度解析。Divi 5 在這一版的設定面板做了不少整理,字型相關的選項位置跟舊版略有出入,但「Design 標籤裡的 Text 區塊」這個大方向沒有變。
動作二:點選「Upload Font」
在 Font Family 下拉選單的頂部,會有一個「Upload Font」的按鈕(或是一條標示為「Upload a custom font」的選項)。點下去之後,會跳出檔案選擇視窗,讓你挑本機的字型檔。
這裡有兩個欄位要填:
- Font Name:這個名字會出現在整個網站的字型下拉選單裡,建議用字型的官方家族名,方便之後辨識。
- Supported Weights:勾選你這個檔案實際包含的字重。如果你僅上傳 Regular,就僅勾 Regular;如果你之後會陸續補上 Bold 與 Light,可以先把對應的欄位留著。
Divi 允許你為同一個字型家族分次上傳不同字重,這在實務上很方便,因為你常常是先拿到 Regular 開工,Bold 之後才補。
動作三:套用到模組,字型即刻可用
上傳完成後,新的字型會立刻出現在 Font Family 下拉選單裡,而且不僅這個模組看得到,整個網站所有模組的字型選單都會出現它。選下去,文字就會套用新字型。這就是「三步驟」的完整樣貌:打開模組、上傳檔案、套用。
有一個關鍵觀念要講清楚:Divi 的自訂字型一旦上傳,就是「全站可用」的資源,它不是綁死在某一個模組上。這代表你僅需上傳一次,就可以在標題設計、內文、按鈕、頁首任何地方重複選用它。很多人誤以為每個頁面都要重新上傳,那是浪費時間。
上傳之後,建議你立刻做一件事:開瀏覽器的開發者工具,切到 Network 面板,重新整理頁面,看看那個字型檔有沒有被正確請求、回傳的狀態碼是不是 200、檔案大小符不符合預期。這個十秒鐘的檢查,可以在字型「看起來套用了但其實沒有」的時候,第一時間抓到問題。
從單一區塊到全站套用:Theme Builder 與子主題的角色
把字型上傳成功,僅是第一步。接下來的問題是:你要怎麼讓它變成整個網站的預設字型,而不是僅在某一個模組裡用?這牽涉到兩條路線,搞清楚它們的差別,你才知道該走哪一條。
第一條路線是 Divi 的全域預設。在 Theme Builder 裡,你可以為全站的 header、body、footer 各自設定預設模組,而每一個預設模組的文字設定,都可以指定你剛上傳的自訂字型。設好之後,未來新增的每一個頁面,都會自動繼承這套預設。這是品牌站最該採用的做法,因為它確保整個網站的字型一致性,不會某個頁面用了品牌字、另一個頁面又掉回預設。
第二條路線是傳統的 Theme Options。在 WordPress 後台的 Divi → Theme Options,有一個 General 頁籤可以設定預設的 Heading 與 Body 字型。這個介面在舊版 Divi 是主要入口,但它有一個限制:它有時候僅認得內建字型庫裡的項目,對你透過 Builder 上傳的自訂字型支援程度會因版本而異。如果你發現 Theme Options 裡選不到剛上傳的字型,不要跟它硬碰硬,改走 Theme Builder 的全域預設會更乾淨。
還有第三條路線,是給進階使用者的:用子主題手動寫 @font-face 與 CSS。這條路的優點是可控性最高,你可以精準指定 font-display、unicode-range、預載入順序,也可以把字型檔放在特定的 CDN 或本機路徑。它的代價是你得自己處理 @font-face 的語法與快取標頭,門檻比點按鈕高一些。如果你的專案對效能要求很挑剔(例如品牌站要做Core Web Vitals 壓測),這條路會回報你最多的控制權。
無論走哪一條,有一個原則不變:全域套用之後,一定要在手機版重新檢查一次。字型在桌面版看起來完美,到了手機版可能因為渲染引擎或系統字型回退機制而走樣,尤其是襯線字型在小螢幕上的表現常常不如預期。別假設桌面版 OK 就等於全裝置 OK。
自己託管還是走 CDN:自訂字型的兩條路
走到這裡,有一個更根本的問題值得停下來想一下:你手上這套字型,到底該自己託管在網站主機上,還是透過 Google Fonts 或字型廠商的 CDN 來送?這個選擇會直接影響你後面的效能調校工作量,所以值得在還沒動手之前先決定好。
自己託管的好處是控制權完整。字型檔放在你的主機上,@font-face 的每一個參數你都改得到,font-display、preload、子集化全部自己說了算,也不必擔心第三方 CDN 哪天變更網址或調整服務條款。對品牌字型來說,這通常是唯一可行的路,因為商業字型根本不會出現在公開的 CDN 上,你想走 CDN 也無路可走。
走 CDN 的好處是免去自行維護字型檔與快取標頭,但現代瀏覽器會依頂層網站分割 HTTP 快取(Chrome for Developers,2020 年 10 月),不能再假設訪客曾在別站載過同一套 Google Fonts,就能在你的網站直接共用快取。它的代價是多一道第三方連線,CDN 的回應與服務條款也不在你手上,隱私法規對第三方資源的要求仍要按網站所在地與受眾評估。
| 比較項目 | 自己託管 | 走 Google Fonts CDN |
|---|---|---|
| 能用的字型 | 任何有授權的字型(含商業、自鑄) | 僅限 Google Fonts 目錄 |
| 控制權 | 完整(font-display、preload、子集全可控) | 有限(CDN 端決定參數) |
| 快取特性 | 由自己的網域與快取設定控制 | 現代瀏覽器通常按網站分割快取,沒有可靠的跨站共用優勢 |
| 隱私顧慮 | 低(資源自給自足) | 需評估第三方請求與 GDPR |
| 適合場景 | 品牌字型、中文標題子集 | 內文用的通用拉丁字型 |
實務上的判斷原則是這樣:品牌字型(商業字型、自鑄字型、子集化過的中文標題字)走自己託管,因為這是唯一選項;通用字型,尤其是內文用的拉丁字型,如果剛好就在 Google Fonts 目錄上,走 CDN 通常更省事。很多品牌站最終是混用的:標題自己託管、內文走 CDN,兩邊各取所長。這樣看來,建議你把「字型要不要自託管」當成一個獨立的決策,而不是一股腦把所有字型都塞進主機。
自訂字型為什麼會拖垮 Core Web Vitals
很多人把字型上傳完,就以為事情結束了。沒有。自訂字型是網站的資源,每一個字型檔都是瀏覽器要下載、解析、渲染的東西。處理不好,它就是你網站速度的隱形殺手。Google 在評估頁面體驗時(2020 年 5 月的官方說明),把載入效能列為明確的考量項目,而字型是影響載入效能的常見兇手之一。
字型拖慢網站,主要有兩個機制。第一個是「渲染阻塞」。當瀏覽器遇到一個還沒下載完的字型,它的預設行為是「先不顯示這段文字」,等到字型下載好再一起畫出來。這個行為叫 FOIT(Flash of Invisible Text),它會讓你的 Largest Contentful Paint(LCP)往後推。如果你的首屏標題用的是自訂字型,而這個字型又下載得慢,你的 LCP 就會被它拖著走。
第二個機制是「版面位移」。字型下載完成、文字從回退字型切換成自訂字型的那一刻,如果兩個字型的寬度與行高不一樣,頁面上的元素會跟著跳動。這個跳動會累積成你的 CLS(Cumulative Layout Shift)分數。Google 自己在 web.dev 的速度研究中也指出,頁面載入每多花一秒,使用者的離開機率就會顯著上升,轉換也會跟著掉。換句話說,字型造成的速度損失,不僅是分數好看不好看的問題,它會直接吃掉你的名單與訂單。
那怎麼辦?難道為了速度就不用自訂字型了嗎?當然不是。關鍵在於你怎麼「安排」字型的下載時機。兩個動作可以解掉八成的問題:
- 指定 font-display:告訴瀏覽器「先用回退字型把字畫出來,等自訂字型好了再換」。這會把 FOIT 變成 FOUT(Flash of Unstyled Text),文字從頭到尾都看得到,僅是中間會換一次字體。對絕大多數品牌字型來說,這個交換是值得的。
- 預載入關鍵字型:用
<link rel="preload">告訴瀏覽器「這個字型很重要,請提早開始下載」。這會把字型下載的時間點往前拉,縮短它阻塞渲染的窗口。
這兩個動作的具體寫法,後面的章節會給你。現在先記住一個觀念:自訂字型的速度成本,是可以被管理的,僅是它不會自己變好。你需要主動設定,上傳完就放著,等於把問題留給訪客去承受。如果你對整體的網站速度優化還沒有完整概念,建議把字型這塊當成其中一環,搭配快取、圖片壓縮一起處理,效果才會疊加得上來。
中文字型千萬別整包上傳:子集化才是正解
這一節是寫給做繁體中文網站的人看的,也是多數教學最該講、卻最少講的一段。如果你打算在 Divi 上傳一套完整的中文字型,請先停下來,這裡有一個大坑在等你。
英文字型很小,因為拉丁字母僅有幾十個字元,一個字重 50 到 200KB 就能打包完。中文字型完全是另一個量級。一套涵蓋常用字的繁體中文字型,單一個 Regular 字重,TTF 檔案可以大到 5 到 20MB。這是因為它要為成千上萬個漢字各自儲存一套曲線資料,沒有捷徑。
把一個 15MB 的字型丟上網站會發生什麼事?瀏覽器會試圖下載它,但在它下載完成之前,你的文字要嘛隱形、要嘛用回退字型頂著。更糟的是,很多行動裝置的瀏覽器遇到這麼大的字型檔,會直接放棄下載,回退到系統字型,結果你的品牌字型在手機上根本沒被套用,你卻完全不知道。15MB 的頻寬還是白白消耗了。
正解是「子集化」(subsetting)。子集化的意思是:把字型檔裡你「用不到」的字元全部刪掉,僅保留你真正會顯示的那一批。對一個品牌站來說,你真正需要品牌字型的地方,往往僅有 logo 文字、首頁主標題、幾個區塊標題,加起來可能不到兩百個字。把字型子集化到這兩百個字,一個 15MB 的檔案可以縮小到 100KB 上下,跟英文字型同一個量級。這時候上傳到 Divi,速度才不會出問題。
中文字型子集化適合字元範圍可預測的頁面;內容頻繁新增、使用者輸入或多語系網站則要考慮缺字與維護成本。可依內容型態採預先產生多個子集、unicode-range、系統字型或完整字型等方案,再用實際載入資料比較效能。
如果你做的網站有大量中文內文,又想要一致的視覺,一個折衷方案是:用一套子集化過的中文品牌字型來做標題與 logo,內文則交給 本機託管的 Google Fonts 或系統字型。這樣你既保住了品牌的字型辨識度,又不會被字型檔案的大小壓垮。這個取捨沒有標準答案,要看你的品牌規範有多嚴格,但「標題用品牌字、內文用通用字」是一個經過實戰驗證、CP 值最高的組合。
選字這件事本身也值得多花點心思,尤其是英文字型。如果你還沒有明確方向,可以從精選英文字體清單裡挑幾款來試,先把候選名單縮小,再進到 Divi 實測渲染效果,會比漫無目的地試一整天有效率得多。
消除文字「閃一下」:font-display 與預載入設定
前面承諾過的具體寫法,在這一節交給你。這兩個設定不會出現在 Divi 的圖形介面裡,你得自己加一小段程式碼,但它的效果是立竿見影的。
第一個動作是指定 font-display。這個 CSS 屬性控制的是「字型還沒下載好時,瀏覽器該怎麼處理文字」。它有五個值,直接給你結論:
| 值 | 行為 | 適用場景 |
|---|---|---|
| auto | 交給瀏覽器決定(通常等同 block) | 不建議明確指定 |
| block | 先隱藏文字,等字型(最多三秒) | 不建議,會造成 FOIT |
| swap | 立刻用回退字型顯示,字型好了就換 | 品牌字型、標題、logo 首選 |
| fallback | 極短時間隱藏,之後回退,字型若很快好才換 | 內文字型可用 |
| optional | 由瀏覽器依網路狀況決定要不要用 | 非關鍵的裝飾字型 |
實務上的預設選擇是:品牌字型與標題用 swap,內文用 fallback 或 optional。這樣可以確保文字永遠看得到,又不會讓品牌字型在最關鍵的視覺位置上缺席太久。
選一個「算得上來」的回退字型
font-display 設成 swap 之所以有效,有一個前提常被忽略:你的回退字型(fallback font)跟自訂字型不能差太多。如果自訂字型是現代無襯線,回退字型卻被瀏覽器抓成襯線的 Times New Roman,那一瞬間的切換會非常明顯,訪客會看到文字整個「跳」一下。這個跳動,就是 CLS 分數最常見的來源之一。
要降低這個落差,你可以在 CSS 裡明確指定一段回退字型堆疊(font stack),讓它在字距與 x-height 上盡量貼近你的自訂字型。例如自訂字型是類似 Inter 的現代無襯線,回退堆疊就寫成 'BrandSans', -apple-system, 'Segoe UI', 'PingFang TC', 'Microsoft JhengHei', sans-serif。這段堆疊的設計邏輯是:先試品牌字型,沒有就用蘋果系統字、再沒有就用微軟系統字,最終才退到通用 sans-serif。每一層都是無襯線、x-height 接近,切換時的視覺落差會被壓到最小。
這個細節看起來不起眼,卻往往是「字型明明設了 swap,CLS 還是偏高」的真正原因。回退字型選得好,swap 的那一瞬間幾乎看不出來;選得差,每一次頁面載入都會有一次明顯的位移。對追求品牌一致度的站來說,這個功夫值得花,而且它的成本僅是一行 CSS。
把這個設定加進 Divi 的方法,是透過 Divi → Theme Options → Integration → Add code to the head,寫一小段 CSS。如果你走的是子主題路線,也可以直接寫進子主題的 stylesheet。大致長這樣:
@font-face {
font-family: 'BrandSans';
src: url('/wp-content/uploads/BrandSans-Regular.woff2') format('woff2'),
url('/wp-content/uploads/BrandSans-Regular.woff') format('woff');
font-weight: 400;
font-style: normal;
font-display: swap;
}
請注意,上面這個寫法是給你「手動指定 @font-face」的情況用的。如果你完全靠 Divi 的 Upload Font 按鈕上傳,Divi 會產生一段 @font-face,但 font-display 的輸出仍應用瀏覽器開發工具確認。網站若需要精確控制字重、子集與載入策略,可以用覆寫 CSS 或子主題自行設定。
再來是預載入。預載入的作用是提高重要字型資源的優先度,讓下載能提早開始,但不保證一定早於畫面渲染完成。你可以在 head 裡加一行:
<link rel="preload" href="/wp-content/uploads/BrandSans-Regular.woff2" as="font" type="font/woff2" crossorigin>
這一行有三個地方不能錯:as="font" 告訴瀏覽器這是字型資源、type="font/woff2" 標明格式、crossorigin 讓預載請求採用與後續字型抓取一致的 CORS 模式,即使字型放在同一網域也應保留。模式不一致時,瀏覽器可能無法重用預載結果而再次下載。
預載入僅該用在「最重要的那一兩個字型」上,通常是首屏標題與內文字型。不要把網站上所有字型都預載入,那會把頻寬與瀏覽器的並行下載通道全部佔滿,反而拖慢其他資源。預載入是手術刀,不是散彈槍。
字體上傳後出問題:一份排查清單
這一節是給已經上傳完、卻發現字型表現不如預期的人。以下整理一份實務上最常遇到的字型問題清單。每一個都是實務上常見的坑,給你當除錯的起點。如果你遇到的是這份清單以外的狀況,回頭從「格式、授權、路徑、快取」這四個面向逐一排查,通常八九不離十。
| 症狀 | 最可能的原因 | 怎麼修 |
|---|---|---|
| 字型上傳後,下拉選單裡找不到它 | 檔案格式不被接受,或檔案超過主機的上傳限制 | 確認是 OTF/TTF/WOFF/WOFF2;調高 php.ini 的 upload_max_filesize;仍被擋時用 upload_mimes 過濾器開放 woff2 上傳 |
| 字型選了,但文字顯示成方塊或缺字 | 字型檔本身沒有包含這些字元(子集化過頭,或本來就不支援該語系) | 改用包含完整字元的版本,或重新子集化補上缺字 |
| 桌面版正常,手機版字型跑掉 | Divi 的手機版有獨立的字型設定,沒有繼承桌面版 | 在手機版斷點重新指定字型,或在自訂 CSS 裡統一 |
| 字型有套用,但頁面載入時文字閃一下 | font-display 沒設成 swap,或字型未被預載入 | 加上 font-display: swap,對關鍵字型加 preload |
| 改了字型,前端卻沒變 | 快取外掛或瀏覽器快取還在舊版 | 清除 Divi 的靜態 CSS 快取、清快取外掛、強制重新整理 |
| PageSpeed Insights 顯示字型阻塞渲染 | 字型未預載入、或一次載入太多字重 | 僅預載入首屏字型,移除用不到的字重 |
這張表裡有一個最容易被錯過的兇手,是「快取」。Divi 自己有一組靜態 CSS 快取,你改了字型設定之後,如果沒有到 Divi → Theme Options → Builder → Advanced 清掉它,前端可能還在吃舊的 CSS。再加上你若有裝快取外掛或WP Rocket這類工具,就得多清一層。養成「改完設定就清快取」的習慣,可以幫你省下大量「明明改對了卻看不到效果」的焦慮。
在動任何字型設定之前,請先備份。字型雖然不會直接動到資料庫,但如果你走子主題路線改了 CSS、或在 Theme Options 動了全域設定,一個不小心就可能讓整個網站的文字樣式走樣。備份成本很低,UpdraftPlus 這類工具排程一下就好,遇到問題時也能快速還原。
收尾:把自訂字型做對的六步走法
講了這麼多,整件事可以濃縮成一份你可以照著走的行動清單。這不是理論,而是品牌站專案裡反覆驗證過的順序,照著做可以避開絕大多數的坑。
- 先備份。在動字型設定之前,用備份外掛做一次完整備份。這是保險,不是麻煩。
- 確認授權。回頭翻字型的 EULA,確認它允許 web embedding。不確定的,當成不能用。
- 轉成 WOFF2。用 Transfonter 或 Font Squirrel 轉檔;需要支援舊版瀏覽器時再補 WOFF,中文字型則應子集化到必要字元。
- 在 Divi 上傳。進 Visual Builder,打開任一文字模組的 Design 標籤,點 Upload Font,填好名稱與字重。
- 全域套用並設 font-display。用 Theme Builder 設全域預設,再補上 font-display: swap 與關鍵字型的 preload。
- 驗證。用開發者工具看字型是否被正確下載,用 速度測試工具確認沒有新增渲染阻塞,再切到手機版複檢一次。
字型這件事,做對了,它會在你之後每一次打開那個網站的時候,安安靜靜地替你說話,讓品牌在第一眼就被認出來。做錯了,它會用載入速度、版面跳動、授權帳單各種方式,在你最不希望的時候找上你。兩者的差別,往往不在於你用了多貴的字型,而在於你有沒有把上面這六步走完。
如果你正在用 Divi 從零打造一個品牌站,這篇文章處理的是字型這一塊;但一個完整的品牌形象網站,還牽涉到主題整體掌握、版型挑選與頁面編輯器的選擇。你可以順著把Divi 主題終極指南與頁面編輯器比較一起讀完,把全站的基礎一次打穩。字型是品牌的聲音,而一個能持續被信任的品牌站,需要的是每一個環節都到位,不僅是聲音好聽而已。現在,輪到你把這六步動手做出來了。
常見問題
Divi 可以上傳哪些字體格式?支援 WOFF 或 WOFF2 嗎?
字型上傳後,Divi 下拉選單裡找不到它,怎麼排查?
中文字型要怎麼用在 Divi 才不會拖垮速度?
在 Divi 用自訂字型會拖慢網站速度嗎?
操作步驟
- 確認字型授權允許商業用途與網頁嵌入,並把授權證明保留下來。
- 把授權允許的原始 OTF/TTF 轉成 WOFF2,需要支援舊版瀏覽器時再一併輸出 WOFF 備援,中文字型順手用子集化只保留必要字元。
- 進 Visual Builder,打開任一文字模組的 Design 標籤,點 Font Family 下拉選單裡的 Upload Font,填好 Font Name 與 Supported Weights 後套用,字型即全站可用。
- 上傳後跑一遍驗證清單:清除快取、Network 面板確認字型檔回應 200、檢查行動版一致性、逐頁掃缺字。