Whoops

想像一下這個畫面:你花了兩個禮拜,用 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 上傳嗎
OTFOpenType Font桌面排版與印刷無壓縮可以,但檔案偏大
TTFTrueType Font較早期的桌面字型無壓縮可以,但檔案偏大
WOFFWeb Open Font Format專為網頁設計的壓縮容器有壓縮舊版瀏覽器相容需求才使用
WOFF2WOFF 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通用格式轉換站介面直覺、支援多種格式互轉無字型專屬的子集功能

轉檔的標準流程是這樣的:

  1. 準備好授權允許網頁使用的原始字型檔,通常是一個或多個字重的 OTF/TTF。
  2. 到 Transfonter 或 Font Squirrel,把檔案上傳。
  3. 選擇 WOFF2;若專案明確支援舊版瀏覽器,再一併輸出 WOFF。
  4. 若要做中文字型的子集化(這是中文站的大重點,下面會專門講),在子集欄位填入你要保留的字元。
  5. 下載轉好的壓縮檔,確認其中有 woff2 與示範 CSS;需要舊版備援時才保留 woff。

有一個觀念要特別提醒:轉檔本身是中性的技術動作,但它不能讓你「洗白」授權。如果你的原始字型不允許網頁嵌入,把它轉成 WOFF2 再上傳,違約的性質完全一樣。轉檔解決的是「格式不相容」這個技術問題,不是「沒有授權」這個法律問題。兩件事不要混為一談。

還有一個小細節:轉出來的檔案命名,建議保留字型家族名與字重,例如 BrandSans-Regular.woff2BrandSans-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,內文用 fallbackoptional。這樣可以確保文字永遠看得到,又不會讓品牌字型在最關鍵的視覺位置上缺席太久。

選一個「算得上來」的回退字型

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 這類工具排程一下就好,遇到問題時也能快速還原。

收尾:把自訂字型做對的六步走法

講了這麼多,整件事可以濃縮成一份你可以照著走的行動清單。這不是理論,而是品牌站專案裡反覆驗證過的順序,照著做可以避開絕大多數的坑。

  1. 先備份。在動字型設定之前,用備份外掛做一次完整備份。這是保險,不是麻煩。
  2. 確認授權。回頭翻字型的 EULA,確認它允許 web embedding。不確定的,當成不能用。
  3. 轉成 WOFF2。用 Transfonter 或 Font Squirrel 轉檔;需要支援舊版瀏覽器時再補 WOFF,中文字型則應子集化到必要字元。
  4. 在 Divi 上傳。進 Visual Builder,打開任一文字模組的 Design 標籤,點 Upload Font,填好名稱與字重。
  5. 全域套用並設 font-display。用 Theme Builder 設全域預設,再補上 font-display: swap 與關鍵字型的 preload。
  6. 驗證。用開發者工具看字型是否被正確下載,用 速度測試工具確認沒有新增渲染阻塞,再切到手機版複檢一次。

字型這件事,做對了,它會在你之後每一次打開那個網站的時候,安安靜靜地替你說話,讓品牌在第一眼就被認出來。做錯了,它會用載入速度、版面跳動、授權帳單各種方式,在你最不希望的時候找上你。兩者的差別,往往不在於你用了多貴的字型,而在於你有沒有把上面這六步走完。

如果你正在用 Divi 從零打造一個品牌站,這篇文章處理的是字型這一塊;但一個完整的品牌形象網站,還牽涉到主題整體掌握、版型挑選與頁面編輯器的選擇。你可以順著把Divi 主題終極指南頁面編輯器比較一起讀完,把全站的基礎一次打穩。字型是品牌的聲音,而一個能持續被信任的品牌站,需要的是每一個環節都到位,不僅是聲音好聽而已。現在,輪到你把這六步動手做出來了。

常見問題

Divi 可以上傳哪些字體格式?支援 WOFF 或 WOFF2 嗎?
Divi 接受 OTF、TTF、WOFF、WOFF2 四種格式,其中 WOFF2 因 Brotli 壓縮率最高、現代瀏覽器全部原生支援,是首選;WOFF 建議作為備援格式,OTF 與 TTF 檔案偏大、較不適合直接上傳。
字型上傳後,Divi 下拉選單裡找不到它,怎麼排查?
最常見原因是檔案格式不被接受,或檔案超過主機的上傳限制。先確認上傳的是 OTF/TTF/WOFF/WOFF2,再視需要調高 php.ini 的 upload_max_filesize;最後清掉 Divi 的靜態 CSS 快取與快取外掛,避免前端還在吃舊版。
中文字型要怎麼用在 Divi 才不會拖垮速度?
不要整包上傳。一套涵蓋常用字的繁體中文字型單一字重 TTF 可達 5 到 20MB,許多行動瀏覽器會直接放棄下載。正解是子集化:只保留 logo、主標題、幾個區塊標題真正會用到的字(往往不到兩百個字),把檔案縮到 100KB 上下;內文則交給系統字型或本機託管的 Google Fonts。
在 Divi 用自訂字型會拖慢網站速度嗎?
中文字型檔案大確實會影響載入速度,但可透過字型子集化、本地託管與設定 font-display: swap 來降低影響;最務實的折衷是標題用設計字型、內文用系統字型,兼顧美感與速度。

操作步驟

  1. 確認字型授權允許商業用途與網頁嵌入,並把授權證明保留下來。
  2. 把授權允許的原始 OTF/TTF 轉成 WOFF2,需要支援舊版瀏覽器時再一併輸出 WOFF 備援,中文字型順手用子集化只保留必要字元。
  3. 進 Visual Builder,打開任一文字模組的 Design 標籤,點 Font Family 下拉選單裡的 Upload Font,填好 Font Name 與 Supported Weights 後套用,字型即全站可用。
  4. 上傳後跑一遍驗證清單:清除快取、Network 面板確認字型檔回應 200、檢查行動版一致性、逐頁掃缺字。

主題聚落|WordPress 佈景主題 看「WordPress 與網站架設」中樞 →

相關文章

褚崇名(Sliven) 創辦人・巫普斯科技有限公司

長期投入技術 SEO、GEO/AEO 與 AI 搜尋實務。本站文章以可驗證資料、公開來源與實作觀察整理而成。

完整作者介紹LinkedInGitHubX

想把這篇的方法用在自己的站上?

SEO 健檢、GEO/AEO 引用優化、網頁設計諮詢——把文章裡的方法落地到你的網站。