![为什么现在的网站不立即显示其文本?](https://linux22.com/image/1350261/%E4%B8%BA%E4%BB%80%E4%B9%88%E7%8E%B0%E5%9C%A8%E7%9A%84%E7%BD%91%E7%AB%99%E4%B8%8D%E7%AB%8B%E5%8D%B3%E6%98%BE%E7%A4%BA%E5%85%B6%E6%96%87%E6%9C%AC%EF%BC%9F.png)
我注意到最近很多网站显示文本的速度都很慢。通常,背景、图片等都会加载,但不会加载文本。一段时间后,文本开始出现在这里和那里(并不总是同时出现全部文本)。
它基本上与以前相反,先显示文本,然后显示图像,其余部分随后加载。什么新技术造成了这个问题?有什么想法吗?
请注意,我的连接速度很慢,这可能会加剧问题。
请参见下面的示例 - 所有内容都已加载,但还需要几秒钟才能最终显示文本:
答案1
其中一个原因是,如今的网页设计师喜欢使用网页字体(通常为沃夫格式),例如通过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;
能够使用自定义字体非常流行,但这也导致了一个问题,即在浏览器加载资源之前不会显示任何文本,这包括下载时间、字体加载时间和渲染时间。我预计这就是你正在经历的神器。
举个例子:我的一份全国性报纸,每日新闻,使用网络字体作为标题,但不使用引导字体,因此当该网站加载时,我通常会首先看到引导字体,半秒钟后,上面所有的空白处都填充了标题(至少在 Chrome 和 Opera 上是这样。没有尝试过其他的)。
(此外,如今设计师几乎随处可见 JavaScript,所以也许有人试图对文本做一些巧妙的事情,这就是文本延迟的原因。不过,这将因网站而异:我认为,现在文本延迟的普遍趋势是上述的网络字体问题。)
添加
这个答案得到了很多赞同,尽管我没有说得太详细,或者也许因为对此。问题主题中有很多评论,所以我将尝试扩展一点(很多评论似乎在主题被保护后不久就消失了——一些版主可能手动清理了它们)。另外,阅读此主题中的其他答案,因为它们都以自己的方式扩展。
这种现象通常被称为“无样式内容闪烁”,具体来说则是“无样式文本闪烁”。搜索“FOUC”和“FOUT”可获得更多信息。
我可以推荐网页设计师 Paul Irish 在 FOUT 上发表的有关网页字体的文章。
值得注意的是,不同的浏览器对此的处理方式不同。我在上面写道,我测试了 Opera 和 Chrome,它们的行为类似。所有基于 WebKit 的浏览器(Chrome、Safari 等)都选择通过以下方式避免 FOUT:不是在网络字体加载期间使用后备字体渲染网络字体文本。即使网络字体被缓存了,将要存在渲染延迟。此问题线程中有很多评论表示并非如此,并且缓存字体的行为完全是错误的,但例如从上面的链接:
在什么情况下你会得到FOUT
- 将要:下载并显示远程 ttf/otf/woff
- 将要:显示缓存的 ttf/otf/woff
- 将要:下载并显示 data-uri ttf/otf/woff
- 将要:显示缓存的 data-uri ttf/otf/woff
- 将不会:显示已安装并在传统字体堆栈中命名的字体
- 将不会:显示使用 local() 位置安装并命名的字体
由于 Chrome 会等到 FOUT 风险消失后再进行渲染,因此会造成延迟。程度效果是可见的(特别是从缓存加载时)似乎取决于需要呈现的文本量以及其他因素,但缓存并不能完全消除效果。
Irish 还在文章底部提供了一些有关 2011 年 4 月 14 日浏览器行为的更新:
- 火狐(截至 FFb11 和 FF4 Final)不再有 FOUT!哇噢!http://bugzil.la/499292基本上,文本会在 3 秒内不可见,然后会恢复备用字体。不过,webfont 可能会在这三秒内加载……但愿如此……
- IE9 支持 WOFF、TTF 和 OTF(尽管它需要嵌入位 设定事物– 如果您使用 WOFF,则基本毫无意义)。然而!!!IE9 有一个 FOUT。:(
- Webkit 有等待着陆的补丁在 0.5 秒后显示后备文本。因此与 FF 的行为相同,但时间为 0.5 秒,而不是 3 秒。
- 添加:Blink 有也为此注册了一个错误,但对于如何处理它似乎尚未达成最终共识 - 目前的实现与 WebKit 相同。
如果这个问题是针对设计师的,那么可以讨论如何避免这类问题,例如webfontloader
,但那是另一个问题。Paul Irish 链接对此事进行了更详细的介绍。
答案2
原因是您无法阅读的文本正在被渲染网络字体该数据仍在通过管道传输至您的浏览器。
此外,由于您的浏览器是 Google Chrome,它使用 WebKit 来呈现页面,这是他们决定的(即 WebKit)最好在下载 Web 字体之前看不到任何文本。但是,如果您是一名开发人员,希望文本在合适的后备系统字体中可读,那么您可以使用类似Google 的 WebFont 加载器为了达成这个。
答案3
有有几个原因的网站“文本显示缓慢”. 缓慢portableapps.com是由于下载沃夫字体。但是,你所描述的“文字开始随处出现”更常见的原因是AJAX。
网站由许多部分组成。如何下载和组装这些部分是一个设计选择在网站设计者。缓慢是由于开发人员选择如何组装以下构建块造成的:
- 初始 HTML 页面
- CSS
- JS
- 图片
- WOFF 字体
- AJAX 请求
- DOM 操作
传统网站:
传统上,开发人员通常将文本内容放在初始 HTML 页面并显示它一旦可用。HTML 将引用几个随后将被下载的资源。然后浏览器将逐步重绘屏幕包含可用的样式和图像。AJAX 和 WOFF 不可用。
WOFF 网站:
WOFF 字体允许网站使用浏览器通常无法使用的字体,方法是通过网站下载字体。有些开发人员指示浏览器在下载完所有 WOFF 字体之前不要显示文本内容。根据我的经验,这种方法尚未得到广泛使用。
AJAX 网站:
有些开发人员选择不在初始 HTML 页面中包含文本内容。相反,他们选择使用 AJAX 下载文本内容。这种情况会发生基本页面加载后。根据我的经验,这种方法已经取得了很大更广泛采用比 WOFF 字体更慢,并且通常是导致您所描述的速度缓慢的原因。
确定原因
要确定特定站点的原因,需要使用以下工具进行分析:萤火虫或者Chrome 开发者工具。或者,您也可以使用以下方式打开网站Internet Explorer 8,它支持 AJAX 但不支持 WOFF。如果网站仍然很慢,则问题出在 AJAX 而不是 WOFF。
答案4
正如其他人所说,自定义字体可能会导致延迟。
为了提供更多背景信息,浏览器在将页面内容呈现到屏幕上之前大致执行以下操作:
- 获取 HTML (DNS、TCP、请求/响应多次往返)
- 开始解析 HTML,发现外部资源,例如外部 CSS 和 JS。请注意,CSS 会阻止布局,而 JS 会阻止解析。因此,在文档早期(例如在头部)加载的 CSS 和 JS 等外部资源会减慢页面在屏幕上显示内容所需的时间。
- 获取外部 CSS 和 JS(多次往返:如果这些资源位于不同的域(例如 CDN)上,则需要 DNS 和 TCP,以及请求/响应的 RTT)
- 一旦外部 CSS 和 JS 加载完成,解析/执行 JS,解析/应用样式
- 如果 CSS 引用了自定义字体,那么现在也必须下载这些字体,从而导致渲染依赖于自定义字体的页面部分时出现额外的往返延迟
虽然这篇文章并不是专门讨论自定义字体导致的延迟,但我最近写了一篇博客文章,其中提供了有关渲染延迟原因的更多信息。它给出了一些建议,以尽量减少页面首次绘制的时间。希望这对那些希望让页面显示内容更快的读者有用,包括那些想要使用自定义字体的页面:http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/