WEB网页之@font-face与机能

FOUT：Flash of Unstyled Text

Paul 将Flash of Unstyled Text指为FOUT。这也是对付 David Hyatt 提出的FOUC（ flash of unstyled content ）的一种担任。FOUC会在样式表加载于页面底部的环境下产生。

Paul 指出了两种范例的FOUT:

重渲染的笔墨 —— 当 @font-face 文件仍在下载时，Firefox将行使默认字体渲染笔墨 。一旦字体文件下载乐成，firefox会将笔墨从头渲染为正确的字体。
不行见的笔墨 —— 其他大部门赏识器并不会渲染笔墨，直到字体文件被下载。
我乃至发明白一种更糟糕的 FOUT 的题目：

假如在 @font-face 声明之前有script标签的话， IE将不会渲染任何对象，直到字体文件完成下载。
你可以通过我的 FOUT 尝试 来调查，尝试中的字体文件会淹灭6秒的时刻下载。IE下整个页面都是空缺的，直到6秒后，纵然HTML喝其他页面元素都已经在赏识器里了。

全部的这些FOUT环境对用户体验都是很糟糕的。它会造成用户赏识页面时的间断，或是信息溘然改变。同时这也不可是 @font-face 笔墨的题目，假如默认字体和 @font-face 指向的字体巨细差异， 全部的除IE以外的赏识器将会对页面其他部门重渲染。

FOUT并不会对页面的绝对加载时刻造成影响，但它却会影响用户对付页面加载速率的印象，而这一点正是我们真正但愿优化的。

阻滞其他下载

对付字体文件的下载是否会阻滞其他文件下载的题目，我们的谜底很简朴——不会。我行使了这样一个阻滞尝试来判定字体文件是否会对其他资源的下载造成影响。测试页面包括了一些行使@font-face的笔墨。笔墨后头是一张图片，一个iframe，一张样式表，尚有一个外联剧本。全部的文件都被配置为2秒的下载时刻。在全部主流赏识器中，页面会在两秒内加载，表白并没有文件被阻滞。

留意字体文件也会受到统一域名下载限定的影响。试一试同域测试 就可以发明这一限定。在阻滞试验中我将资源分手到差异的域名下从而防备任何的链接限定。可是假如字体文件与其他资源位于统一域名下，阻滞将会因为同域下载限定而产生。

为了让差异域的字体文件可以或许正常事变于firefox下，你必需增进 Access-Control-Allow-Origin 的http头。到跨域测试中查察这一征象。

赏识器忙的标识

尽量字体文件不会阻滞其他文件的下载，它们如故会影响到赏识器忙的标识。这会给用户一种页面必要很长时刻加载的不良印象。赏识器忙的标识对付各个赏识器都差异，拜见下表：

同时要留意的是，在IE和firefox中，字体下载将阻滞window.onload变乱，而Safari 和 Chrome将不会。 这个可以从第一个尝试中看出。

下载挥霍

Paul指出，Garrick曾经发明IE在下载字体的时辰会有一小点不正常。IE在发明字体文件的声明的时辰就开始下载。这意味着纵然没有任何元素行使了该字体，IE也会下载这个字体文件。

同样你可以从我的 未行使字体测试 来验证。该页面拥有一处 @font-face的声明，不外页面中并没有行使。同时，该文件被节制必要6秒时刻下载。显然，整个页面在IE中耗费了6秒的加载时刻，证实了纵然没有行使字体文件IE也会下载的究竟。大概IE但愿这一点可以或许办理FOUT的题目，可是相同于这样的题目将导致许多的资源挥霍，而且低落页面的机能。

压缩

Stoyan的文章指出字体文件必必要gzip。Paul开始以为这不行能，我也有相同概念。谢天谢地Stoyan指正，究竟上，你必需压缩字体文件。他的研究显式这对付TTF,OTF和EOT文件将节省40%的体积。我此刻将我的apache设置为压缩字体文件了。

缓存

与其他资源一样，字体文件可以被缓存。你可以在缓存测试中看到这一点。字体文件会在6秒后下载，以是当第一次你会见这个页面，加载将高出6秒。可是字体文件拥有了一个很长的逾期时刻，以是再次点击上面的链接，你会发明因为字体文件是从缓存中读取的，加载速率会快许多。

@font-face的毗连题目

因为字体文件激发了FOUT和赏识器忙碌的题目，我们必需思量最坏的环境： 假如字体文件的处事器产生了某些不测好比哀求超时可能耗费了很长的时刻相应，会产生什么呢？ 毗连测试 揭示了这一征象，并且功效不乐观。字体文件被设置为20秒后下载，下面是测试的功效：

IE: 因为第一个尝试反应出的题目，在字体文件下载完成前整个页面都是空缺的。纵然@font-face在整个页面的最下部城市产生。于是，在这个测试中页面在20秒内一向都是全白。
在Firefox中，字领会由默认字体渲染，然后20秒后，变为我们指定的字体。
在其他赏识器中，字体在20秒内不行见，但页面其他部门已被渲染。
由Annie的提醒，我试着探求赏识器耗费在下载字体文件上的最大时刻。我测试出的最长时刻是10分钟。Safari 做的最好：60秒后它放弃了下载，选用默认字体渲染。IE呈现了最坏的环境，10分钟的下载时刻内，IE一向都揭示的一张白页面。Firefox会当纵然用默认字体渲染笔墨，可是赏识器忙的标识会一向一连10分钟。Chrome没有渲染笔墨，同时它的忙碌状态也一连了10分钟。

这些相应慢的题目使得思量行使@font-face的开拓者要思量更多。它与图片的加载超时差异，当时辰赏识器将以显式一个坏链图标来竣事。假如一个字体文件不能下载，页面加载会在IE下阻滞，笔墨在Chrome下将不会显式，同时赏识器忙的标识将一向呈此刻IE,Firefox和Chome下（至少10分钟）。

（留意赏识器对付字体文件超时的举动和图片相同。）

@font-face 机能的提议

我起首的提议是除非它对付页面长短常重要的，不然不要行使@font-face。

最首要的缘故起因是因为假如@font-face声明之前有script标签的话，字体文件的下载将阻滞整个页面的加载。样式表同样也有这样的阻滞题目。可是样式表是对付整张页面提供样式的，而字体文件仅仅插手了一个自界说的字体。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!