为什么现在网站不立即显示他们的文字？
lau*_*ent 446 browser performance display webkit
我注意到最近许多网站显示文本的速度很慢。通常，将加载背景、图像等，但不会加载文本。一段时间后，文本开始出现在各处（并非总是同时出现）。
它的工作原理与以前相反，首先显示文本，然后加载图像，然后加载其余部分。什么新技术造成了这个问题？任何的想法？
请注意，我的连接速度很慢，这可能会加剧问题。
请参阅下面的示例 - 一切都已加载，但在最终显示文本之前还需要几秒钟：
Dan*_*son 482
一个原因是现在的网页设计者喜欢使用网页字体（通常是WOFF格式），例如通过Google 网页字体。
以前，能够在站点上显示的唯一字体是用户在本地安装的字体。由于例如 Mac 和 Windows 用户不一定具有相同的字体，设计者总是本能地将规则定义为
font-family: Arial, Helvetica, sans-serif;
其中，如果在系统上找不到第一种字体，浏览器将查找第二种字体，最后是后备“sans-serif”字体。
现在，可以将字体 URL 作为 CSS 规则来让浏览器下载字体，如下所示：
@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);
然后通过例如加载特定元素的字体：
font-family: 'Droid Serif',sans-serif;
这很流行能够使用自定义字体，但也导致了浏览器加载资源之前不显示文本的问题，包括下载时间、字体加载时间和渲染时间。我希望这就是您正在体验的神器。
举个例子：我的一家全国性报纸Dagens Nyheter的标题使用网络字体，而不是他们的潜在客户，所以当加载该网站时，我通常首先看到潜在客户，半秒钟后，上面的所有空白区域都被填充带有头条新闻（至少在 Chrome 和 Opera 上是这样。没有尝试过其他的）。
（此外，如今设计师在任何地方都使用 JavaScript，所以也许有人试图对文本做一些聪明的事情，这就是它被延迟的原因。不过，这将是非常特定于站点的：文本在这些中被延迟的总体趋势我相信时间是上面描述的网络字体问题。）
添加
这个答案变得非常受欢迎，尽管我没有详细说明，或者可能是因为这个。问题线程中有很多评论，所以我会尝试扩大一点（很多评论似乎在主题受到保护后不久就消失了——一些版主可能手动清理了它们）。另外，请阅读此线程中的其他答案，因为它们都以自己的方式扩展。
这种现象显然通常被称为“无样式内容的闪烁”，特别是“无样式文本的闪烁”。搜索“FOUC”和“FOUT”可提供更多信息。
我可以推荐网页设计师 Paul Irish 在 FOUT 上关于网页字体的帖子。
可以注意到的是，不同的浏览器对此的处理方式不同。我在上面写道，我已经测试了 Opera 和 Chrome，它们的行为都相似。所有基于 WebKit 的（Chrome、Safari 等）都选择通过在 Web 字体加载期间不使用后备字体呈现 Web 字体文本来避免 FOUT 。即使缓存了网页字体，也会有渲染延迟。在这个问题线程中有很多评论另有说法，并且缓存字体的行为是完全错误的，但例如来自上面的链接：
在什么情况下你会得到 FOUT
- Will：下载并显示远程 ttf/otf/woff
- Will：显示缓存的 ttf/otf/woff
- Will:下载并显示一个 data-uri ttf/otf/woff
- Will：显示缓存的数据 uri ttf/otf/woff
- 不会：显示已在传统字体堆栈中安装并命名的字体
- 不会：显示使用 local() 位置安装和命名的字体
由于 Chrome 会在渲染前等待 FOUT 风险消失，因此会产生延迟。哪个程度的影响是可见的（尤其是当从缓存中加载）似乎是依赖于除其他事项外，需要呈现的文本量，也许还有其他因素，但缓存不完全去除的效果。
在帖子底部，爱尔兰语也有一些关于截至 2011-04-14 年浏览器行为的更新：
- Firefox（从 FFb11 和 FF4 Final 开始）不再有 FOUT！呜呼！http://bugzil.la/499292基本上文本是不可见的 3 秒，然后它带回了后备字体。webfont 可能会在这三秒钟内加载，不过……希望……
- IE9 支持 WOFF 和 TTF 和 OTF（尽管它需要一个嵌入位 设置的东西——如果你使用 WOFF，这主要是没有意义的）。然而！！！IE9 有一个 FOUT。:(
- Webkit 有一个补丁等待登陆以在 0.5 秒后显示回退文本。所以与FF相同的行为，但0.5s而不是3s。
- 另外：Blink 也为此注册了一个错误，但似乎尚未就如何处理它达成最终共识 - 目前与 WebKit 的实现相同。
如果这是一个针对设计师的问题，人们可以想方设法避免此类问题，例如webfontloader，但那将是另一个问题。Paul Irish 链接更详细地讨论了这个问题。
- 是否有任何浏览器尝试先以可用字体呈现文本，然后在下载首选字体后重新呈现？ (7认同)
- 有些人更愿意进入浏览网页的阅读部分，而不是等待很长时间来加载字体 (6认同)
- @ratchetfreak 重新格式化页面会令人不安，因为字体可能没有相同的指标 (5认同)
- 哦，呃，评论下一个答案：http://paulirish.com/2009/fighting-the-font-face-fout/ (4认同)
Kev*_*edy 19
网站“显示文本缓慢”有多种原因。在缓慢portableapps.com通过下载造成的WOFF字体。但是，您所描述的“文本开始在这里和那里出现”更常见的是由AJAX引起的。
一个网站由许多部分组成。如何下载和组装这些部件是网页设计师控制下的设计选择。缓慢是由开发人员选择组装以下构建块的方式引起的：
- 初始 HTML 页面
- CSS
- JS
- 图片
- WOFF 字体
- AJAX 请求
- DOM 操作
传统网站：
传统上，开发人员通常将文本内容放在初始 HTML 页面中，并在可用时立即显示。HTML 将引用几个随后将被下载的资源。然后，浏览器将逐步重绘屏幕以包含可用的样式和图像。AJAX 和 WOFF 不可用。
WOFF 网站：
WOFF 字体允许网站使用浏览器通常无法使用的字体，方法是通过网站下载字体。一些开发人员指示浏览器在下载所有 WOFF 字体之前不要显示文本内容。根据我的经验，这种方法还没有得到非常广泛的使用。
AJAX 网站：
一些开发人员选择在初始 HTML 页面中不包含文本内容。相反，他们选择使用 AJAX 下载文本内容。这发生在加载基本页面之后。根据我的经验，这种方法比 WOFF 字体获得了更广泛的采用，并且通常是您描述的缓慢的原因。
确定原因
要确定特定站点的原因，需要使用Firebug或Chrome 开发人员工具等工具进行分析。或者，您可以使用支持 AJAX 但不支持 WOFF 的Internet Explorer 8打开站点。如果站点仍然很慢，则问题是 AJAX 而不是 WOFF。
小智 14
我经常可能是故意选择避免“无样式内容的闪光”。如果在加载 CSS 之前显示文本，您会看到它看起来是原始的，然后在浏览器重新绘制它时会闪烁。通过放入一些基本的内联样式来最初隐藏在实际样式表中被覆盖的内容，或者使用 JS，开发人员可以避免这种闪光。
- 十有八九不是故意的，这只是以最简单的方式嵌入网络字体的副作用。事实上，当网络字体进入管道时，需要一些额外的努力来呈现一个可见的替代品。请参阅 https://developers.google.com/webfonts/docs/webfont_loader (6认同)
小智 8
正如其他人所指出的，自定义字体可能会导致延迟。
为了提供更多背景信息，浏览器在将页面内容呈现到屏幕之前大致执行以下操作：
- 获取 HTML（DNS、TCP、请求/响应的多次往返）
- 开始解析 HTML，发现外部资源，如外部 CSS 和 JS。请注意，CSS 块布局，而 JS 块解析。因此，在文档早期（例如在头部）加载的 CSS 和 JS 等外部资源会减慢页面在屏幕上显示内容所需的时间。
- 获取外部 CSS 和 JS（多次往返：DNS 和 TCP，如果这些资源位于不同的域，例如 CDN，以及请求/响应的 RTT）
- 一旦外部 CSS 和 JS 加载完成，解析/执行 JS，解析/应用样式
- 如果 CSS 引用自定义字体，那么现在也必须下载这些字体，从而导致额外的往返延迟来呈现依赖于自定义字体的页面的任何部分
虽然这不是专门针对自定义字体造成的延迟，但我最近写了一篇博客文章，提供了有关渲染延迟原因的更多信息。它提供了一些建议，以最大限度地减少首次为您的页面绘制的时间。希望这对有兴趣使页面显示内容更快的读者有用，包括那些想要使用自定义字体的页面：http : //calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -一秒/