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

443

119

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

laurent

Posted 2013-02-07T06:22:29.273

Reputation: 5 258

72

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 http://font.ubuntu.com/ it will work immediately.

– Chris Morgan – 2013-02-07T09:20:44.683

21The 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 – 2013-02-07T10:00:10.450

1As 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 – 2013-02-07T11:55:59.600

6So 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 – 2013-02-07T12:06:22.627

1But font files are kept in cache, this site has long wait for loading m.aspx they might check that part – user613326 – 2013-02-07T12:42:49.290

/me remembers choosing one browser over another based on "load order" – Grady Player – 2013-02-07T16:10:26.400

@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. – tylerl – 2013-02-07T16:20:29.277

@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.. – user613326 – 2013-02-07T20:07:15.913

@user613326: well, with Firefox Portable the cache size is typically 0MB. Can't remember whether Chrome Portable has that or not. – Chris Morgan – 2013-02-07T20:42:31.300

@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. – user613326 – 2013-02-08T20:25:05.817

@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. – sourcejedi – 2013-02-10T10:28:36.623

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.... – Syed Aqeel Ashiq – 2013-02-15T09:49:18.137

Answers

482

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.

Daniel Andersson

Posted 2013-02-07T06:22:29.273

Reputation: 20 465

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. – user613326 – 2015-01-06T15:00:38.590

7Have 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 – 2013-02-08T02:17:14.447

4

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

– Steve Bennett – 2013-02-08T02:18:45.787

5@ratchetfreak it would be disconcerting to have the page reformat since the fonts probably wouldn't have the same metrics – Samuel Edwin Ward – 2013-02-08T19:31:24.020

6some would prefer to get to the reading part of browsing a webpage instead of waiting ages for the font to get loaded – ratchet freak – 2013-02-08T20:28:15.477

@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? – Mario – 2013-02-08T22:38:59.167

@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. – Daniel Andersson – 2013-02-10T18:55:46.317

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. – Bobby – 2013-07-17T11:43:23.003

117

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.

Marcel

Posted 2013-02-07T06:22:29.273

Reputation: 1 087

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 – 2013-02-08T20:37:23.663

19

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.

KevSheedy

Posted 2013-02-07T06:22:29.273

Reputation: 291

14

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.

Greg H

Posted 2013-02-07T06:22:29.273

Reputation: 149

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 https://developers.google.com/webfonts/docs/webfont_loader

– Marcel – 2013-02-07T10:56:39.080

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

– r3m0t – 2013-02-07T14:50:02.027

Code to prevent the "flash of useful content", tends to prevent images appearing as well as text. – Jon Hanna – 2013-02-08T15:13:11.937

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. – Ric – 2013-02-09T20:43:33.070

8

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/

Bryan McQuade

Posted 2013-02-07T06:22:29.273

Reputation: 81

4

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.

Benny

Posted 2013-02-07T06:22:29.273

Reputation: 89

21Nope - 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 – 2013-02-07T10:13:04.717

+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 – 2013-02-07T10:21:15.827

1Long answer: Developers, developers, developers, developers. – iono – 2013-02-07T16:54:11.060

@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 – 2013-02-10T07:33:24.883

3

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.

Michael Dillon

Posted 2013-02-07T06:22:29.273

Reputation: 899

-1

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.

user613326

Posted 2013-02-07T06:22:29.273

Reputation: 167

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 – 2013-02-07T12:02:07.577

21You 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 – 2013-02-07T12:28:18.407

8The 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 – 2013-02-07T20:21:13.743

1@raylu I don't know about that misinformation. Seeing an answer with a lot of downvotes can be quite helpful sometimes. :-) – LarsTech – 2013-02-07T21:13:59.333

7Hi @user613326: we encourage honest downvoting here, as we're primarily here to provide useful answers for the community. Don't take it personally! – Flimm – 2013-02-07T22:11:43.710

@raylu what made you think that ?? try fidler – user613326 – 2013-02-08T20:29:18.423

@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 – 2013-02-08T20:31:25.613