OnlyOffice 开档及字体加载慢——问题剖析与优化落地实战在私有化部署 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 的 disk cache：一般只有几十 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 页面触发字体下载与缓存。
具体见：onlyoffice.moqisoft.com/docs/featur…

作用：

提前建立连接
提前进入缓存

2.3 字体 CDN（公网场景）

如果使用 CDN 服务器，将字体部署到离用户近的节点。
具体见：onlyoffice.moqisoft.com/docs/featur…

每次增加字体或升级版本后，字体文件会发生变化，需要及时更新 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，打开速度提升了4倍

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

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

五、总结

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

字体裁剪：使用静态裁剪工具删除不必要的字体数据，大幅减少字体体积（-95%），从源头缩短加载时间。
双轨制渲染：将排版与渲染分离，排版时采用裁剪后的轻量字体保证快速计算，渲染时调用系统本地完整字体确保显示效果，并对不同类型字体采取差异化处理，兼顾排版准确性与视觉质量。

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

如果想体验本地字体的优化效果，欢迎访问：onlyoffice.moqisoft.com/docs/featur…

OnlyOffice 开档及字体加载慢——问题剖析与优化落地实战