Why don't websites immediately display their text these days?

Question

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 below for an example - everything's loaded but it takes a few more seconds before the text is finally displayed:

Answer 1

One reason is that web designers nowadays like to use web fonts (usually in WOFF format), e.g. through Google 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

font-family: Arial, Helvetica, sans-serif;

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:

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

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

font-family: 'Droid Serif',sans-serif;

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 (a lot of comments seem to have disappeared a short while after the topic was protected — some moderator probably manually cleaned them). Also, read the other answers in this thread as they all expand in their own ways.

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 bit set 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.
• Addition: Blink has a bug registered for this too, but it seems a final consensus has not been reached regarding what to do with it - currently same implementation as WebKit.

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.

Answer 2

The reason for this is the text you can't read yet is being rendered with a web font that is still on its way down the pipes to your browser.

Also, since your browser is Google Chrome, which uses WebKit to render the page, it was decided by them (WebKit that is) that it's best for you not to see any text at all until the web font is downloaded. If, however, you're a developer that would prefer the text to be readable in a suitable fall-back system font instead, then you can use something like Google's WebFont Loader to achieve this.

Answer 3

Short answer: AJAX or WOFF

There are several causes of websites being "slow to display their text". The slowness on portableapps.com is caused by downloading WOFF fonts. However, what you describe as "text starts appearing here and there" is more often caused by AJAX.

A website is made up of many parts. How these parts are downloaded and assembled is a design choice under the control of the web designer. The slowness is caused by how the developer chooses to assemble the following building blocks:

• Initial HTML page
• CSS
• JS
• Images
• WOFF fonts
• AJAX requests
• DOM manipulation

---

Traditionally websites:

Traditionally, it was common for developers to put the text content in the initial HTML page and display it as soon as it was available. The HTML would reference several resources that would then be downloaded. The browser would then progressively redraw the screen to include the styles and images as they became available. AJAX and WOFF were not available.

---

WOFF Websites:

WOFF fonts allows a website to use fonts that aren't normally available to the browser, by downloading fonts with the website. Some developers instruct the browser not to display the text content until all the WOFF fonts have been downloaded. In my experience, this approach hasn't gained very wide usage yet.

---

AJAX Websites:

Some developers choose not to include the text content in the initial HTML page. Instead, they choose to download the text content using AJAX. This happens after the basic page has been loaded. In my experience, this method has gained much wider adoption than WOFF fonts and is most often the cause of the slowness you describe.

---

Determining the Cause

To determine the cause for a specific site requires analysis using tools like Firebug or Chrome Developer Tools. Or alternatively, you can open the site using Internet Explorer 8, which supports AJAX but not WOFF. If the site is still slow, the problem is AJAX and not WOFF.

Answer 4

I often it may be a deliberate choice to avoid the "flash of unstyled content". If the text displayed before the CSS was loaded, you'd briefly see it as it appears raw, and then a flash as the browser redraws it. By putting in some basic inline styles to initially hide the content, that are overridden in the actual stylesheet, or using JS, developers avoid this flash.

Answer 5

As others have noted, custom fonts are likely contributing to the delay.

To give a little more background, the browser is doing roughly the following before it can render the page contents to the screen:

1. fetch HTML (several round trips for DNS, TCP, request/response)
2. begin to parse HTML, discover external resources such as external CSS and JS. Note that CSS blocks layout, and JS blocks parsing. So external resources like CSS and JS loaded early in the document (e.g. in the head) slow down the time it takes for a page to display content on the screen.
3. fetch external CSS and JS (several round trips: DNS and TCP if these resources are on a different domain such as CDN, as well as an RTT for the request/response)
4. once the external CSS and JS have finished loading, parse/execute JS, parse/apply styles
5. if the CSS makes reference to custom fonts, those fonts now have to be downloaded as well, resulting in additional round trip delays to render any parts of the page that depend on the custom fonts

Though it isn't about the delays caused by custom fonts specifically, I wrote a blog post recently that gives additional information about the causes of render delays. It gives some suggestions to minimize the time to first paint for your pages. Hopefully this is useful for readers interested in making their pages display content faster, including those pages that want to use custom fonts: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/

Answer 6

Short answer: Developers.

When link and script tags referencing external documents (like .css or .js files) are placed in the head of the document (higher in the flow than the body, and its elements), they are loaded first. JavaScript executes from the markup that references it; if there is a lot of code to process, or it's cumbersome code, or more commonly if the text you expect to see is being rendered on a server and populated into the document on load -- and that server-sided code is also cumbersome, large, or blocking I/O due to processing of several concurrent requests, you may certainly notice downtime before the HTML has had a chance to even render. Some developers choose to load non-view-related JavaScript after markup and styles (at the end of the body), and the best try to be more conscious of how their technology decision will affect the overal user experience when implemented.

Internet connection speed plays a role in the slow downloading of data, quite obviously, but poorly written code, or poorly designed technology stacks (for the type of website) play an increasingly central role in the slow loading of dynamic content, as faster network connections approach ubiquity.

Answer 7

In a nutshell, too many loadable objects that need to be loaded from separate HTTP GETs before the page can be displayed, and an over reliance on average latency as a measure of site health.

The first refers to all those .css, .js, and webfonts that the page loads, not to mention the fact that many sites also need to retrieve JSON objects viea XHR requests and then generate HTML from those using some kind of templating.

But why don't they notice that the site is slow?

Probably because they have memecache in there somewhere to speed things up (or just rely on filesystem caches) and are measuring their site health using average latency. Thus the cached objects are returned with 6 mircrosecond latency and mask the fact that many GET requests take 5000 milliseconds to complete. Averages must die. Long live the counting of RTTs over an acceptable maximum threshold! That number should be 0 or, by definition, the RTT is unacceptable.

Answer 8

Well there are multiple reasons. One reason is also that commands to define a background or on top of a html page often Or retrieved in a separate CSS that is loaded first. before the body of the document is loaded which contains the text.

Another cause is that although it is possible to type the size of an image in most cases web designers don't make use of that. And so the brouwser has to load the whole images first on the pages so that it knows how to wrap text around it.

Some designers, also wants to show first pictures and next text, they achieve that by some javascript so for example a simple page will first show a banner and then everything else on it.

But if your wondering why there is so much spam commercial stuff on my pages while i only want to read the news, then there is a solution for you. You can make use of spam-blockers if your using firefox. With such an addon the webrowser knows sites that provides spam, and simply blocks them, resulting in a much faster page load, while your still be able to see the important images that relate to the articles you read.

I would recomend to all of you who deal with slow page loading to try fidler. fidler can be used with IEexplorer or with FireFox (using its proxy function) Fidler will actually show you how long it actually takes and when parts of a web page are loaded. It is a HTML debugging tool.