【资料报告】W3C 发布《渐进式字体优化的评估报告》

W3C 中国区成员：
大家好！

W3C 发布《渐进式字体优化的评估报告》：
https://www.w3.org/TR/PFE-evaluation/

当下 WebFonts 的使用分布并不均衡。这份报告介绍了 WebFonts 
的相关术语，并分析了 WebFonts 
的现状和问题，以及哪些方案能够在网络速度慢、字体很大、或复杂的子集要求的情况下允许使用 
WebFonts。报告研究了两种渐进式字体优化的方法：补丁子集（Patch 
Subset）和范围请求（Range Request）。与将整个字体发送为 WOFF2 或使用现有的 
Unicode 范围的方法相比，这两种方法都显着减少了传输的字节数。

其中，补丁子集法要求升级服务器，而范围请求法则不需要。《2019年Web年鉴：字体》发现25％的 
WebFonts 
是自托管的，其余75％由CDN提供。这既表明需要升级的服务器数量很少，也表明我们需要一个简单、自托管的解决方案。
https://almanac.httparchive.org/en/2019/fonts

当使用 WebFonts 
显示内容时（特别是在较慢的网络上），主要的限制因素是延迟，而在发出的请求数较多时，这种效果会增强。报告将这种效果建模为成本函数。

对于大部分使用字母的文字系统（如拉丁字母、斯拉夫字母、希腊字母和泰语）：现有的Web字体传递方法可以很好地满足这些语言和文字系统的使用，如果子集导致了变形失败，受到的影响也很小。成本函数数据表明，在3G或更快速的网络上，补丁子集方法将缩短页面加载时间。范围请求方法将使桌面和移动WiFi网络上的页面加载时间恶化，并显著增加4G、3G和2G网络上的页面加载时间。因此，对于2G网络，最好将整个字体加载为WOFF2。

对于变形（shaping）要求较高的语言（如阿拉伯语和印地语）：如果子集引起了变形失败和其他渲染失败，受到的影响会很大。成本函数数据表明，补丁子集方法将改善4G或更快速网络上的页面加载时间，同时保留整个字体的渲染保真度，Unicode 
码位预测可以缩短这些语言的页面加载时间。而范围请求方法将使台式机或笔记本等较快的网络上的页面加载时间增加，并显着增加移动WiFi、4G、3G和2G网络上的页面加载时间。因此，对于3G和2G网络，最好将整个字体加载为WOFF2。

对于中日韩等包含汉字的字体：由于文件大小非常大，这些语言使用WebFonts的成本很高，所以需要一个大幅减少文件大小而又不会显着增加由多个网络请求引起的页面加载时间的方法。在4G和更快的网络上，补丁子集法让这些语言能够更好地使用WebFonts。在3G网络上，补丁子集方法可能仍可用于中日韩的 
WebFonts（但并非在所有情况下页面加载时间都会被缩短，有些情况下可能还会增加）。

注意：可以将实现补丁子集的服务器配置为根据网络条件自动表现为整个字体。这样可以确保在慢速网络上不会出现性能下降的问题。

如果不能扩展服务器，则对于4G和更快的网络，范围请求方法使中日韩 WebFonts 
成为昂贵但可用的资源。在2G网络上，范围请求方法节省的字节很有限，所以在2G网络上使用中日韩的预装字体仍然是唯一可行的解决方案。

报告将进行的下一步工作包括：

* 
加上模拟中跳过了的WOFF2压缩的第一阶段（表重新排列），因为这将提供更好的结果。
* 可以进一步完善Unicode码位预测，并进一步研究对网络类型的依赖性。
* 可以研究流字体预处理器中的更多函数。
* HTTP/2 POST请求绕过了Web缓存；应该研究与Web缓存一起使用的解决方案。
* 推动补丁子集，让中日韩字体的字节减少量减少90％以上，这将大大提高 WebFonts 
的使用率。
* 请求启用PFE的字体可能需要更改CSS标准，如src描述符上的新格式字符串。

本文执行的模拟完全是理论上的。在真实网络上的实际浏览器中进行的测试应使用范围请求法和补丁子集法的概念验证实现来执行。这将对这两种转移方法的性能进行更准确的评估，并验证此处报告的结果。

这项模拟研究的结果清楚地表明了进行渐进式字体优化的标准化工作对缔造真正全球通行的万维网的必要性。

如有任何疑问或需要更多信息，欢迎随时联系我们！

更多内容，欢迎关注W3C中国：
官网：http://www.chinaw3c.org/
微博@w3c中国：http://weibo.com/w3cchina
微信：W3C资讯

祝好！
贾雪远
-- 
Xueyuan Jia - W3C Marketing and Communications
mailto: xueyuan@w3.org; tel: 186 1297 0645

Received on Tuesday, 3 November 2020 04:13:05 UTC