同一個雙語網站上，中文頁面往往比英文頁面打開得慢——問題通常不在設計或伺服器，而在字體文件。中文字體要覆蓋的字符數量遠超英文字體，瀏覽器在顯示中文文字之前，往往要先下載一個大得多的文件。好消息是不需要重新設計網站：只讓瀏覽器下載頁面實際用到的字符，或者對中文正文乾脆不下載字體、直接用系統自帶字體，就能解決大部分問題。
為什麼網站的中文版感覺比英文版慢？
英文排版只需要拉丁字母、數字和標點，總共一百個左右的字符；中文常用字則有幾千個。根據谷歌官方 web.dev 文檔，中日韓（CJK）字體通常要覆蓋的字符數量，是拉丁字體的 15 到 20 倍——這也是為什麼同一頁面上，完整的中文字體文件體積常常是英文字體的好幾倍。手機網速稍慢時，訪客感受到的就是中文文字遲遲不出現，英文版卻正常打開。
這值得小企業官網花時間解決嗎？
值得，原因有兩個：主要內容多快出現（Largest Contentful Paint）是 Google 核心網頁指標之一，直接影響排名；而且這個問題容易被忽略——多數網站主只測試英文頁面，從沒單獨打開中文頁面檢查過。
最簡單的做法：中文正文乾脆不下載字體
每個主流作業系統都自帶高品質中文字體：蘋方（PingFang SC/TC）、微軟雅黑、Noto Sans CJK。把系統字體寫在自定義字體前面，瀏覽器就會直接用設備已裝好的字體顯示中文，零下載。這一個改動就能解決大部分問題，多數讀者也看不出設計差別：
font-family: "PingFang SC", "Microsoft YaHei", "Noto Sans CJK SC", sans-serif;
如果確實需要自定義中文字體，怎麼保持輕量？
有些品牌希望標題或 Logo 用特定中文字體。這時目標是只下載頁面實際用到的那些字，而非整套字符集。谷歌從 2011 年起就提供了內建做法：在谷歌字體請求裡加上 text= 參數，就能讓接口只返回請求中指明的字符，而非整個字體文件，這對中日韓字體同樣適用。配合 CSS 的 unicode-range——把字體按字符區間切成"切片"，瀏覽器只取用到的那一片——谷歌自己的 web.dev 文檔說明，這種做法相比下載完整字體，能把傳輸量減少約 90%。部分字體廠商也開始提供中日韓可變字體格式，把多個字重打包進一個文件——具體能省多少因廠商和字體而異，不要假設一個固定比例。
自查清單：10 分鐘測試你網站的雙語字體載入
- 打開中文首頁（不是英文版），用 Chrome 開發者工具 Network 面板，按 "Font" 過濾。
- 記下字體傳輸的 KB 數，和英文首頁對比——中文頁面明顯是好幾倍，就是本文說的情況。
- 檢查網站是在下載自定義中文字體，還是已用系統字體兜底。
- 確認 CSS 用了
font-display: swap，讓文字不會隱身等待字體下載完。 - 如果自定義字體只在標題或 Logo 真正需要，正文部分改用系統字體組合。
常見問題
換成系統字體，中文頁面看起來會不一樣嗎？
會有一點差別，但多數訪客不會注意到。蘋方、微軟雅黑、Noto Sans CJK 本身就是清晰易讀的中文字體，多數商家只需要在 Logo 或少數標題上用特定字體，正文不需要。
這個方法對英文頁面也有用嗎？
字符精簡和 unicode-range 對任何網頁字體都適用，但本文說的體積差距是中日韓字體特有的問題。如果英文頁面本來就快，主要收益是把中文頁面補到同一水平。
需要把網站重做一遍嗎？
不需要。這只是字體載入和 CSS 層面的調整，不會動到排版、配色或內容本身。
我們是怎麼做的
我們做雙語網站時，會把中文和英文頁面的字體載入分開測試——因為即便排版完全相同，兩個語言版本的實際表現也真的不一樣。中文正文預設採用系統字體組合，只在品牌真正需要的地方，才上自定義、做過字符精簡的中文網頁字體。
了解我們如何打造雙語網站，請看網站設計服務頁面，或免費申請一次網站字體載入檢查。
資料來源
- Google web.dev：An API for fast, beautiful web fonts —— 中日韓字體字符數對比與 unicode-range 傳輸量削減數據
- Google Developers Blog：Streamline your web font requests — introducing "text=" —— 動態字體字符精簡參數說明