Twitter开始使用WOFF webfont（screenshot）。此字体是base64编码的，并且在<link>内<head>的CSS文件中内联。
现在，如果我理解正确，<link>编辑的CSS样式表是渲染阻止的，即浏览器在获取/解析其外部CSS文件之前不会渲染页面。
在这种情况下，访问Twitter时，浏览器应加载包含webfont的CSS文件，然后使用该webfont 呈现页面。但是，我在Chrome / Windows中执行了测试（在空缓存/浏览器历史记录中），并且webfont显示且有延迟：页面上的文本首先使用默认值呈现操作系统的sans-serif字体，然后，几秒钟之后，webfont＆＃34;开始＆＃34;并替换系统字体。
见这里： https://www.youtube.com/watch?v=yt9UXHmNofA（转换发生在6秒标记处）
为什么会这样？为什么Chrome在第一次渲染时不显示webfont？可能是base64解码是异步发生的吗？
答案 0 :(得分：9)
（将这些放在一起作为答案，以便人们不必阅读无休止的评论）
出乎意料的是，这与浏览器无关，而是关于Twitter如何包含样式表。
基本上，名为“goth”的cookie确定是以阻塞还是非阻塞方式注入字体样式表。
在Twitter页面的第一次加载（没有cookie）中，字体样式表被异步注入（即以非阻塞方式）和cookie named "goth" is set¹。
在后续发送goth Cookie的请求中，字体样式表以阻止方式提供，格式为<link rel="stylesheet">中的<head>。
要自己查看，请按照以下简单说明操作：
在Chrome中，打开view-source:https://twitter.com/simevidas
打开DevTools（F12） - ＆gt; “资源”标签 - ＆gt; Cookies - ＆gt; twitter.com，删除goth cookie。
点击重新加载（F5）。由于您的请求标头未包含goth Cookie，因此文档的gotham-narrow-v3.css中不存在字体样式表（head），而是隐藏的HTML编码的JSON字符串（ pic）。它将在稍后通过JavaScript异步注入。
再次在DevTools Resources标签中检查您的Cookie - 只需重新加载视图源页面即可为我再次设置goth Cookie，但如果您没有{{} 1}} cookie只是打开一个Twitter页面。
现在设置了goth cookie，再次重新加载视图源页面。您会注意到字体样式表（goth）现在通过文档头部gotham-narrow-v3.css内的<link rel="stylesheet">包含在内。这个在第一次渲染之前加载，因为<link> CSS样式表是渲染阻止的。
当然，硬刷新（Ctrl / Cmd + F5）仍会发送cookie并以阻止方式加载字体样式表。
¹：最初，我认为这应该是某种带有功能检测的延迟加载，但我在Firefox 3.5（不支持WOFF webfonts）和Firefox 3.0.13上测试了它（它根本不支持webfonts）并且两者都设置了goth cookie。
由于cookie实际上是一个会话cookie（一旦浏览器关闭就被丢弃），更可信的是第一次异步注入是为了加速第一次渲染，后续请求假设字体样式表是已经缓存并以阻止的方式插入它以防止flash-of -webfont'ed-content（我刚刚编写的pic更具体的形式）。
我还没有通过缩小的JS来确保这一点，但如果你愿意，可以随意编辑这个答案或评论。
是的，这是一个高度本地化的话题，可能无法帮助很多人，我只是决定将它们全部放在一个清晰简洁的答案中，以便那些对这个主题感兴趣的人不必冒险进入问题中的无休止的评论。
