Embedded Google Fonts: 以 Base64 嵌入字体到 CSS 中

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

爱意满满的作品展示区。

这是一个创建于 3013 天前的主题，其中的信息可能已经有所发展或是发生改变。

一是国内的 google fonts 被墙，二是 font file 加载延迟造成的字体全白问题还是挺严重的，即便在改善了的 Safari 上也有三秒钟空白。

内联字体会是解决这两个问题的最佳方案，所以做了这个： https://amio.github.io/embedded-google-fonts/

cpvu6utuiaedfpe

第 1 条附言 · 2016-08-16 23:56:26 +08:00

文中提到的 Safari 今年六月份的一片博文，介绍了对 webfont 加载的改进：
https://webkit.org/blog/6643/improved-font-loading/

不过这个改进方案依然只能算是“改善”，用户仍可能体验到“ 3 秒白屏-->系统默认字体-->webfont ”这三个渲染效果的交替出现——可用性比原先的持续空白字体好了一点，体验远远不够。

把字体内嵌进 CSS 可以彻底解决此问题。

Fonts

字体

Google

联字

6 条回复 • 2016-08-16 23:51:22 +08:00

ivmm

2016-08-16 23:01:07 +08:00

Base64 、 svg 这类矢量的。
我一直有个疑惑。

如果这些东西应用一多，网站的打开速度应该会变长吧。如果低性能机器打开说不定会卡？是不是这样

huangtao728

2016-08-16 23:01:52 +08:00 via Android

感谢，很实用

DoraJDJ

2016-08-16 23:03:26 +08:00

@ivmm 我个人感觉 Base64 编码过后的图片、资源 etc 会让整个源码的可读性变差
因为 Base64 实在是太长了，可能会拖慢低端机子的性能？

ivmm

2016-08-16 23:04:49 +08:00

@DoraJDJ 图片直接下载打开。矢量的得浏览器自己渲染出来

YuJianrong

2016-08-16 23:32:51 +08:00

base64 编码的资源加载确实要比直接加载资源要慢，这有人做过 benchmark 的。不过就这点速度差异在 base64 资源使用不是很多的情况下也不严重。应该远远不及拖慢性能的程度。

对于字体内联 base64 其实还是个挺不错的解决方案的。字体的加载和 css 不同，不会阻塞渲染。 html 引入了 CSS 的话，在 CSS 加载结束之前页面不会 render （要不用户就会看到错误的页面，也加重 render 器重新 render 的负担），但 css 里面的字体就不会阻塞渲染，然后用户就会观察到，页面显示一种字体渲染，然后过了一会又变成另一种字体，我觉得这样反而体验很糟。内联 base64 之后，相当于 font 的加载是阻塞的，用户一看到界面就是正确渲染的界面了。

amio

2016-08-16 23:51:22 +08:00

@YuJianrong 👍👍👍

@ivmm @DoraJDJ 这个工具主要是针对已经确定要使用 webfont 的情况， Google Fonts 提供的 css 加载进页面之后，浏览器解析了这个 CSS 才开始去下载相应的字体文件，在这些字体下载完成之前，页面里设定用这个字体的文字部分就会显示一片空白。

[最近的 Safari 更新对此做了些改善]( https://webkit.org/blog/6643/improved-font-loading/)，最多显示 3 秒的空白，如果 webfont 还没下载完成会先用本地字体渲染，等 webfont 下载完成之后再换成 webfont 。虽然可用性上改善了一些，但页面效果多次变化，依然是个问题。

而对于国内的情况还多了一条，为了解决被墙问题我们通常要换国内的 google fonts 镜像，国内的这些能保证访问，但速度就难说，国外用户访问的情况更不靠谱，也会加重这个问题。

把字体内嵌到 css 中，就是对这个问题的解决办法。