If you’re prone to watching the browser pane with an eagle eye, you may have noticed that pages frequently load their images and layout before loading their text–the exact opposite loading pattern we experienced during the 1990s. What’s going on?

今天的问答环节是由SuperUser提供的，SuperUser是Stack Exchange的一个分支，是一个由社区驱动的问答网站分组。

问题

超级用户读者Laurent非常好奇为什么页面加载的元素与以前完全不同。他写道：

I’ve noticed that recently many websites are slow to display their text. Usually, the background, images and so on are going to be loaded, but no text. After some time the text starts appearing here and there (not always all of it at the same time).

It basically works the opposite as it used to, when the text was displayed first, then the images and the rest was loading afterwards. What new technology is creating this issue? Any idea?

Note that I’m on a slow connection, which probably accentuates the problem.

See [above] for an example – everything’s loaded but it takes a few more seconds before the text is finally displayed.

那是什么原因呢？劳伦特和我们中的许多人都记得，有一段时间，文本首先加载，而其他所有东西——加里什动画gif、平铺背景和90年代后期网络浏览的所有其他人工制品——都是后来才加载的。是什么原因造成了设计元素先设计后文本的现状？

答案

超级用户贡献者Daniel Andersson提供了一个非常详细的答案，可以从根本上解释为什么字体会加载最后一个谜：

One reason is that web designers nowadays like to use web fonts (usually in WOFF format), e.g. throughGoogle Web fonts.

Previously, the only fonts that were able to be displayed on a site was those that the user had locally installed. Since e.g. Mac and Windows users not necessarily had the same fonts, designers instinctively always defined rules as

where, if the first font wasn’t found on the system, the browser would look for the second, and lastly a fallback “sans-serif” font.

Now, one can give a font URL as a CSS rule to get the browser to download a font, as such:

and then load the font for a specific element by e.g.:

This is very popular to be able to use custom fonts, but it also leads to the problem that no text is displayed until the resource has been loaded by the browser, which includes the download time, the font loading time and the render time. I expect that this is the artifact that you are experiencing.

As an example: one of my national newspapers, Dagens Nyheter, use web fonts for their headlines, but not their leads, so when that site is loaded I usually see the leads first, and half a second later all the blank spaces above are populated with headlines (this is true on Chrome and Opera, at least. Haven’t tried others).

(Also, designers sprinkle JavaScript absolutely everywhere these days, so maybe someone is trying to do something clever with the text, which is why it is delayed. That would be very site specific, though: the general tendency for text to be delayed in these times is the web fonts issue described above, I believe.)

Addition:

This answer became very upvoted, though I didn’t go into much detail, or perhaps because of this. There have been many comments in the question thread, so I’ll try to expand a bit […]

The phenomenon is apparently known as “flash of unstyled content” in general, and “flash of unstyled text” in particular. Searching for “FOUC” and “FOUT” gives more info.

I can recommend web designer Paul Irish’s post on FOUT in connection with web fonts.

What one can note is that different browsers handle this differently. I wrote above that I had tested Opera and Chrome, who both behaved similarly. All WebKit based ones (Chrome, Safari, etc.) choose to avoid FOUT by not rendering web font text with a fallback font during the web font loading period. Even if the web font is cached, there will be a render delay. There are a lot of comments in this question thread saying otherwise and that it is flat out wrong that cached fonts behave like this, but e.g. from the above link:

In what cases will you get a FOUT

• Will: Downloading and displaying a remote ttf/otf/woff
• Will: Displaying a cached ttf/otf/woff
• Will: Downloading and displaying a data-uri ttf/otf/woff
• Will: Displaying a cached data-uri ttf/otf/woff
• Will not: Displaying a font that is already installed and named in your traditional font stack
• Will not: Displaying a font that is installed and named using the local() location

Since Chrome waits until the FOUT risk is gone before rendering, this gives a delay. To which extent the effect is visible (especially when loading from cache) seems to be dependent on among other things the amount of text that needs to be rendered and perhaps other factors, but caching does not completely remove the effect.

Irish also has some updates concerning browser behavior as of 2011–04–14 at the bottom of the post:

• Firefox (as of FFb11 and FF4 Final) no longer has a FOUT! Wooohoo!http://bugzil.la/499292 Basically the text is invisible for 3 seconds, and then it brings back the fallback font. The webfont will probably load within those three seconds though… hopefully..
• IE9 supports WOFF and TTF and OTF (though it requires an embedding bitset thing– mostly moot if you use WOFF). HOWEVER!!! IE9 has a FOUT. :(
• Webkit has a patch waiting to land to show fallback text after 0.5 seconds. So same behavior as FF but 0.5s instead of 3s.

If this was a question aimed for designers, one could go into ways to avoid these kinds of problems such as webfontloader, but that would be another question. The Paul Irish link goes into further detail on this matter.

有什么要补充解释的吗？在评论中发出声音。想从其他精通技术的堆栈交换用户那里阅读更多答案吗？请查看此处的完整讨论线程。