Почему веб-сайты не отображают свой текст сразу?

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.

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.

Краткий ответ: AJAX или WOFF

Есть несколько причин, по которым веб-сайты «медленно отображают свой текст» . Медлительность на portableapps.com вызвана загрузкой шрифтов WOFF . Однако то, что вы описываете как «текст начинает появляться здесь и там», чаще всего вызывается AJAX .

Сайт состоит из множества частей. Как эти части загружаются и собираются - выбор дизайна под контролем веб-дизайнера . Медлительность вызвана тем, как разработчик выбирает сборку следующих строительных блоков:

• Начальная HTML-страница
• CSS
• JS
• Изображений
• Шрифты WOFF
• AJAX-запросы
• Манипулирование DOM

Традиционно сайты:

Традиционно разработчики обычно помещали текстовое содержимое на исходную HTML-страницу и отображали его, как только оно было доступно . HTML будет ссылаться на несколько ресурсов, которые затем будут загружены. Затем браузер будет постепенно перерисовывать экран, чтобы включить стили и изображения по мере их появления. AJAX и WOFF не были доступны.

Веб-сайты WOFF:

Шрифты WOFF позволяют веб-сайту использовать шрифты, которые обычно недоступны для браузера, загружая шрифты с веб-сайта . Некоторые разработчики инструктируют браузер не отображать текстовое содержимое до тех пор, пока не будут загружены все шрифты WOFF. По моему опыту, этот подход еще не получил широкого применения.

Сайты AJAX:

Некоторые разработчики предпочитают не включать текстовое содержимое в исходную HTML-страницу. Вместо этого они выбирают для загрузки текстовое содержимое с использованием AJAX. Это происходит после загрузки базовой страницы . По моему опыту, этот метод получил гораздо более широкое распространение, чем шрифты WOFF, и чаще всего является причиной медлительности, которую вы описываете.

Определение причины

Чтобы определить причину для конкретного сайта, необходим анализ с использованием таких инструментов, как Firebug или Chrome Developer Tools . Или же вы можете открыть сайт с помощью Internet Explorer 8, который поддерживает AJAX, но не WOFF. Если сайт все еще работает медленно, проблема в AJAX, а не в WOFF.

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.

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/

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.

Короче говоря, слишком много загружаемых объектов, которые необходимо загрузить из отдельных HTTP-запросов GET до отображения страницы, и чрезмерная зависимость от средней задержки как показателя работоспособности сайта.

Первый относится ко всем тем .css, .js и веб-шрифтам, которые загружает страница, не говоря уже о том, что многим сайтам также необходимо извлекать объекты JSON через XHR-запросы, а затем генерировать HTML из тех, которые используют какой-то шаблонизатор.

Но почему они не замечают, что сайт работает медленно?

Возможно, потому что у них где-то есть memecache, чтобы ускорить процесс (или просто полагаться на кеши файловой системы), и они измеряют состояние своего сайта с использованием средней задержки. Таким образом, кэшированные объекты возвращаются с задержкой в ​​6 микросекунд и маскируют тот факт, что для выполнения многих запросов GET требуется 5000 миллисекунд. Средние должны умереть. Да здравствует счет RTT за допустимый максимальный порог! Это число должно быть 0 или, по определению, RTT недопустимо.

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.