字体体积减少95%!OnlyOffice性能优化的这一招,太狠了

在私有化部署 OnlyOffice 的过程中，“文档打开慢”几乎是所有团队都会遇到的问题。而在中文场景下，这个问题往往更加严重——动辄几秒甚至十几秒的首屏时间，严重影响用户体验。

深入分析后你会发现：

瓶颈并不在文档解析，而在“字体加载与解析”。

本文将从 OnlyOffice 的真实架构出发，拆解字体加载机制，并给出一套从“短期缓解”到“工程级优化”的完整方案。

一、 OnlyOffice 字体机制揭秘（为什么它天生就慢）

1.1 OnlyOffice 的技术本质

很多人误以为 OnlyOffice 是“基于浏览器渲染的在线编辑器”，但实际上并非如此。

OnlyOffice 的核心架构是：

• Canvas 渲染（非 DOM）

• WASM 字体引擎（类似 FreeType）

• 自研排版引擎（Word/Excel 级别）

这意味着：

OnlyOffice 并不依赖浏览器字体系统，而是自己解析字体、自己排版、自己渲染

带来的直接后果是：

•  无法使用浏览器字体缓存

•  无法直接使用系统字体

• 必须加载完整字体文件

1.2 字体加载完整流程

当你打开一个文档时，OnlyOffice 实际做了这些事情：

Step 1：解析文档字体

• 提取 font-family（如：SimSun、Calibri）

• 构建字体依赖列表

Step 2：字体匹配与替换

• 在服务器字体目录中查找（/fonts）

• 若不存在 → fallback（如 Arial → Liberation Sans）

Step 3：字体加载

OnlyOffice 的字体已经提前经过格式转换，替换文件头等操作变为专有格式。在收集完依赖后，前端发起请求：

/fonts/000/fonts/001

Step 4：WASM 解析字体

加载后进入 WASM 引擎，解析：

• cmap（字符映射）

• glyf（字形轮廓）

• hmtx（字符宽度）

• kerning（字距）

Step 5：参与排版与渲染

• 计算每个字符位置

• 将 glyph 转为 Canvas path 绘制

1.3 缓存机制（很多人理解错了）

OnlyOffice 缓存的是“字体文件”，不是“解析后的字体”。也就是说：

• 第一次：下载字体 ✔，WASM 解析 ✔（耗时）

• 第二次：不下载（命中缓存）✔，但仍然需要重新解析字体，CPU 开销依然存在

特别是在 Android 环境，WebView 的磁盘缓存一般只有几十 MB ~ 100MB 左右，由系统动态管理（LRU 淘汰）。当你加载：

• 一个 10MB+ 的 CJK 字体

• 多个字体叠加

会发生：刚缓存进去 → 很快被淘汰。

1.4 性能瓶颈拆解

① 字体体积巨大（核心问题）

• 英文字体：~200KB

• 中文字体：5MB ~ 20MB

如果一个文档用 3 种中文字体：👉 可能下载 30MB+

② WASM 解析成本高

字体不是直接可用的：

• 需要解析 OpenType 表

• 解码 glyph

• 构建内部结构

首屏必然有 CPU 开销

③ 网络请求多且分散

• 每个字体一个请求

• 无打包机制

• HTTP/1.1 下更慢

④ 移动设备特别慢

原因主要不是设备性能，而是：

• 默认无持久缓存

• WebView 复用差

• 每次重新加载字体

二、 缓解策略：短期可见效果

这些方案不改变架构，但可以明显改善体验。

2.1 控制字体数量（最简单有效）

问题本质：

OnlyOffice 是“每种字体独立加载”

优化建议：

• 限制文档字体 ≤ 2 种

• 统一使用标准字体（如 Noto / 思源系列）

2.2 应用层字体预加载

可在编辑页面之前使用 preload 页面触发字体下载与缓存。

具体见：https://onlyoffice.moqisoft.com/docs/feature/speedup

作用：

• 提前建立连接

• 提前进入缓存

2.3 字体 CDN（公网场景）

如果使用 CDN 服务器，将字体部署到离用户近的节点。

具体见：https://onlyoffice.moqisoft.com/docs/feature/speedup

每次增加字体或升级版本后，字体文件会发生变化，需要及时更新 CDN 缓存。

适用于：

• SaaS 部署

• 多地区访问

优化点：

• HTTP/2 / HTTP/3

• 边缘节点缓存

2.4 字体裁剪（可行但要注意）

很多人想到“子集化”，但在 OnlyOffice 中：

❌ 动态子集化（编辑场景）不可行

因为：

• 用户随时输入新字符

• 无法预知字符集

✔ 可行方案：静态裁剪

使用工具（如 fonttools）：

• 删除 hinting

• 精简 GSUB / GPOS

• 保留核心表（cmap / glyf / hmtx）

👉 通常可减少：

30% ~ 70% 体积

三、 工程级优化：documentserver 中国版的落地方案

这一部分才是真正解决的关键。

3.1 排版与渲染分离

优化思路是：

用“裁剪后的字体做排版 + 本地字体做渲染”

但在 OnlyOffice 中默认不成立！

原因：

• 排版依赖字体宽度（hmtx）

• 渲染依赖 glyph（glyf）

• 光标定位、选区计算也依赖字体

👉 排版与渲染强耦合

3.2 字体裁剪双轨制 + 本地字体渲染

中国版的 documentserver 中，新增了“字体裁剪双轨制”，我们称之为 “本地字体”：

• 西文字体与图标字体默认不裁剪，走原来的解析、排版计算、渲染逻辑

• CJK（中日韩）字体裁剪后，仅保留排版计算需要的测量表，解析及排版计算依然走之前的逻辑，渲染时根据配置自动探测浏览器本地字体，自动回落到可用字体

这样既保证了排版计算的准确性（文字效果与艺术字与原版渲染效果基本无差异），又大幅减少了网络传输的字体体积。

这套方案同时对 PC 和 Mobile 模式生效，对于安卓设备无法缓存字体问题也会得到很大缓解。

目前已在 documentserver 中国版最新版本中落地，效果显著。

四、 实战效果

在一个空白 Word 文档场景中：

优化前：

• 中文字体下载：18MB（SimSun）

• 打开时间：8~12s

优化后：

• 中文字体下载：289KB（SimSun）

• 打开时间：2~4s，打开速度提升了 3~4 倍

如果文档中 CJK 字体存在多个，这个差异还会更明显。

按上述方案执行后，文档服务中国版 fonts 目录下所有字体，由优化前的 416MB 减少至优化后的 21MB，减少了 95%。

五、 总结

通过以上分析和优化方案，我们可以看到，文档服务中国版针对 OnlyOffice 字体加载慢的问题，通过字体裁剪和双轨制优化，可以显著提升文档打开速度和用户体验。具体总结如下：

1. 字体裁剪：使用静态裁剪工具删除不必要的字体数据，大幅减少字体体积（-95%），从源头缩短加载时间。

2. 双轨制渲染：将排版与渲染分离，排版时采用裁剪后的轻量字体保证快速计算，渲染时调用系统本地完整字体确保显示效果，并对不同类型字体采取差异化处理，兼顾排版准确性与视觉质量。

这套方案已经在 documentserver 中国版中成功落地，取得了显著的效果。未来，随着技术的发展和优化，相信可以进一步提升字体加载性能，为用户提供更加流畅的文档处理体验。

如果想体验本地字体的优化效果，欢迎访问：https://onlyoffice.moqisoft.com/docs/feature/fivestar-word

 相关资源

• OnlyOffice 最新版本 9.x 镜像：https://onlyoffice.moqisoft.com/docs/install/docker

• 版本介绍：https://onlyoffice.moqisoft.com/docs/product/summary

• OnlyOffice 中国版技术交流（QQ群：183026419）：https://qm.qq.com/q/uMwFyL5Wn0

如果你在 OnlyOffice 部署和优化中遇到其他问题，欢迎在评论区留言交流！