盘点字体性能优化方案

原创 于 2025-07-09 17:59:08 发布 · 682 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#性能优化 #前端 #OpenTiny #ui

本文由张庭岑原创。

一, WOFF2 字体文件格式优化

W3C 标准: WOFF File Format 2.0

方案简介

WOFF2 (Web Open Font Format 2) 字体文件格式已经是 W3C 标准, 无需考虑兼容性问题.
WOFF2 通过优化编码格式和更先进的压缩算法使字体文件压缩率提升(WOFF2 相比TTF/OTF压缩率提升40%-60%，相比 WOFF1 压缩率提升 30%), 同时具备更快的客户端解析速度.

下面是主流字体文件格式对比

以下是常见 Web 字体格式的对比表格，综合了技术特性、兼容性及适用场景：

格式全称浏览器兼容性压缩率核心优势主要缺点
TTFTrueType Font全平台支持（Windows、macOS、Linux、移动端）低通用性强，支持 Unicode 和高级排版（连字、字距调整）文件体积大, 移动端加载慢
OTFOpenType Font全平台支持低支持 PostScript 轮廓，适合专业排版（如印刷设计）文件体积大, 移动端加载慢
WOFFWeb Open Font Format主流浏览器（Chrome、Firefox、Edge、Safari）高（比 TTF/OTF 小 40%）专为 Web 设计，支持压缩和元数据（如许可证信息）压缩率低于 WOFF2, 不支持旧版浏览器
WOFF2Web Open Font Format 2.0现代浏览器（Chrome 40+、Firefox 36+、Edge、Safari 12.1+）极高（比 WOFF 小 30%）Brotli 压缩算法，体积最小；支持高级特性（如可变字体）不支持旧版浏览器

场景分析

在本地能控制字体文件格式的情况下, 都应该使用 WOFF2; 在使用字体平台的情况下, 基本都支持 WOFF2;

字体格式转换工具: 如附录;

二, CSS unicode-range 字体子集化

unicode-range 已经是 W3C 的 CSS 标准, 无需考虑兼容性问题. 不需要服务端支持;

W3C 标准: CSS Fonts Module Level 4

MDN 文档: unicode-range

方案简介

在 CSS 中, @font-face 规定只有在 unicode-range 属性范围内的文字使用该字体;

DOM 文字渲染过程命中了 unicode-range 范围, 才会下载该字体子集;

因此可以将一个字体拆分成多个字体子集, 根据每个字体子集的 unicode-range 设置多个 @font-face

应用实例

鸿蒙开发者官网 的鸿蒙字体使用了 unicode-range 字体子集化方案, 将同一字体拆分成 96 个子集, 不同字重也拆分成不同子集, 完整字体 WOFF2 体积为 8.1M, 首屏字体子集请求 44 个共计下载 1.1M 字体子集;

LESS 代码如下 (也可以自行调试鸿蒙开发者官网 )

@fontUrl: '@/assets/fonts/HarmonyOS/HarmonyOS_Sans';

@font-face {
  font-family: HarmonyOSHans-Regular;
  src: url("@{fontUrl}/HarmonyOS_Sans_SC_Light.1.woff2") format("woff2");
  font-weight: 300;
  font-style: normal;
  font-display: swap;
  unicode-range: U+ff03,U+ff04,U+ff07,U+ff0a,U+ff17-ff19,U+ff1c,U+ff1d,U+ff20-ff3a,U+ff3c,U+ff3e-ff5b,U+ff5d,U+ffe0-ffe4;
}
@font-face {
  font-family: HarmonyOSHans-Regular;
  src: url("@{fontUrl}/HarmonyOS_Sans_SC_Regular.1.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+ff03,U+ff04,U+ff07,U+ff0a,U+ff17-ff19,U+ff1c,U+ff1d,U+ff20-ff3a,U+ff3c,U+ff3e-ff5b,U+ff5d,U+ffe0-ffe4;
}
@font-face {
  font-family: HarmonyOSHans-Regular;
  src: url("@{fontUrl}/HarmonyOS_Sans_SC_Light.2.woff2") format("woff2");
  font-weight: 300;
  font-style: normal;
  font-display: swap;
  unicode-range: U+f92c,U+f979,U+fa11,U+fe30,U+fe31,U+fe33-fe44,U+fe49-fe52,U+fe54-fe57,U+fe59-fe66,U+fe68-fe6b;
}
@font-face {
  font-family: HarmonyOSHans-Regular;
  src: url("@{fontUrl}/HarmonyOS_Sans_SC_Regular.2.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+f92c,U+f979,U+fa11,U+fe30,U+fe31,U+fe33-fe44,U+fe49-fe52,U+fe54-fe57,U+fe59-fe66,U+fe68-fe6b;
}
...略...
@font-face {
  font-family: HarmonyOSHans-Regular;
  src: url("@{fontUrl}/HarmonyOS_Sans_SC_Light.96.woff2") format("woff2");
  font-weight: 300;
  font-style: normal;
  font-display: swap;
  unicode-range: U+df-e5,U+e7-ea,U+ec,U+ed,U+f1-f4,U+f6,U+f9,U+fa,U+fc,U+101,U+103,U+113,U+12b,U+148,U+14d,U+16b,U+1ce,U+1d0,U+300,U+301,U+1ebf,U+1ec7,U+3042,U+3044,U+3046,U+3048,U+304a-3055,U+3057,U+3059-305b,U+305d,U+305f-3061,U+3063-306b,U+306d-3073,U+3075,U+3076,U+3078,U+3079,U+307b,U+307e,U+307f,U+3081-308d,U+308f,U+3092,U+3093,U+30a1-30a4,U+30a6-30bb,U+30bd,U+30bf-30c1,U+30c3,U+30c4,U+30c6-30cb,U+30cd-30d7,U+30d9-30e1,U+30e3-30e7,U+30e9-30ed,U+30ef,U+30f3;
}
@font-face {
  font-family: HarmonyOSHans-Regular;
  src: url("@{fontUrl}/HarmonyOS_Sans_SC_Regular.96.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+df-e5,U+e7-ea,U+ec,U+ed,U+f1-f4,U+f6,U+f9,U+fa,U+fc,U+101,U+103,U+113,U+12b,U+148,U+14d,U+16b,U+1ce,U+1d0,U+300,U+301,U+1ebf,U+1ec7,U+3042,U+3044,U+3046,U+3048,U+304a-3055,U+3057,U+3059-305b,U+305d,U+305f-3061,U+3063-306b,U+306d-3073,U+3075,U+3076,U+3078,U+3079,U+307b,U+307e,U+307f,U+3081-308d,U+308f,U+3092,U+3093,U+30a1-30a4,U+30a6-30bb,U+30bd,U+30bf-30c1,U+30c3,U+30c4,U+30c6-30cb,U+30cd-30d7,U+30d9-30e1,U+30e3-30e7,U+30e9-30ed,U+30ef,U+30f3;
}

场景分析

  1. 通过良好的拆分字体子集, 可以减少首屏加载字体文件的体积; 大部分情况下, unicode-range 字体子集化方案都可以减少 40% 到 70% 的字体文件体积;
  2. 在多语言和中文场景, 对性能提升有显著效果;
  3. 同时不应该忽略的是字体子集化会增加网络请求的数量, 应该避免造成负向优化;

三, 增量字体传输方案 Incremental Font Transfer (IFT)

W3C 标准(草稿阶段): Incremental Font Transfer

方案简介

IFT 处于 W3C 标准的草案阶段, 将字体文件类比成 video, 将 unicode 类比成 video 的时间轴, 让浏览器自动下载所需要的字体子集;

从高层次来看，增量字体的使用方式如下：

  1. 客户端下载初始字体文件，其中包含来自字体完整版本的一些初始数据子集以及描述可用于扩展字体的补丁集的嵌入数据。
  2. 客户端会根据待渲染的内容选择、下载并应用补丁来扩展字体，使其涵盖更多字符、布局特性和/或变体空间。每次有新内容时，都会重复此步骤。

下面我用比较形象的两个图展示:
Video 播放根据时间切片进行增量传输, 最开始只需要下载时间轴和 video 的元数据即可, 包含时间轴和 video 切片的对应关系, 播放过程会自动下载 video 切片;

在这里插入图片描述

字体根据 unicode 进行增量传输, 最开始只需要下载 unicode 和字体子集的对应关系即可, DOM 渲染过程会自动请求增量字体

在这里插入图片描述

W3C 标准规定了增量字体的编码方式, 以便客户端代理或者服务端代理可以返回增量子集;

客户端将自动识别增量字体并请求增量子集, 前端开发人员未来就不用操心字体体积优化了;

目前该提案还在草案阶段, 完全自动的字体优化还未能实现; 因此后面的方案都是自行实现的增量字体传输方案;

四, Google Fonts 字体按需加载

Google Fonts, Typekit 等字体平台都提供 Web Font 服务, 目前发现 Google Fonts 不进提供字体全量下载, WOFF2 字体格式, 字体子集下载等服务, 还提供字体按需加载能力;

Google Fonts API:

在这里插入图片描述

向 API 传入 text 参数, 将只下载参数 text 内包含的字体子集

方案简介

在这里插入图片描述

  1. 前端动态进行网页内容识别, 输出网页需要渲染的文字: textContent
  2. 根据 textContent 生成字体子集的 @font-face 并插入文档流: @font-face 的 src 的 url 指向 https://google-font-api?text=textContent
  3. 浏览器 DOM 文档渲染命中 @font-face 规则, 向 google fonts 服务端请求下载字体子集
  4. Google Fonts 服务端返回仅包含 textContent 的字体子集, 浏览器重新渲染文字

按需加载字体子集的思路, 不一定要生成 @font-face CSS, 还可以使用 FontFace Api 直接下载字体子集, 例如:

// 代码片段来自古茗团队博客: [因网速太慢我把20M+的字体压缩到了几KB](https://juejin.cn/post/7490337281866317836)
const text = textContent;
// 构建字体对象
const font = new FontFace(
    fontName,
    `url(http://127.0.0.1:5000/font/${fontName}?text=${text}&format=woff2)`
);
// 加载字体
font.load();
// 添加到文档字体集中
document.fonts.add(font);

场景分析

  1. 在运营场景, 首屏存在多种字体, 并且只有特定元素如 banner, logo, slogan 等才使用的字体, 按需加载可以带来大幅度的性能提升和用户体验提升;
  2. 在服务端渲染页面使用字体按需加载将获得极致字体性能
  3. 在需要处理用户中文输入的情况下, 体验不佳 - 会发起大量单个文字的字体子集请求, 并且页面文字渲染可能发生跳变 (用户输入场景, unicode-range 方案浏览器会自动下载字体子集; 按需加载方案需要我们主动监听文档流变化)
  4. 不一定依赖服务端, 在活动页, 运营页等场景, 可以 !!提前!! !!按需!! 生成字体子集即可;

技术细节

  1. 识别网页渲染内容的算法: nathanford/google-fonts-dynamic-subsetter
  2. 动态监听网页内容变化的算法需要自行判断是否需要动态监听: MDN - MutationObserver
  3. 服务端按需生成字体子集的工具: 如附录

工具附录

工具连接说明
fontminhttps://ecomfe.github.io/fontmin/#bannerbaidu EFE 团队出品的字体子集化工具, 基于 nodejs 编写, 有客户端, cli, 还有 nodejs api 可以基于它做字体按需加载服务端
fonttoolshttps://github.com/fonttools/fonttools一个使用 python 操作字体文件的库, 可以将字体文件在各种编码之间快速转换, 也可以拆分字体子集
glyphhangerhttps://www.zachleat.com/web/glyphhanger/- 使用 puppeteer 爬取网页所有的文字, 输出 unicode-range 便于拆分字体子集; - 可以根据 unicode-range 将输入的字体文件拆分出字体子集 (这部分功能封装的是 fonttools)
font-spiderhttps://github.com/aui/font-spider功能同 glyphhanger, 同样使用 puppeteer 爬取网页内容生成 unicode-range, 并且可以将字体拆分出字体子集, 不同的是 font-spider 有 webpack/grunt/gulp 插件, 可以在本地构建阶段自动化地为 SPA 打包处最小量的字体子集, font-spider 内部封装的是 fontmin

glyphhanger 使用示例: 爬取网页, 按需输出字体子集

在这里插入图片描述

关于OpenTiny

欢迎加入 OpenTiny 开源社区。添加微信小助手：opentiny-official 一起参与交流前端技术～

OpenTiny 官网：https://opentiny.design
OpenTiny 代码仓库：https://github.com/opentiny
TinyVue 源码：https://github.com/opentiny/tiny-vue
TinyEngine 源码： https://github.com/opentiny/tiny-engine
欢迎进入代码仓库 Star🌟TinyEngine、TinyVue、TinyNG、TinyCLI、TinyEditor~

如果你也想要共建，可以进入代码仓库，找到 good first issue标签，一起参与开源贡献~

AI营销内容创作工具大盘点：AIGC领域TOP10推荐
AI天才研究院
05-12 600
数字营销领域正经历从“人力驱动”到“AI驱动”的范式转变。据emarketer数据，2023年全球企业在AI营销工具的投入同比增长42%，其中内容创作工具占比达37%。本文聚焦AIGC（AI-Generated Content）技术在营销内容生产中的应用，通过技术原理剖析、工具性能对比、实战案例演示，构建完整的工具选型与应用指南。覆盖文本、图像、视频、多模态内容生成四大场景，精选10款具有行业标杆意义的工具，解析其核心算法、技术架构与商业价值。核心概念：解析AIGC技术架构与生成式AI核心算法工具盘点。
数据湖在大数据场景下应用和实施方案调研笔记(增强版)
微信搜：import_bigdata，大数据领域硬核原创作者
08-24 1271
点击上方蓝色字体，选择“设为星标”回复”面试“获取更多惊喜在读本文前你应该看过这些：《我看好数据湖的未来，但不看好数据湖的现在》《数据湖解决方案关键一环，IceBerg会不会脱颖而出？》本...
Android性能优化——内存优化
ForgetSky的博客
05-12 2650
Android内存优化大盘点
Android内存优化大盘点
Peter的专栏
05-27 1607
内存优化是性能优化的重头戏，因此这部分也花了很多时间来梳理。老规矩，先上大纲：1基础知识1.1 Android内存管理框架:这里针对上图进行简单描述：1）物理地址与虚拟地址：虚拟内存是程...
2017 前端性能自查表
求索
12-26 3802
Smashing Magazine在年底做了一个有意义的事，把最新的Web性能优化实践做了盘点，这里提供其中大部分内容的翻译，供大家参考。有很多我自己也没有深入学习的点，翻译也不能保证准确，所以有时间还是看原文。
前端优化各个盘点
weixin_34107955的博客
12-06 126
围绕前端的性能多如牛毛，涉及到方方面面，以下我们将围绕PC浏览器和移动端浏览器的优化策略进行罗列。注意，是罗列不是展开，遇到不会不懂的点还请站外扩展。开车速度有点快，坐稳了。　　tips : 这么多前端优化点你都记得住吗？反正我是收藏起来备查的。PC浏览器前端优化策略PC端优化的策略很多，如 YSlow（YSlow 是 Yahoo 发布的一款 Firefox 插件，现 Chrome 也可安装，可以...
前端性能优化盘点
weixin_47369582的博客
09-28 121
聊到前端性能优化，首当其冲肯定得是白屏时间优化了，脚手架打包的js文件过大，当用户打开首页时，会一次性加载所有的资源，造成首页加载很慢，降低用户体验目标： 缩小打包体积，优化白屏时间 组件懒加载 一般只用在需要用户手动操作才调用的组件，如dialog、drawer等，我们期望用户操作后去触发组件的加载 重新打包后，home.js 和 about.js 中没有了弹框组件的代码，该组件被独立打包成 dialog.js，当用户点击按钮时，才会去加载 dialog.js 和 dialog.css 使用组件路由懒
[盘点]项目中可以怎么优化图片
weixin_34233679的博客
11-26 269
看似平常的事物，往往会蕴含的巨大的智慧。把看似平常的事物简单做好，可能很正常。如果能把平常的事物做精，做细，这个不平常。 1.前言 每一个开发者在开发项目中，不可避免要和图片打交道，优化图片似乎也成了一个必修课。图片优化也不仅仅是性能上的优化，还要进行体验上的优化。至于怎么优化图片，没有固定的方式，只能具体场景，具体分析，选择合适的方案。...
2020 年前端技术发展盘点
热门推荐
三钻 - 之前端到全栈之路
03-30 1万+
2020 年已经结束，这一年里面因为疫情，生活和工作中大家都有受到一定的影响。但是在 2020 年里面前端技术的发展依然没有停止脚步。 而我们作为前端开发者，必定需要对技术的更新换代有所了解。虽然我们不需要去学习所有新出来的技术。但是时刻保持 “了解” 和 “理解” 这些技术是有必要的。 了解这些新的技术和趋势，有效让我们成为更好的开发者，同时在我们日常工作中，这些知识有效帮助我们去解决工作中的技术问题，或者在一个问题中看到更多的解决办法和可能性。
Cocos Creator 性能优化：DrawCall
Cocos的博客
07-06 225
前言在游戏开发中，DrawCall 作为一个非常重要的性能指标，直接影响游戏的整体性能表现。无论是 Cocos Creator、Unity、Unreal 还是其他游戏引擎，只要说到游戏性能优化，DrawCall 都是绝对少不了的一项。本文将会介绍什么是 DrawCall，为什么要减少 DrawCall 以及在 Cocos Creator 项目中如何减少 DrawCall 来提升游戏性能。正文什么是...
2017移动开发年终盘点
xiangzhihong8的专栏
01-17 1292
2017年已经过了大半个月，2017年移动端经历了哪些大事件呢，现在总结如下。 Android 技术动态 在今年 Google I/O 大会上，谷歌 CEO Sundar Pichai 宣布谷歌的正在从“移动为首位”转变为“AI 高于一切”，所以与往年的开发者大会相比，今年会议的大部分内容都围绕 AI 展开，如 Google 将开放 Tensor Flow、TPU 等软硬件工具给开发者，还发布
资产清查盘点管理系统前端
03-30
安全性和性能优化措施 在实际部署前还需要注意安全性考量以及整体性能调优策略： - 对敏感接口实施身份验证机制防止未授权访问；同时加密传输重要参数保护隐私安全[^11]。 - 减少不必要的 DOM 操作次数从而加快...
【POS打印编程速度优化】：如何优化打印作业处理速度，提升打印效率！
文章强调了硬件性能和软件优化对提高打印速度的重要性，并建立了理论模型，探讨其在实际场景中的应用。在第三章，本文详细介绍了代码级别和系统级别的优化策略，包括硬件调整，并提供了详细的案例研究，展示了这些...
微前端架构在嵌入式BI中的集成实践与性能优化
zandy1011的博客
07-06 642
摘要：微前端架构为嵌入式BI提供了创新解决方案，有效解决传统集成模式存在的体验割裂、技术门槛高等痛点。通过DIV层级嵌入替代iframe，实现BI组件与业务界面无缝融合，使加载时间从2.8s降至0.9s，内存占用减少51%。关键技术包括沙箱隔离、预加载策略和API网关设计，支持3天完成深度集成。未来将向智能化、自适应渲染方向发展，推动嵌入式BI从功能集成迈向智能融合，成为企业数字化转型的核心竞争力。
前端开发常见问题（从布局到性能优化）
最新发布
BUG糕手的博客
07-06 717
本文总结了前端开发中的十大常见问题及解决方案，涵盖页面布局（盒模型、浮动、Flex布局）、CSS样式冲突、JavaScript异步处理（Promise、async/await）、跨域请求、性能优化（懒加载、防抖节流）、浏览器兼容性、移动端适配（REM布局）、SEO优化（语义化标签）、构建工具（Webpack/Vite）和安全性（XSS/CSRF防护）。每个问题都提供了具体代码示例和实用解决技巧，既适合初学者入门学习，也能帮助中级开发者深入理解。通过系统化的整理，为前端开发者提供了一份实用的开发避坑指南。
七、性能优化
chenzimin_blog
07-04 754
本文总结了Flutter应用性能优化的关键策略：1) 使用DevTools、Inspector等工具检测UI渲染、内存问题；2) 通过重绘边界隔离刷新区域；3) 避免组件重建，推荐const构造函数和状态拆分；4) 长列表优化采用ListView.builder和固定高度；5) 减少启动时间需简化初始化、预加载资源。优化后首帧渲染时间可从1200ms降至400ms，显著提升用户体验。核心在于合理控制重建范围、减少不必要的计算和资源加载。
分类树查询性能优化：从 2 秒到 0.1 秒的技术蜕变之路
m0_72945550的博客
07-03 851
《电商分类树查询的五次优化实践》摘要：本文记录了电商系统中分类树查询功能的持续优化过程。初始版本直接查询数据库导致2秒响应延迟，通过五次迭代优化：1)引入Redis缓存降低数据库压力；2)采用异步定期更新解决缓存雪崩；3)添加Caffeine内存缓存将QPS提升至500+；4)开启GZip压缩使数据传输量缩减90%；5)优化Redis存储结构解决大key问题。最终将响应时间从2秒降至0.1秒，QPS提升5倍，存储和传输效率显著提高，体现了性能优化需要结合
Java并发性能优化｜读写锁与互斥锁解析
07-04 1165
本文深入比较了 Java 中普通互斥锁与读写锁的核心机制、性能差异及适用场景，提供详细代码示例与 JMH 测试结果，帮助开发者根据读写比例合理选择锁类型，并讲解了锁降级、锁升级、饥饿问题及性能优化策略。
Java 与 MySQL 性能优化：MySQL全文检索查询优化实践
博客
07-04 1186
本文探讨了MySQL InnoDB全文索引在CMS系统中的应用与优化。首先介绍了InnoDB全文索引的基本原理、创建方法和三种查询模式（自然语言、布尔、查询扩展），并针对中文分词提出了ngram解析器解决方案。接着分析了CMS场景下全文检索的性能瓶颈，包括索引维护开销、查询性能、锁机制和大数据量问题。文章提供了四类优化方案：索引设计优化、查询语句优化、服务器参数调优和高级技术（如查询扩展、读写分离）。通过两个实际案例展示了优化效果，最后总结出CMS全文检索的核心原则和最佳实践，强调索引设计优先、查询优化、参
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值