字体这块的活儿看着不起眼真做起来全是细节。最近在给一个老项目做性能优化翻网络请求记录的时候发现首页字体文件加载得极其缓慢.ttf 格式一个文件动辄两三兆打开 DevTools 的 Network 面板简直惨不忍睹。当时心里就一个想法这都什么年头了还有人直接把 TTF 丢到线上让浏览器去下载。后来花了一下午把手头常用的几套字体统一做了一次转换全部从 TTF 转成 WOFF2文件体积平均缩小了差不多 60%个别字体甚至压下去了 70% 多。这个优化效果比你在 CSS 里折腾各种font-display策略要来得直接得多。这篇就来聊聊我用 ttf2woff2 把 TTF 字体转换为 WOFF2 格式的完整实践包括工具原理、安装步骤、批量处理脚本以及我踩过的一些坑。1. 为什么现在做字体转换需要盯上 WOFF21.1 TTF 和 WOFF2 到底差在哪先别急着上手敲命令得把这两个格式的底细摸清楚。TTFTrueType Font是苹果和微软在上世纪八十年代末联合制定的字体轮廓标准后来微软又搞了个 OpenType 的扩展但大家日常称呼时经常把 .ttf 和 .otf 混着叫。TTF 的优势是兼容性极广从 Windows 到 macOS从手机到打印机几乎所有设备都能认但它的打包方式比较原始直接存储字体的轮廓数据、度量信息、字距表等内容几乎没有做压缩处理所以体积常年居高不下。WOFF2 则是 Web Open Font Format 的第二个大版本由 W3C 在 2016 年前后推动标准化。它在 WOFF1 的基础上引入了 Brotli 压缩算法这是一种比 zlib 压缩率高出不少的无损压缩方案。针对字体文件的特殊性WOFF2 还会对轮廓点坐标、复合字形引用、字距调整表做专门的变换和重编码不是简单地把整个文件用压缩算法包一遍而是从字体内部数据的组织方式上做优化。这就导致一个结果WOFF2 在同等视觉精度下体积通常只有 TTF 的 40% 到 60%甚至更夸张。我见过不少朋友有个误区以为 TT F转 WOFF2 就像 ZIP 压缩一样解压之后能完整还原。实际上这个过程不是纯粹的压缩而是有损的字体重组。WOFF2 会将 TTF 里冗余的表格丢弃重新排列字形数据再用 Brotli 做熵编码。虽然最终的渲染效果和原始字体几乎无损但放在二进制层面你很难通过简单解压把它还原成原来的 TTF。1.2 网页场景下体积账算明白了你就知道该转做 Web 开发的朋友应该深有体会字体是页面加载性能里特别容易被忽视的一环。一张图片你可以懒加载、可以压缩但文字内容语义不能丢字体文件你得老老实实让浏览器拿下来。如果你的站点用了自托管的中文字体一个 TTF 常常在 3MB 到 8MB 之间这相当于几十张高清图片的体积。把所有访问者的流量成本、弱网用户的首屏等待时间算在一起这笔账非常惊人。而且更关键的是现代浏览器的字体加载机制比较特殊。虽然 CSS 里写了font-face但在字体文件完全下载完毕之前浏览器不会用这个字体渲染任何文本。这在技术圈里叫 FOITFlash of Invisible Text也就是不可见文本闪烁。文件越大用户盯着白屏或空白占位符的时间就越长。WOFF2 因为体积小下载速度快能显著缩短这个不可见窗口。我做过一次粗略测试同一款思源黑体的英文字重TTF 原始大小 2.1MB转成 WOFF2 之后只剩 680KB缩水了接近 68%。这还是在没有做子集化的情况下。如果配合字体子集化工具把用不到的字符全部切掉一个只含数字和英文的 WOFF2 甚至能做到几十 KB。所以我的原则很简单只要目标浏览器支持一律用 WOFF2没有例外。2. ttf2woff2 是什么凭什么值得用2.1 这个工具的出身和定位ttf2woff2 是 Google 在开源字体工具链里孵化的一个命令行小工具本质上封装了 Google 自家的 woff2 库。它配套的还有 woff2_decompress、woff2_compress 等兄弟命令但 ttf2woff2 这个名字被大家叫顺口了网络上各种博客、教程里提到的也大多是它。它是一个底层的转换器不做加粗、斜体、子集化这些复杂的字体编辑操作只专注做一件事把 TTF 格式的字体文件转换成 WOFF2 格式。为什么我会专门推荐这个工具而不是建议你打开一个在线转换网站原因是方便、可靠、可控。在线转换工具虽然省事但你经常要上传字体文件到别人的服务器这里存在字体版权和隐私的双重风险。很多商业字体在授权协议里明确禁止将字体文件上传给第三方服务。而 ttf2woff2 是完全本地的你在终端里跑一条命令文件从哪儿来还留在哪儿整个过程不经过任何网络传输版权安全和数据安全都能自己掌控。另外从技术角度看Google 官方出品的实现对 WOFF2 规范的理解是最透彻的转出来的文件兼容性最好。我用几百款字体测试过包括一些结构很怪异的老式 TTFttf2woff2 的转换成功率相当高。相比之下某些在线工具为了追求速度压缩参数设置得很激进转出来的字体在个别浏览器里会异常。2.2 和其他转换方案的对比我知道有人会说用 FontForge、fontTools 这些重量级工具也能转格式。确实可以但属于用牛刀杀鸡。fontTools 是一个 Python 库功能非常强大可以做子集化、修表、改度量但它需要你写 Python 脚本对不熟悉编程的普通用户来说门槛太高。FontForge 则是一个 GUI 应用每次转换都要打开软件手动操作批次处理体验很差。还有一个大家常提的方案是Google Fonts提供的那套命令行 API但那个需要在网络环境里申请和下载对于本地字体文件的转换场景反而不够直接。我整理了一张简单的对比表方便你快速判断方案操作难度批量处理本地执行转换质量ttf2woff2低一条命令支持是高FontForge中GUI操作弱是高fontTools高写Python支持是高但配置复杂在线转换工具低网页上传弱否低到中这些方案里ttf2woff2 的最大优势就是极简。它不要求你掌握字体原理也不需要任何图形界面一条命令就完成转换。如果后续要做更复杂的字体处理比如对所有字符做子集化那可以再把 fontTools 捡起来两者并不冲突反而能互补。3. 实操从安装到出文件一条龙搞定3.1 环境准备与安装ttf2woff2 的安装非常友好对主流平台都有覆盖。我日常的主力环境是 macOS直接用 Homebrew 就能装brew install ttf2woff2如果是 Ubuntu 或者 Debian 系的 Linux 系统可以用 apt 安装sudo apt update sudo apt install ttf2woff2Windows 用户可能稍微费点事官方没有提供预编译的 exe但可以通过 WSLWindows Subsystem for Linux跑 Linux 环境再执行上面的 apt 命令。当然如果你已经在用 msys2 或者 cygwin那就更简单了包管理器一搜就能找到。另外还有一种最通用的安装方案是直接用 npm 全局安装社区维护的 wrapper 包npm install -g ttf2woff2这个包实际上是通过 node-gyp 在本地编译 WASM 版本好处是不依赖系统库跨平台体验统一而且可以在 Node.js 里直接引用作为函数调用。不过说实话如果你只是想在终端里转几个文件用 Homebrew 或 apt 的原生版本就够了性能和稳定性都更好。装完之后先验证一下环境是否正常跑一下帮助命令ttf2woff2 --version正常情况下会输出版本号比如v1.3.11。如果提示command not found多半是环境变量没配好或者你安装的版本路径没加到 PATH 里。macOS 上用 Homebrew 安装的路径一般在/opt/homebrew/bin检查一下是否有这个目录没有的话就是安装过程出了问题重新跑一遍安装命令即可。3.2 单文件转换命令与参数说明ttf2woff2 的用法非常直接基本没有多余的参数需要记忆。最基础的命令是这样ttf2woff2 input.ttf output.woff2输入文件是原始 TTF 路径输出文件是你想生成的 WOFF2 路径。注意这个工具不会自动帮你在原文件名后追加.woff2后缀输出路径完全由你指定。如果你省略输出部分有些版本会默认输出到标准输出流这在使用时有点反直觉建议还是老老实实把两个参数都写全。有的版本还支持通过-n或者--no-optimize之类的参数关闭优化步骤这个参数适合调试场景。因为我发现少数结构不太规范的 TTF 字体在对轮廓点做变换优化时反而可能出现异常比如某些字形渲染时出现多余的毛刺。虽然这个情况非常罕见但真遇到了加一个--no-optimize参数绕开优化流程能解决大部分兼容性问题。代价是转换出来的文件体积会比原来大一些但总比 TTF 小很多。我的习惯是在项目根目录建立一个fonts文件夹里面按原始字体和转换后字体分成两个子目录。转换时相对路径写起来更清爽mkdir -p fonts/woff2 ttf2woff2 fonts/src/MyFont-Regular.ttf fonts/woff2/MyFont-Regular.woff2这样整个项目的字体资源一目了然后续写 CSS 的时候也不会搞混。3.3 批量转换脚本实战平时碰到的需求很少是只转一两个文件一般都有一整批字体要处理。如果一个一个敲命令效率太低而且容易漏文件。所以必须写一个批量转换的脚本。macOS 和 Linux 环境下直接用一个 shell 脚本就能解决#!/bin/bash for ttf_file in fonts/src/*.ttf; do filename$(basename $ttf_file .ttf) ttf2woff2 $ttf_file fonts/woff2/${filename}.woff2 echo 已转换: ${filename}.ttf - ${filename}.woff2 done这个脚本的逻辑很直白遍历fonts/src下所有以.ttf结尾的文件用basename去掉扩展名再拼上woff2目录和.woff2后缀交给 ttf2woff2 处理。执行时先给脚本加上执行权限chmod x convert_fonts.sh ./convert_fonts.shWindows 环境如果想做类似的事用 PowerShell 也能轻松实现Get-ChildItem -Path fonts\src\*.ttf | ForEach-Object { $outName $_.BaseName .woff2 ttf2woff2 $_.FullName fonts\woff2\$outName }这里用到了 PowerShell 里比较有特色的管道处理方式Get-ChildItem负责枚举文件ForEach-Object对每个文件执行转换命令。整个过程写得很简洁逻辑和 shell 脚本殊途同归。批量脚本里我还会顺手加一个校验步骤。因为字体文件体积普遍不小万一某个文件转换失败脚本会继续往下跑你最后很难发现遗漏。加一段判断逻辑如果命令执行失败就直接退出并报错这样至少能把问题暴露出来#!/bin/bash set -e for ttf_file in fonts/src/*.ttf; do filename$(basename $ttf_file .ttf) echo 正在转换: ${filename} ttf2woff2 $ttf_file fonts/woff2/${filename}.woff2 done echo 全部完成set -e会让脚本在任意命令返回非零退出码时立即终止。这样哪个文件转换失败终端最后输出的那个文件名就是你排查的起点。4. 转出来的字体有问题常见坑与排查4.1 命令行报错记录与解决我在实际操作中遇到过几种典型的报错这里整理成速查表方便你对照解决报错信息原因解决办法Not a TTF file?输入文件实际不是标准 TTF 格式用file命令检查真实格式确认是否为 OpenType/TrueTypeError: unrecognized table字体内部包含异常的表结构大概率是字体被裁剪或非标准生成尝试用 FontForge 重新导出 TTFFailed to open output file输出目录不存在或没有写权限提前mkdir -p创建目标目录检查目录权限std::bad_alloc输入文件损坏或格式极其混乱重新下载字体源文件或换一份 TTF 测试第二种情况我在处理一套从论坛扒下来的老字体时遇到过一次console 里直接冒出一串unrecognized table。后来用python3 -m fontTools.ttLib看了一下字体里的表发现除了常规的cmap、glyf、head之外还多了一个奇怪的TSI0表这个表是某些字体编辑软件留下的痕迹。ttf2woff2 规范要求输出文件只保留必要表遇到这种意外表会直接报错。解决方式也不复杂用 FontForge 打开原字体另存为一份新的 TTF新文件会自动清理掉这些杂表。std::bad_alloc这个报错比较唬人看起来像内存爆炸实际上我遇到的那次是因为下载的字体文件在传输过程中损坏了文件大小和原版差了好几十字节。建议拿到陌生字体先跑一下校验或者直接对比下载源的 MD5。如果是微信、网盘这种渠道转发过来的文件损坏的概率比想象中高不少。4.2 转完的 WOFF2 在浏览器里不生效这是另一个高频问题。命令行明明提示转换成功文件也生成了但部署到网站之后页面上的字体完全没有变化或者说字体样式不对。大多数情况下问题不是出在 ttf2woff2而是出在你的 CSS 写法上。我见过最常见的错误是font-face里只写了一个 WOFF2 文件的引用但没有做回退处理。虽然现代浏览器对 WOFF2 的支持已经很普遍但仍然有少量老版本浏览器不认识这个格式。更稳妥的做法是同时提供 WOFF 甚至 TTF 作为回退让浏览器自己选择合适的格式下载font-face { font-family: MyFont; src: url(/fonts/woff2/MyFont-Regular.woff2) format(woff2), url(/fonts/woff/MyFont-Regular.woff) format(woff), url(/fonts/src/MyFont-Regular.ttf) format(truetype); font-weight: 400; font-style: normal; font-display: swap; }浏览器选择字体文件的机制是从列表的第一个开始逐个检查是否支持该格式如果支持就下载不支持就跳到下一项。这个回退链写清楚版本兼容性问题基本都能兜住。另外要注意 Nginx 服务器的 MIME 类型配置。如果服务器没有正确返回font/woff2这个 Content-Type部分浏览器会拒绝加载字体。检查一下 Nginx 配置里是否包含types { font/woff2 woff2; }Debian/Ubuntu 系统的 Nginx 默认配置其实已经包含了这个类型但如果你用的是精简镜像或者手动编译的版本很容易漏掉。可以用curl -I看一下响应头确认Content-Type到底返回的是什么。还有一个小坑就是字体的跨域问题。如果字体文件放在 CDN 上而你的页面在另一个域名浏览器默认会拦截跨域字体请求。解决方法是让 CDN 在返回字体文件时带上Access-Control-Allow-Origin头location ~* \.(woff2?)$ { add_header Access-Control-Allow-Origin *; }这个配置我建议直接加上它不会带来明显副作用但能省掉一长串调试跨域的烦恼。5. 进阶玩法把转换嵌入自动化流程5.1 在 Node.js 脚本里调用如果你的项目本身就是 Node.js 技术栈完全可以把字体转换直接集成到构建流程里实现一键打包。这时候上面的 npm 包装包就派上用场了。先用 npm 安装依赖npm install ttf2woff2 --save-dev然后写一个简单的转换脚本const fs require(fs); const path require(path); const ttf2woff2 require(ttf2woff2); const srcDir path.join(__dirname, fonts, src); const outDir path.join(__dirname, fonts, woff2); fs.readdirSync(srcDir).forEach((file) { if (!file.endsWith(.ttf)) return; const srcPath path.join(srcDir, file); const outPath path.join(outDir, file.replace(.ttf, .woff2)); const ttfBuffer fs.readFileSync(srcPath); fs.writeFileSync(outPath, ttf2woff2(ttfBuffer)); console.log(转换完成: ${file}); });这段代码本身不长但里面有几个隐藏的细节值得说。ttf2woff2传入的参数不是一个文件名而是一个 Buffer 对象所以必须先fs.readFileSync把文件内容读进来。输出同样是一个 Buffer直接写进目标文件即可。注意这里没有做异步处理如果你的字体数量特别多同步阻塞可能会拖慢打包流程建议用Promise.all配合异步 API 优化一下。写完之后在 package.json 里加一个快捷脚本{ scripts: { build:fonts: node scripts/convertFonts.js } }以后要转换字体一行命令搞定不用记任何 ttf2woff2 的参数。5.2 配合构建工具使用的一些思路在实际项目中我还会把字体转换和子集化、构建工具串在一起。举个例子一个多语言站点通常需要十几套字体覆盖不同语言字符集。如果全部打成完整 WOFF2加起来体积依然不小。更合理的做法是先用 Python 的 fonttools 脚本对 TTF 做子集化只保留站点需要的 Unicode 区间然后再用 ttf2woff2 压缩成 WOFF2。比如下面这个思路先提取常用字符比如 Basic Latin、Latin-1 Supplement、CJK Unified Ideographs 的一部分然后用 fonttools 的subset命令生成一个瘦身后的 TTFpyftsubset fonts/src/NotoSansSC-Regular.ttf \ --unicodesU0000-00FF, U2000-206F, U3000-303F, U4E00-9FFF \ --output-filefonts/subset/NotoSansSC-subset.ttf然后再把这个子集化后的 TTF 交给 ttf2woff2 压缩。经过两步处理的字体文件体积完全可能控制在原版的 5% 以内加载速度直接起飞。配合构建工具的话Webpack 可以通过copy-webpack-plugin把转换后的字体拷贝到输出目录Gulp 则有现成的插件可以串联这些任务。核心思路都差不多把 ttf2woff2 当成一个独立的处理函数在构建的某个环节调用它计算出最终产物。这种自动化的价值在你后期更新字体文件时体现得特别明显源文件换一版npm run 一下所有格式和目录就全部重新生成不会出现漏转换、路径写错这类低级问题。我个人在实际操作中还有一个习惯就是在每次批量转换之后用ls -lh对比一下原始文件和压缩后的体积记录在项目的 README 里。这样后续任何一次字体更新一旦体积出现异常波动都能快速定位是字体源文件的问题还是转换参数被改过。别小看这个习惯它能帮你省掉不少排查时间。最后再分享一个小技巧万一手头没有现成的 ttf2woff2又急需确认某个字体在页面上渲染是否正常可以直接打开 Chrome 的 DevTools在 Network 面板里看字体文件的大小和加载耗时。如果响应体积已经很小了说明压缩效果已经到位如果发现某个字体文件还是好几 MB多半是格式没转换或者子集化没做趁早回头处理别等线上出问题再追悔。
