为什么这些天网站不立即显示其文字？

我注意到，最近许多网站显示文字的速度都很慢。通常，背景，图像等将被加载，但是没有文本。一段时间后，文本开始出现在这里和那里（并非总是同时出现）。

基本上与以前相反，当首先显示文本时，然后显示图像，然后再加载其余图像。什么样的新技术正在造成这个问题？任何想法？

请注意，我的连接速度很慢，这可能会加剧问题。

参见下面的示例-一切已加载，但最终显示文本还需要几秒钟：

原因之一是当今的Web设计人员喜欢使用Web字体（通常为WOFF格式），例如通过Google Web字体。

以前，唯一可以在网站上显示的字体是用户在本地安装的字体。由于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”可获得更多信息。

我可以推荐Web设计师Paul Irish在FOUT上发布的有关Web字体的文章。

可以注意到的是，不同的浏览器对此的处理方式不同。我在上面写道，我已经测试了Opera和Chrome，两者的行为相似。所有基于WebKit的浏览器（Chrome，Safari等）都选择通过在Web字体加载期间不使用后备字体呈现Web字体文本来避免FOUT 。即使缓存了Web字体，也会存在渲染延迟。在这个问题线程中有很多评论都相反，并且缓存字体的行为完全是错误的，但这完全是错误的，但是例如来自上面的链接：

在什么情况下您会得到FOUT

• 威尔：下载并显示远程ttf / otf / woff
• 威尔：显示缓存的ttf / otf / woff
• 意志：下载并显示数据-uri ttf / otf / woff
• 威尔：显示缓存的数据-uri ttf / otf / woff
• 不会：显示传统字体堆栈中已经安装并命名的字体
• 不会：显示使用local（）位置安装和命名的字体

由于Chrome浏览器会等到FOUT风险消失后再进行渲染，因此会产生延迟。哪个程度的影响是可见的（尤其是从缓存中加载时）似乎是依赖于除其他事情要呈现的文本需要的量，也许还有其他因素，但缓存不完全去除的效果。

爱尔兰语在帖子底部也有一些有关浏览器行为的更新，截至2011年4月14日：

• Firefox（从FFb11和FF4 Final开始）不再具有FOUT！hoo！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）的链接在此问题上有进一步的详细说明。

原因是您仍无法阅读的文本是使用Web字体呈现的，该字体仍在通过管道传递到浏览器的途中。

另外，由于您的浏览器是使用WebKit渲染页面的Google Chrome浏览器，因此由他们（即WebKit）决定，最好是在下载Web字体之前完全不看任何文本。但是，如果您是开发人员，希望使用合适的后备系统字体来阅读文本，那么可以使用Google的WebFont Loader之类的工具来实现。

简短答案：AJAX或WOFF

网站“显示文本速度慢”有多种原因。在缓慢portableapps.com通过下载造成的WOFF字体。但是，您所说的“文本开始在这里和那里开始出现”的情况更多是由AJAX引起的。

网站由许多部分组成。在Web设计人员的控制下，如何下载和组装这些零件是一种设计选择。速度慢是由开发人员选择组装以下构件块引起的：

• 初始HTML页面
• 的CSS
• JS
• 图片
• WOFF字体
• AJAX请求
• DOM操作

传统上，网站：

传统上，开发人员通常将文本内容放在初始HTML页面中，并在可用时立即显示。HTML将引用几个资源，然后将其下载。然后，浏览器将逐步重画屏幕，以包括样式和图像（当它们可用时）。AJAX和WOFF不可用。

WOFF网站：

WOFF字体允许网站使用网站上下载的字体来使用浏览器通常不可用的字体。一些开发人员指示浏览器在下载所有WOFF字体之前不要显示文本内容。以我的经验，这种方法尚未得到广泛使用。

AJAX网站：

一些开发人员选择不在初始HTML页面中包含文本内容。相反，他们选择使用AJAX下载文本内容。这是在基本页面加载后发生的。以我的经验，这种方法比WOFF字体获得了更广泛的采用，并且通常是造成您描述缓慢的原因。

确定原因

要确定特定站点的原因，需要使用Firebug或Chrome Developer Tools之类的工具进行分析。或者，您可以使用Internet Explorer 8打开站点，该浏览器支持AJAX但不支持WOFF。如果站点仍然很慢，则问题是AJAX而不是WOFF。

我经常可能会选择避免“未样式化内容的闪烁”。如果在加载CSS之前显示的文本，您会短暂地看到它原始的样子，然后在浏览器重新绘制它时闪烁一下。通过放置一些基本的内联样式以最初隐藏实际样式表中覆盖的内容，或者使用JS，开发人员可以避免出现这种情况。

正如其他人指出的那样，自定义字体可能会导致延迟。

为了提供更多的背景信息，浏览器在将页面内容呈现到屏幕之前会大致执行以下操作：

1. 获取HTML（DNS，TCP，请求/响应的多次往返）
2. 开始解析HTML，发现外部资源，例如外部CSS和JS。请注意，CSS阻止布局，而JS阻止解析。因此，像CSS和JS这样的外部资源会在文档的早期（例如，在头部）加载，从而减慢了页面在屏幕上显示内容所花费的时间。
3. 获取外部CSS和JS（多次往返：DNS和TCP（如果这些资源位于CDN等不同的域）以及请求/响应的RTT）
4. 外部CSS和JS完成加载后，解析/执行JS，解析/应用样式
5. 如果CSS引用了自定义字体，则现在还必须下载这些字体，从而导致额外的往返延迟，以呈现依赖于自定义字体的页面任何部分

尽管这与自定义字体造成的延迟无关，但我最近写了一篇博客文章，提供了有关渲染延迟原因的更多信息。它提供了一些建议，以最大程度地减少首次绘画页面的时间。希望这对于希望使页面显示内容更快的读者有用，包括那些想要使用自定义字体的页面：http : //calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -一秒/

简短答案：开发人员。

将引用外部文档（例如.css或.js文件）的链接和脚本标签放在文档的开头（流中的内容比正文及其元素的位置高）时，将首先加载它们。JavaScript从引用它的标记执行；如果要处理的代码很多，或者代码很繁琐，或者更常见的是，如果您希望看到的文本是在服务器上呈现并在加载时填充到文档中的，那么服务器端代码也很繁琐，大型或由于处理多个并发请求而导致I / O阻塞，您肯定会在HTML有机会呈现之前就注意到停机时间。一些开发人员选择在标记和样式之后（在正文末尾）加载与视图无关的JavaScript，

互联网连接速度在缓慢下载数据中起着重要作用，但是显然，编写得不好的代码或设计不当的技术堆栈（针对网站的类型）在动态内容缓慢加载中起着越来越重要的作用，因为网络连接速度更快方法无处不在。

简而言之，在显示页面之前，需要从单独的HTTP GET加载太多可加载对象，并且过分依赖平均延迟来衡量站点运行状况。

第一个是指页面加载的所有那些.css，.js和webfonts，更不用说许多站点还需要通过XHR请求检索JSON对象，然后使用某种模板从那些对象中生成HTML。

但是，为什么他们不注意到该网站运行缓慢？

可能是因为他们在某处有memecache以加快处理速度（或仅依靠文件系统缓存），并使用平均延迟来衡量其站点运行状况。因此，缓存的对象将以6毫秒的延迟返回，并且掩盖了许多GET请求需要5000毫秒才能完成的事实。平均值必须消亡。RTT计数超过可接受的最大阈值万岁！该数字应为0，或者根据定义，RTT是不可接受的。

嗯，有多个原因。原因之一还在于，通常会使用命令定义背景或在html页面顶部，或者在首先加载的单独CSS中检索命令。在加载包含文本的文档正文之前。

另一个原因是，尽管在大多数情况下可以键入图像的大小，但Web设计人员没有使用它。因此，浏览器必须首先将整个图像加载到页面上，以便它知道如何在其周围包装文本。

一些设计师还希望显示第一张图片和下一个文本，他们通过使用JavaScript来实现这一点，例如，一个简单的页面将首先显示一个横幅，然后显示其他所有内容。

但是，如果您想知道为什么在我只想阅读新闻的同时，我的页面上为什么有这么多垃圾商业广告，那么有个适合您的解决方案。如果您使用的是Firefox，则可以使用垃圾邮件阻止程序。有了这样的插件，Webrowser就能知道提供垃圾邮件的站点，并简单地阻止它们，从而导致页面加载快得多，同时您仍然能够看到与阅读的文章相关的重要图像。

我建议所有处理缓慢页面加载的人尝试一下fidler。fidler可以与IEexplorer或FireFox一起使用（使用其代理功能）Fidler会实际显示实际花费的时间以及何时加载网页的一部分。这是一个HTML调试工具。