Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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:

enter image description here

share|improve this question
67  
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. –  Chris Morgan Feb 7 '13 at 9:20
16  
The answer by Daniel is eye opener. I thought this is purposely done so that we can view all the advertisements on the page. –  Manoj R Feb 7 '13 at 10:00
1  
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 Feb 7 '13 at 11:55
6  
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. –  PJ Brunet Feb 7 '13 at 12:06
1  
But font files are kept in cache, this site has long wait for loading m.aspx they might check that part –  user613326 Feb 7 '13 at 12:42

8 Answers 8

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.

share|improve this answer
44  
now if only webbrowsers use the fall back font until the web font is loaded everything would be fine –  ratchet freak Feb 8 '13 at 0:19
7  
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 Feb 8 '13 at 2:17
4  
Oh, duh, comment on the next answer: paulirish.com/2009/fighting-the-font-face-fout –  Steve Bennett Feb 8 '13 at 2:18
5  
@ratchetfreak it would be disconcerting to have the page reformat since the fonts probably wouldn't have the same metrics –  Samuel Edwin Ward Feb 8 '13 at 19:31
2  
some would prefer to get to the reading part of browsing a webpage instead of waiting ages for the font to get loaded –  ratchet freak Feb 8 '13 at 20:28

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.

share|improve this answer
21  
+1 for mentioning Google WebFont Loader, made exactly to resolve the problem reported by op –  pcans Feb 7 '13 at 12:32
    
+1 for the link to more background on WebKit and the link's more thorough investigation of the issue than in my answer. –  Daniel Andersson Feb 7 '13 at 15:47
    
+1 This is actually the correct answer. Not sure why Daniel's received so many up-votes, it's actually wrong about a few things. –  Django Reinhardt Feb 8 '13 at 16:01
    
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. –  user613326 Feb 8 '13 at 20:37

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.

share|improve this answer
6  
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 –  Marcel Feb 7 '13 at 10:56
    
@Marcel - this can be caused by slow stylesheets as well as slow fonts, see phpied.com/css-and-the-critical-path –  r3m0t Feb 7 '13 at 14:50
    
Code to prevent the "flash of useful content", tends to prevent images appearing as well as text. –  Jon Hanna Feb 8 '13 at 15:13
    
I struggle to understand why unstyled text is worse than no text at all. I'd rather be able to start reading an accept that it might jiggle about a bit. I find it more jarring when it sudden appears for nowhere and it's very frustrating when a page has loaded and you're forced to wait for a font. –  Richard Le Poidevin Feb 9 '13 at 20:43

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.

share|improve this answer

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/

share|improve this answer

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.

share|improve this answer
20  
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. –  Toby Feb 7 '13 at 10:13
    
+1 @Toby because it really is the designers' fault. It's extremely irritating too if you're on a slow link (such as, oh I dunno, my cell phone or the landline at home). Stuff like that just makes websites slower and irritates users for no benefit whatsoever. –  Magnus Feb 7 '13 at 10:21
1  
Long answer: Developers, developers, developers, developers. –  twome Feb 7 '13 at 16:54
    
@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. –  arbales Feb 10 '13 at 7:33

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.

share|improve this answer

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.

share|improve this answer
    
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. –  user613326 Feb 7 '13 at 12:02
20  
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. –  Femaref Feb 7 '13 at 12:28
7  
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. –  raylu Feb 7 '13 at 20:21
1  
@raylu I don't know about that misinformation. Seeing an answer with a lot of downvotes can be quite helpful sometimes. :-) –  LarsTech Feb 7 '13 at 21:13
6  
Hi @user613326: we encourage honest downvoting here, as we're primarily here to provide useful answers for the community. Don't take it personally! –  Flimm Feb 7 '13 at 22:11

protected by Daniel Beck Feb 7 '13 at 18:28

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.