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

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

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

感谢，很实用

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

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

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

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

@YuJianrong 👍👍👍


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

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

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

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