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:

Solution 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.

Solution 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.

Solution 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.

Solution 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.

Solution 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/

View more solutions

Comments

[Chris Morgan]

In this particular case, PortableApps.com is using the "Ubuntu" font. John tried OpenSans first, but we switched to Ubuntu fairly quickly. I was the main proponent of switching... one way in which you can remove the problem is by having the font family installed yourself. If you install it from font.ubuntu.com it will work immediately.

[Manoj R]

The answer by Daniel is eye opener. I thought this is purposely done so that we can view all the advertisements on the page.

[PJ Brunet]

As several people have pointed out here, there are infinite reasons for text to render in unexpected ways, as rendering a page is only limited by the imagination of the developer/designer, which has been the case at least since ANSI position codes allowed 1980s bulletin boards to implement multiuser chats and UIs with overlapping windows with drop shadows. Meebo was one of the first to reproduce some of these effects in a browser without an Applet. "Works the opposite as it used to" vastly over-simplifies the Internet and doesn't even refer to a specific time period.

[PJ Brunet]

So why make sweeping generalizations about the Internet based on one random screen cap from a website with a low Alexa rank? The best answer also makes a bold claim: "nowadays designers do XYZ" should be backed up with some real numbers, like "5% of websites use Google Web Fonts as of 2012" or whatever it is.

[user613326]

But font files are kept in cache, this site has long wait for loading m.aspx they might check that part

[Alex]

@user613326 which is why if you click from page to page within the site, you don't get the font-load delay. But if you hit "reload", then the browser needs to re-validate all its cached files, and you'll see the delay again.

[user613326]

@tylerl did you try to do a time trace of the page loading? try using fidler (works with FF to) (also reloading each page isnt normal browsing behaviour. But maybe he has a cash size of zero MB..

[Chris Morgan]

@user613326: well, with Firefox Portable the cache size is typically 0MB. Can't remember whether Chrome Portable has that or not.

[user613326]

@chriss Morgan, Well no that's not default, firefox automatically reserves a Cache size which is *variable > please go to > Options > Advanced > network tab [ over there look at Cached web Content ] You can overide default and set it to zero or a fixed size i wouldnt advice to put it to zero if you like some speed. ( *default install based on fresh installed linux Mint) Or maybe you got confused by offline webcontent storage thats a different topic offline browsing in some cases keep settings.

[mu1988]

@chriss Wiki says Firefox portable used to disable disk cache. But that this was on the old version 2.0, and it's no longer the default.

[Syed Aqeel Ashiq]

I have a 512Kbps link(which is below average in today's age), and the overall experience about the website you mentioned is good, sometimes it takes a flash of a millisecond, and sometimes it don't. So I guess the designers should not be worried about using web-fonts....

[Toby]

Nope - what you describe can block elements of the DOM from displaying but not just text. The answer is to do with font replacement and is the fault of designers, not developers.

[Marcel]

Nine times out of ten it won't be deliberate, it's simply a side-effect of embedding web-fonts in the simplest way possible. In fact, it takes a little extra effort to present a visible alternative while the web fonts are coming down the pipe. See developers.google.com/webfonts/docs/webfont_loader

[user613326]

so you try to help people and get down voted isnt that fun ? Ok i will think twice again before explaining people technical stuff in laymens terms here.

[Femaref]

You explained the wrong thing, that's why you are getting downvoted. As you can see in the screenshot, the page is fully loaded, only the text isn't displayed. This has nothing to do with images.

[r3m0t]

@Marcel - this can be caused by slow stylesheets as well as slow fonts, see phpied.com/css-and-the-critical-path

[iono]

Long answer: Developers, developers, developers, developers.

[raylu]

The body of the document is almost always loaded before external CSS. The browser doesn't stop parsing the page just to load external content. Trying to help is only useful if you are actually being helpful. Misinformation is worse than no information.

[LarsTech]

@raylu I don't know about that misinformation. Seeing an answer with a lot of downvotes can be quite helpful sometimes. :-)

[Flimm]

Hi @user613326: we encourage honest downvoting here, as we're primarily here to provide useful answers for the community. Don't take it personally!

[Steve Bennett]

Have any of the browsers tried rendering the text first in an available font, and re-rendering it once the preferred font is downloaded?

[Steve Bennett]

Oh, duh, comment on the next answer: paulirish.com/2009/fighting-the-font-face-fout

[Jon Hanna]

Code to prevent the "flash of useful content", tends to prevent images appearing as well as text.

[ratchet freak]

some would prefer to get to the reading part of browsing a webpage instead of waiting ages for the font to get loaded

[user613326]

@raylu what made you think that ?? try fidler

[user613326]

@Femaref i just wonder the good answer here, did anyone of you see the actual downloading of the font file over the wire, or did it just sounded like a nice answer,.. because network tracing doesnt showup a 2MB file to be constantly loaded.. images are loaded first because of page rendering.

[user613326]

Sadly its a wrong answer, if you would visit this page once, the font file would reside in your web cash; for other pages on this site or other websites using this font it would be retrieved from cash.

[Mario]

@SteveBennett I'm pretty sure that's exactly what Internet Explorer 10 is doing. I've never seen text popping up later on. For me it's always text appearing in some "standard font" and a few seconds later it changes to the styled/downloaded one. I'm not sure whether it picks the next CSS one or just the system's default though. Edit: Ah, nice, so it's just Webikit with the hidden text? I'd consider that annoying and bad behavior. Is there any browser ignoring/hiding progressive image loading?

[Ayaz]

@Toby The designers specify which fonts to use, yes, but its the job of every good developer to make the right choices during technical implementation. The good developer would also understand why its happening (explained in an answer above), what choices can be made to avoid the problem (Google Webfont Loader), and how that effects the experience.

[Daniel Andersson]

@user613326: There will be a delay even if the font is cached. There are many people disputing this among the comments, but that does not make it false in itself. The parsing and rendering time remains even if the download time is gone (though latency to the web server to receive the HTTP 200 is still needed), and on complicated pages this amounts to very noticeable delays. Just try it. It can be amended by developer tricks as mentioned in the linked blog post and the webfontloader project, but that is not really the focus of the question in hand: why does the FOUT happen when it happens.

[Jjames]

It might be noteworthy that his behavior can be controlled at least in Firefox with the settings gfx.downloadable_fonts.enabled and gfx.downloadable_fonts.fallback_delay. The former allows to disable the loading of webfonts completely, while the later is the 3 seconds you mentioned until the font is displayed via fallback. As far as I could test, that means that the text get's directly displayed and later is the webfont applied. Which is a much more desirable behavior for me.

[user613326]

Compared to average image sizes these days, a font download is relatively small. In most cases fidler or the developer look of IExplorer or developer look of Firefox (hit F12), will show you where you slow page building originates from. Most often its caused by external code, like hosted page counters, google statistics, trafic analyzers, or the server itself might have non optimized java/php/asp code, content for large sites is often stored in databases and even those can be slow, while the page make-up on such sites is standard (cached) and loads quick.