Divi 自訂字型：TTF／OTF 上傳與 WOFF2 自架教學

想像一下這個畫面：你花了兩個禮拜，用 Divi 把一個品牌官網從無到有拉出來，配色、間距、圖片全部到位，前後對比測試也跑過了。你興沖沖地把預覽連結丟給客戶，對方看了三秒，回了一句：「看起來跟我上週看過的另一個網站好像。」

問題往往不在配色，也不在版面。問題出在字型。Divi 內建的字型庫雖然齊全，但那是「所有人都拿得到」的資源，當你的競爭對手也用同一套 Google Fonts 時，你的品牌辨識度從第一眼就被歸零。字型是品牌的聲音，它在你開口之前就先替你說話了。

核心重點：若用 Divi 內建 Upload Font，先核對字型授權並準備 TTF／OTF，再到 Visual Builder 的文字模組選 Upload Font、設定名稱與實際字重。若要用 WOFF2，須另走允許自架的 @font-face 路線；font-display 與 preload 則應按前台量測決定。

為什麼 Divi 內建字型庫，滿足不了真正的品牌站

先說結論：Divi 內建的字型庫對九成的入門專案來說綽綽有餘。它接了 Google Fonts 的完整目錄，也允許你在 Theme Customizer 的 Typography 或 Builder 的全域字型設定中選擇標題與內文字型。如果你做的是一個在地咖啡館的介紹頁、一個活動 landing page，內建字型完全夠用，沒必要自找麻煩。

但「夠用」跟「有辨識度」是兩件事。實務上常見許多網站，配色用心、圖片精挑，卻因為字型跟隔壁競品一模一樣，整體看起來就是「哪裡都看得到的網站」。這種感覺很微妙，訪客說不出哪裡怪，但你就是很難記住它。對一個打算長期經營的品牌來說，這種「面目模糊」其實是比載入慢更隱性的傷害，因為它一點一滴吃掉的是品牌被想起來的機會。

若品牌規範指定特定字型，可先確認授權是否允許網頁嵌入，再依網站架構選擇 Divi 自訂字型、佈景主題設定、外掛或 @font-face。Divi 上傳是其中一種管理方式，不是唯一選項。

這件事之所以比「換個漂亮字體」更值得看重，是因為字型承擔的品牌工作量，往往比配色還大。你可以把一個網站的配色全部抽換掉，僅需字型還在，品牌的氣質就還在；反過來，一旦字型換掉，整個品牌的個性會瞬間變樣。這樣看來，建議在動手改配色之前，先把字體與排版的底層邏輯想清楚，再回頭處理品牌色。順序錯了，後面的調整會事倍功半。

說穿了，自訂字型不是「讓網站變漂亮」的化妝品，而是「讓品牌可以被辨識」的基礎建設。這也是為什麼它值得你花一篇文章的篇幅，好好搞懂格式、授權與效能這三件事。

上傳之前，先搞懂四種網頁字型格式

很多人卡在上傳這一步，問題很少出在 Divi 本身，多半出在手上的字型檔案格式不對。在你點下那個「Upload Font」按鈕之前，先花三分鐘認識四種你一定會遇到的格式。這三分鐘會幫你省下後面三小時的除錯時間。

先分清兩條實作路線：Divi 內建 Upload Font 接受 TTF／OTF；若要以前台常用的 WOFF／WOFF2 傳輸，則須確認授權後另外設定檔案路徑與 @font-face。格式沒有固定的四階段升級順序。

這裡的關鍵差異是「壓縮」。OTF 與 TTF 是為桌面排版設計的，它們要把字型送進印刷廠，所以保留了完整的曲線資料與提示（hinting）資訊，檔案自然大。實際大小取決於字元數、字重、可變字型與壓縮方式；繁體中文字型常比僅含拉丁字母的檔案大得多。上線前應檢查每個實際載入的字型檔與裝置網路請求。

WOFF 與 WOFF2 則是專為網頁而生的。它們本質上是把同一套字型曲線「打包壓縮」過的容器，WOFF2 用的還是 Google 的 Brotli 演算法，壓縮率比 WOFF 再高一截。WOFF2 通常可減少傳輸大小，實際節省幅度仍要看字型內容與子集。選 Divi 內建 Upload Font 時依官方文件準備 TTF／OTF；若要以 WOFF2 送到前台，改用授權允許的自架 @font-face，並在目標瀏覽器實測。

2026 年面向現代瀏覽器的網站，通常準備 WOFF2 就夠了；若專案明確需要支援不相容 WOFF2 的舊版瀏覽器，再補 WOFF 備援。Divi 內建上傳介面以 TTF／OTF 為主；若使用 WOFF2，應另規劃自架路徑與 @font-face，是否需要備援應由瀏覽器支援範圍決定（見 web.dev 的字型優化指南，2026 年 7 月）。

字體授權：比格式轉換更容易踩雷的一關

格式選錯，頂多字型顯示不出來，修一下就好。授權搞錯，可能是一封律師函的問題。這一關被絕大多數教學跳過，但對做品牌站的人來說，它才是最該被認真對待的。

字型授權不是「我買了就能用在任何地方」這麼單純。同一家字體廠商通常會把授權拆成好幾種，每一種對應一種使用情境：

• Desktop 授權：讓你在設計軟體裡用這套字型做海報、做簡報、做印刷品。是否包含網站自架權利，取決於該字型的具體授權條款，不能只看授權名稱。
• Webfont 授權：才是允許你用 @font-face 把字型嵌入網站的那種。授權可能限制嵌入方式、網域、用量或是否可自行託管；例如 Adobe Fonts 的網站使用須採官方嵌入碼。
• App 授權：給手機 App 內嵌字型用，跟網站是兩條授權線。
• OFL 與免費授權：SIL Open Font License（OFL）這類開源條款，明確允許商用與網頁嵌入。Google Fonts 提供可商用的開源字型；下載或修改前，仍應核對該字型頁面的個別授權。

最容易出事的情境是這個：設計師在公司電腦裡裝了一套商業字型做印刷物，客戶看了很喜歡，順手把同一個字型檔拿去做網站。這時候你拿到的，是一份 Desktop 授權的檔案，它的 EULA（終端使用者授權協議）裡很可能寫著「禁止 web embedding」或「禁止 @font-face 使用」。你把它上傳到 Divi，技術上完全跑得動，但合約上你已經違約了。

那實務上會怎樣？實際授權爭議的處理與費用依廠商和合約而異，不能預先推定。較穩妥的做法是記錄字型來源、購買證明、允許的網站使用方式及客戶帳號歸屬；不確定時向授權方確認。

實務上的判斷標準很簡單，給你當參考：來源不明的字型檔，預設當成「不能上網」；明確標示 OFL 或 Apache License 的，可以放心用；商業字型，一定要回頭翻它的 EULA，找到「web embedding」或「@font-face」相關條款，確認你的使用量落在授權範圍內。如果你打算長期經營這個品牌站，這一步省不得。

需要自架 WOFF2 時，如何轉檔與設定

確認授權沒問題之後，接下來就是格式轉換。字型廠商提供的檔案與授權各不相同。若走 Divi 內建上傳，官方支援 TTF／OTF，無須先轉 WOFF2；若走自架 @font-face，則可在授權允許時產生 WOFF2。這一步不難，但有幾個細節會影響成品品質。

實務上常用的轉檔工具有三個，你可以依喜好挑一個：

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

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

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

還有一個小細節：轉出來的檔案命名，建議保留字型家族名與字重，例如 BrandSans-Regular.woff2、BrandSans-Bold.woff2。清楚命名可幫你管理檔案。注意：Divi 內建上傳表單處理 TTF／OTF；若你轉出 WOFF2，應在自架 @font-face 的路徑與 font-weight 對照，不要把它送進 Upload Font。這種「現在多花三十秒，未來省三十分鐘」的習慣，在多站維護的時候特別有感。

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」的選項）。點下去之後，會開啟自訂字型表單，選擇可支援的 TTF／OTF 檔並設定字重。

這裡有兩個欄位要填：

• Font Name：這個名字會出現在整個網站的字型下拉選單裡，建議用字型的官方家族名，方便之後辨識。
• Supported Weights：勾選你這個檔案實際包含的字重。如果你僅上傳 Regular，就僅勾 Regular；如果你之後會陸續補上 Bold 與 Light，可以先把對應的欄位留著。

上傳時要將 Supported Weights 設為檔案實際包含的字重；要提供 Regular、Bold 等多個字重時，先確認每個檔案與字重的對應，再在前台檢查是否合成粗體。

動作三：套用到模組，字型即刻可用

上傳完成後，新的字型會立刻出現在 Font Family 下拉選單裡，而且不僅這個模組看得到，整個網站所有模組的字型選單都會出現它。選下去，文字就會套用新字型。這就是「三步驟」的完整樣貌：打開模組、上傳檔案、套用。

有一個關鍵觀念要講清楚：Divi 的自訂字型一旦上傳，就是「全站可用」的資源，它不是綁死在某一個模組上。這代表你僅需上傳一次，就可以在標題設計、內文、按鈕、頁首任何地方重複選用它。很多人誤以為每個頁面都要重新上傳，那是浪費時間。

上傳之後，建議你立刻做一件事：開瀏覽器的開發者工具，切到 Network 面板，重新整理頁面，看看那個字型檔有沒有被正確請求、回傳的狀態碼是不是 200、檔案大小符不符合預期。這個十秒鐘的檢查，可以在字型「看起來套用了但其實沒有」的時候，第一時間抓到問題。

全站字型怎麼套用：Typography、Global Fonts 與子主題

把字型上傳成功，僅是第一步。接下來的問題是：你要怎麼讓它變成整個網站的預設字型，而不是僅在某一個模組裡用？這牽涉到兩條路線，搞清楚它們的差別，你才知道該走哪一條。

第一條路線是先把 TTF／OTF 透過 Divi Upload Font 加入，再到 Divi → Theme Customizer → General Settings → Typography 選作全站字型，或在文字模組的 Edit Global Fonts 設定標題字型。Theme Builder 可處理頁首、頁尾與頁面範本，但它不是內建字型上傳後設定全站 Typography 的唯一入口；既有模組覆寫仍須逐頁檢查。

若要核對全站 Typography，請先看 Divi → Theme Customizer → General Settings → Typography；官方也說上傳後可從文字模組的 Edit Global Fonts 修改全域標題字型。不要把 Theme Options 的 General 頁籤或 Theme Builder 模板誤當成所有字型設定的固定入口；Divi 4／5 介面差異以當前版本為準。

還有第三條路線，是給進階使用者的：用子主題手動寫 @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 哪天變更網址或調整服務條款。對品牌字型要先看授權：有些允許自行託管，有些（如 Adobe Fonts 服務）要求官方嵌入碼與託管方式，不能一律自行上傳。

走 CDN 的好處是免去自行維護字型檔與快取標頭，但現代瀏覽器會依頂層網站分割 HTTP 快取（Chrome for Developers，2020 年 10 月），不能再假設訪客曾在別站載過同一套 Google Fonts，就能在你的網站直接共用快取。它的代價是多一道第三方連線，CDN 的回應與服務條款也不在你手上，隱私法規對第三方資源的要求仍要按網站所在地與受眾評估。

實務上的判斷原則是這樣：品牌字型先依授權決定自架或使用廠商的嵌入服務；通用字型，尤其是內文用的拉丁字型，如果剛好就在 Google Fonts 目錄上，走 CDN 通常更省事。很多品牌站最終是混用的：標題自己託管、內文走 CDN，兩邊各取所長。這樣看來，建議你把「字型要不要自託管」當成一個獨立的決策，而不是一股腦把所有字型都塞進主機。

自訂字型為什麼會拖垮 Core Web Vitals

很多人把字型上傳完，就以為事情結束了。沒有。自訂字型是網站的資源，每一個字型檔都是瀏覽器要下載、解析、渲染的東西。處理不好，它就是你網站速度的隱形殺手。Google 在評估頁面體驗時（2020 年 5 月的官方說明），把載入效能列為明確的考量項目，而字型是影響載入效能的常見兇手之一。

字型拖慢網站，主要有兩個機制。第一個是「渲染阻塞」。字型未下載完成時，文字如何顯示取決於 font-display、瀏覽器與載入時序。若首屏關鍵文字進入短暫不可見階段，可能延後 LCP；應以實際頁面的瀏覽器量測判斷。如果你的首屏標題用的是自訂字型，而這個字型又下載得慢，你的 LCP 就會被它拖著走。

第二個機制是「版面位移」。字型下載完成、文字從回退字型切換成自訂字型的那一刻，如果兩個字型的寬度與行高不一樣，頁面上的元素會跟著跳動。這個跳動會累積成你的 CLS（Cumulative Layout Shift）分數。字型切換也可能帶來 CLS。web.dev 的速度研究討論頁面速度與體驗，但不能從單一字型設定直接推定名單或訂單的變化；應量測真實使用者資料、字型載入時序與轉換流程。

那怎麼辦？難道為了速度就不用自訂字型了嗎？當然不是。關鍵在於你怎麼「安排」字型的下載時機。可先檢查兩個常見設定，再由量測決定是否需要進一步調整：

• 檢查 font-display：swap 通常讓後備字型先顯示、字型就緒後再切換；這能縮短不可見文字階段，但字型尺寸不同可能造成 CLS。依實際頁面比較 swap、optional 與後備字型設定。
• 只預載入已確認的關鍵字型：先用 Network 與實際頁面量測，僅對首屏確實需要的字型考慮 <link rel="preload">；過多預載入可能與其他資源競爭，且會略過 unicode-range 的字型選擇。

這兩個動作的具體寫法，後面的章節會給你。現在先記住一個觀念：自訂字型的速度成本，是可以被管理的，僅是它不會自己變好。你需要主動設定，上傳完就放著，等於把問題留給訪客去承受。如果你對整體的網站速度優化還沒有完整概念，建議把字型這塊當成其中一環，搭配快取、圖片壓縮一起處理，效果才會疊加得上來。

中文字型千萬別整包上傳：子集化才是正解

這一節是寫給做繁體中文網站的人看的，也是多數教學最該講、卻最少講的一段。如果你打算在 Divi 上傳一套完整的中文字型，請先停下來，這裡有一個大坑在等你。

拉丁字與繁體中文字型的大小，取決於收錄字元、字重、格式與子集策略；完整中文字集通常需要更多資料。不要用固定 KB／MB 區間估算速度，先看實際檔案大小和瀏覽器 Network 請求。

如果頁面載入 15 MB 字型，行動網路使用者可能需要額外下載大量資料；文字先顯示後備字型或延後繪製，取決於 font-display 與瀏覽器。請用 Network、LCP、CLS 的實測確認它對首屏的影響，再決定子集、字重或後備字型方案。

子集化（subsetting）是只保留實際需要的字元；適合字元可預測的 Logo 與標題。若文字會更新，須規劃缺字的後備字型與維護方式，並量測各字重實際檔案大小。自架 WOFF2 子集與 Divi 內建 TTF／OTF 上傳是不同路線，不能把輸出的 WOFF2 直接交給 Upload Font。

中文字型子集化適合字元範圍可預測的頁面；內容頻繁新增、使用者輸入或多語系網站則要考慮缺字與維護成本。可依內容型態採預先產生多個子集、unicode-range、系統字型或完整字型等方案，再用實際載入資料比較效能。

如果你做的網站有大量中文內文，又想要一致的視覺，一個折衷方案是：用一套子集化過的中文品牌字型來做標題與 logo，內文則交給 本機託管的 Google Fonts 或系統字型。這樣你既保住了品牌的字型辨識度，又不會被字型檔案的大小壓垮。這個取捨沒有標準答案，要看你的品牌規範有多嚴格，但「標題用品牌字、內文用通用字」是一個經過實戰驗證、CP 值最高的組合。

選字這件事本身也值得多花點心思，尤其是英文字型。如果你還沒有明確方向，可以從精選英文字體清單裡挑幾款來試，先把候選名單縮小，再進到 Divi 實測渲染效果，會比漫無目的地試一整天有效率得多。

消除文字「閃一下」：font-display 與預載入設定

前面承諾過的具體寫法，在這一節交給你。若採自架 @font-face，可明確設定 font-display，必要時加入 preload；若使用 Divi 上傳，先在前台檢查產生的 CSS 與實際請求，不要假設所有版本都需同一段覆寫碼。效果也應以量測確認。

第一個動作是指定 font-display。這個 CSS 屬性控制的是「字型還沒下載好時，瀏覽器該怎麼處理文字」。它有五個值，直接給你結論：

實務上的預設選擇是：品牌字型與標題用 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。

下方 @font-face 可放在 Divi → Theme Options → General → Custom CSS 或子主題 style.css；若改放 Integration 的 head 欄位，必須用 <style>...</style> 包住 CSS。範例路徑和檔名也要改成網站實際資源：

@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 模式，即使字型放在同一網域也應保留。模式不一致時，瀏覽器可能無法重用預載結果而再次下載。

預載入僅該用在「最重要的那一兩個字型」上，通常是首屏標題與內文字型。不要把網站上所有字型都預載入，那會把頻寬與瀏覽器的並行下載通道全部佔滿，反而拖慢其他資源。預載入是手術刀，不是散彈槍。

字體上傳後出問題：一份排查清單

這一節是給已經上傳完、卻發現字型表現不如預期的人。以下整理一份實務上最常遇到的字型問題清單。每一個都是實務上常見的坑，給你當除錯的起點。如果你遇到的是這份清單以外的狀況，回頭從「格式、授權、路徑、快取」這四個面向逐一排查，通常八九不離十。

這張表裡有一個最容易被錯過的兇手，是「快取」。Divi 自己有一組靜態 CSS 快取，你改了字型設定之後，如果沒有到 Divi → Theme Options → Builder → Advanced 清掉它，前端可能還在吃舊的 CSS。再加上你若有裝快取外掛或WP Rocket這類工具，就得多清一層。養成「改完設定就清快取」的習慣，可以幫你省下大量「明明改對了卻看不到效果」的焦慮。

在動任何字型設定之前，請先備份。字型雖然不會直接動到資料庫，但如果你走子主題路線改了 CSS、或在 Theme Options 動了全域設定，一個不小心就可能讓整個網站的文字樣式走樣。備份成本很低，UpdraftPlus 這類工具排程一下就好，遇到問題時也能快速還原。

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

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

1. 先備份。在動字型設定之前，用備份外掛做一次完整備份。這是保險，不是麻煩。
2. 確認授權。回頭翻字型的 EULA，確認它允許 web embedding。不確定的，當成不能用。
3. 選定路線。Divi 內建上傳準備 TTF／OTF；若需要自架 WOFF2，先確認授權允許轉換與託管，再規劃子集、路徑及 @font-face。
4. 依路線加入字型。TTF／OTF 可在 Visual Builder 的文字模組點 Upload Font；自架 WOFF2 則放在授權允許的位置，並以 @font-face 宣告，不會自動出現在 Divi 字型下拉選單。
5. 套用並量測。內建上傳可在 Theme Customizer 的 Typography 或 Edit Global Fonts 選字；自架字型則設定 CSS，按需要測試 font-display、fallback 與 preload。
6. 驗證。用開發者工具看字型是否被正確下載，用 速度測試工具確認沒有新增渲染阻塞，再切到手機版複檢一次。

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

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