Web pages can take a long time to display their text. This is because the web page is designed to be displayed on a computer screen, and not on a phone or tablet. When you view a web page on your computer, your browser sends the text to your screen in response to requests from your computer. This process can take some time, so it can take some time for the text to show up on your screen.

Today’s Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Exchange, a community-driven grouping of Q&A web sites.

The Question

SuperUser reader Laurent is very curious about why exactly pages seem to load elements completely differently than they did once upon a time. He writes:

So what gives? Laurent, and many of us, remember a time when the text loaded first and everything else–garrish animated GIFs, tiled backgrounds, and all the other artifacts of late 90s web browsing–came later. What causes the current situation of design elements first, text later?

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.

The Answer

SuperUser contributor Daniel Andersson offers a wonderfully detailed answer that gets right to the bottom of the why-the-fonts-load-last mystery:

Have something to add to the explanation? Sound off in the the comments. Want to read more answers from other tech-savvy Stack Exchange users? Check out the full discussion thread here.

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.