小迪博客PRO

文章 · 性能优化

把字体分包做成一条流水线

许原2026-10-1536112

手工切片只能应付一次性任务。真正上线之后，文案会改、字重会加、页面会新增，切片必须变成一条自动跑的流水线。

流水线的输入

输入是「完整字库」加「站点实际用到的字符集」。字符集不用手维护，从构建产物里扫一遍文本节点就能自动收集。

流水线的步骤

扫描产物，收集站点用到的全部码位
按 Unicode 区间切分，生成分片文件
为每片生成对应的 @font-face 声明
把字体文件发布到带长缓存的静态路径

增量是关键

每次全量重切既慢又会让缓存全部失效。把切分结果按内容哈希缓存，只有码位集合变化时才重跑受影响的分片，日常提交的耗时能压到秒级。

评论15

登录后参与评论，你的发言会署上自己的名字。

许原作者@xuyuan2026-10-15
先占个位：文里的数字都是本地实测的，测试环境写在文末备注里，有疑问直接在这儿回。
郑一鸣@yiming2026-10-16
想问下这种切片方案在字体版本升级的时候怎么处理？全部重下还是只换变化的分片？
吴桐@wutong2026-10-17
行高和字距那一段说得很实在，中文确实不能照搬西文那套参数。
顾青@guqing2026-10-18
懒加载和解码分开讲这点很关键，很多团队只做了前一半。
沈亦@shenyi2026-10-19
预留尺寸这一步收益比我想的大，页面重排少了以后体感差别很明显。
韩雪松@xuesong2026-10-20
有没有考虑过体积之外的因素？我们这边的瓶颈其实在解码那一步。
邓可@dengke2026-10-21
把流水线耗时先打出来这一步太重要了，不然优化全靠猜。
罗叙@luoxu2026-10-22
同意，先有数据再谈优化，不然改了半天不知道有没有用。