这问题其实挺接地气的，不少前端开发者都疑惑过——为啥PageSpeed天天催着加font-display，Google自家的字体服务反而慢半拍？结合我了解到的背景和后来的变化，给你拆解下：

• 历史兼容性的保守策略
  font-display是CSS Fonts Level 4才引入的属性，在它刚出来那几年，还有不少旧版本浏览器（比如老版IE、某些移动端浏览器）不支持这个特性。Google Fonts作为面向全球的公共服务，得优先保证最大范围的兼容性，要是贸然全量加上font-display，对于那些旧浏览器用户来说，可能反而出现字体加载异常的问题，这和他们“让所有网站轻松用上自定义字体”的目标相悖，所以一开始选择了观望。

• 自有加载机制的替代效果
  其实Google Fonts早有一套自己的异步加载逻辑，比如早年的Web Font Loader，后来又把类似的逻辑内置到了字体请求里。这套机制能实现和font-display: swap几乎一样的效果：先显示系统默认字体，等自定义字体加载完成后再无缝替换。在font-display普及之前，这套方案已经能满足性能和体验的平衡，所以团队可能觉得暂时不需要额外引入新属性。

• 产品迭代和最佳实践的时差
  PageSpeed Insights作为性能检测工具，会第一时间跟进Web性能的最新最佳实践，而Google Fonts作为成熟的产品，迭代需要走内部的评估、测试、部署流程——要考虑现有用户的影响、兼容性测试、文档更新等等，这中间自然会有时间差。就像很多大厂的不同产品之间，也不是完全同步推进的，得给产品团队留够调整的时间。

不过要补充一句：现在Google Fonts已经完全支持font-display属性了！你只需要在字体请求的URL里加上&display=参数就能指定，比如：

https://fonts.googleapis.com/css2?family=Roboto&display=swap

返回的CSS样式里就会自动包含font-display: swap，完美满足PageSpeed的要求。

内容的提问来源于stack exchange，提问作者Artem Evtihii