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