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

443

Я заметил, что в последнее время многие сайты медленно отображают свой текст. Обычно загружаются фон, изображения и т. Д., Но текст отсутствует. Через некоторое время текст начинает появляться здесь и там (не всегда все одновременно).

Он работает в основном наоборот, когда раньше текст отображался, а затем загружались изображения и остальные. Какие новые технологии создают эту проблему? Любая идея?

Обратите внимание, что у меня медленное соединение, что, вероятно, подчеркивает проблему.

Ниже приведен пример - все загружено, но до окончательного отображения текста требуется еще несколько секунд:

введите описание изображения здесь

Laurent
источник
72
В данном конкретном случае PortableApps.com использует шрифт «Ubuntu». Сначала Джон попробовал OpenSans, но мы довольно быстро переключились на Ubuntu. Я был основным сторонником переключения ... один способ, которым вы можете устранить проблему, установив семейство шрифтов самостоятельно. Если вы установите его с сайта font.ubuntu.com, он будет работать немедленно.
Крис Морган
21
Ответ Даниэля сенсационный. Я думал, что это сделано специально, чтобы мы могли просматривать всю рекламу на странице.
Manoj R
1
Как указывалось здесь несколькими людьми, существует бесконечное количество причин для отображения текста неожиданными способами, поскольку отображение страницы ограничено только воображением разработчика / дизайнера, что имело место, по крайней мере, с тех пор, как коды положения ANSI позволили опубликовать бюллетень 1980-х годов. доски для реализации многопользовательских чатов и интерфейсов с перекрывающимися окнами с тенями. Meebo был одним из первых, кто воспроизвел некоторые из этих эффектов в браузере без апплета. «Работает противоположно, как раньше», значительно упрощает Интернет и даже не относится к определенному периоду времени.
PJ Brunet
6
Так зачем делать широкие обобщения об Интернете, основанные на одной случайной заглушке с сайта с низким рейтингом Alexa? Лучший ответ также делает смелое утверждение: «в настоящее время дизайнеры делают XYZ» должны быть подкреплены некоторыми действительными числами, такими как «5% веб-сайтов используют Google Web Fonts по состоянию на 2012 год» или что-то еще.
PJ Brunet
1
Но файлы шрифтов хранятся в кеше, этот сайт долго ждет загрузки m.aspx, они могут проверить эту часть
user613326

Ответы:

482

Одна из причин заключается в том, что в настоящее время веб-дизайнерам нравится использовать веб-шрифты (обычно в формате WOFF ), например, через веб-шрифты Google .

Ранее единственными шрифтами, которые можно было отобразить на сайте, были те, которые пользователь установил локально. Так как, например, пользователи Mac и Windows не обязательно имели одинаковые шрифты, дизайнеры инстинктивно всегда определяли правила как

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

где, если первый шрифт не найден в системе, браузер будет искать второй, и, наконец, запасной шрифт «без засечек».

Теперь можно указать URL-адрес шрифта в качестве правила CSS, чтобы браузер мог загрузить шрифт следующим образом:

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

а затем загрузить шрифт для определенного элемента, например:

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

Это очень популярно, когда можно использовать пользовательские шрифты, но это также приводит к тому, что текст не отображается до тех пор, пока ресурс не будет загружен браузером, который включает время загрузки, время загрузки шрифта и время рендеринга. Я ожидаю, что это тот артефакт, который вы испытываете.

В качестве примера: одна из моих национальных газет, Dagens Nyheter , использует веб-шрифты для заголовков, но не для ссылок, поэтому, когда этот сайт загружается, я обычно вижу сначала, а через полсекунды заполняются все пустые места, указанные выше. с заголовками (это верно для Chrome и Opera, по крайней мере. Другие не пробовал).

(Кроме того, в наши дни дизайнеры распространяют JavaScript абсолютно везде, поэтому, возможно, кто-то пытается сделать что-то умное с текстом, поэтому он откладывается. Однако это будет очень специфично для сайта: общая тенденция задержки текста в этих раз проблема веб-шрифтов, описанная выше, я считаю.)


прибавление

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

Этот феномен, по-видимому, известен как «флеш нестандартного контента» в целом и «флеш нестандартного текста» в частности. Поиск "FOUC" и "FOUT" дает больше информации.

Я могу порекомендовать пост веб-дизайнера Пола Ирриша на FOUT в связи с веб-шрифтами .

Что можно отметить, так это то, что разные браузеры обрабатывают это по-разному. Я писал выше, что я тестировал Opera и Chrome, которые оба вели себя одинаково. Все основанные на WebKit (Chrome, Safari и т. Д.) Предпочитают избегать FOUT, не отображая текст веб-шрифта с резервным шрифтом в течение периода загрузки веб-шрифтов. Даже если веб-шрифт кэшируется, будет задержка рендеринга . В этой ветке вопросов есть много комментариев, говорящих об обратном, и что неправильно кэшированные шрифты ведут себя так, но, например, по приведенной выше ссылке:

В каких случаях вы получите FOUT

  • Будет: загрузка и отображение удаленного ttf / otf / woff
  • Will: Отображение кэшированного ttf / otf / woff
  • Will: Загрузка и отображение данных-uri ttf / otf / woff
  • Будет: отображение кэшированных данных-uri ttf / otf / woff
  • Не будет: отображение шрифта, который уже установлен и назван в вашем традиционном наборе шрифтов
  • Не будет: отображение шрифта, который установлен и назван с использованием local ()

Поскольку Chrome ждет, пока риск FOUT не исчезнет, ​​перед рендерингом это дает задержку. В какой степени эффект виден (особенно при загрузке из кэша), по-видимому, зависит, помимо прочего, от объема текста, который необходимо отобразить, и, возможно, от других факторов, но кэширование не полностью удаляет эффект.

У ирландцев также есть некоторые обновления, касающиеся поведения браузера, по состоянию на 2011–04–14 в нижней части поста:

  • Firefox (по состоянию на FFb11 и FF4 Final) больше не имеет FOUT! Wooohoo! http://bugzil.la/499292 В основном текст невидим в течение 3 секунд, а затем он возвращает запасной шрифт. Веб-шрифт, вероятно, будет загружен в течение этих трех секунд, хотя ... надеюсь ...
  • IE9 поддерживает WOFF, TTF и OTF (хотя для этого требуется набор битов для встраивания - в основном спорный, если вы используете WOFF). ТЕМ НЕ МЕНИЕ!!! IE9 имеет FOUT. :(
  • В Webkit есть патч, ожидающий приземления, который показывает запасной текст через 0,5 секунды. То же поведение, что и FF, но 0,5 с вместо 3 с.
  • Дополнение : Blink также зарегистрировала ошибку для этого , но кажется, что окончательное согласие не было достигнуто относительно того, что с этим делать - в настоящее время та же реализация, что и в WebKit.

Если бы этот вопрос был направлен на дизайнеров, можно было бы попытаться избежать таких проблем, как webfontloader, но это был бы другой вопрос. Ссылка Пола ирландского языка содержит более подробные сведения по этому вопросу.

Даниэль Андерссон
источник
7
Пробовал ли кто-нибудь из браузеров отображать текст сначала доступным шрифтом и повторно отображать его после загрузки предпочтительного шрифта?
Стив Беннетт
4
Ох, прокомментируйте следующий ответ: paulirish.com/2009/fighting-the-font-face-fout
Стив Беннетт
5
@ratchetfreak было бы неудобно переформатировать страницу, поскольку шрифты, вероятно, не имели бы одинаковых показателей
Сэмюэль Эдвин Уорд
6
некоторые предпочли бы перейти к чтению при просмотре веб-страницы, а не ждать целую вечность, пока шрифт загружается
ratchet freak
@ SteveBennett Я уверен, что это именно то, что делает Internet Explorer 10. Я никогда не видел текст, появляющийся позже. Для меня это всегда текст, который появляется в каком-то «стандартном шрифте», а через несколько секунд он меняется на стилизованный / загруженный. Я не уверен, выберет ли он следующий CSS или только системное значение по умолчанию. Редактировать: Ах, хорошо, так что это просто Webikit со скрытым текстом? Я бы посчитал это раздражающим и плохим поведением. Есть ли браузер, игнорирующий / скрывающий прогрессивную загрузку изображения?
Марио
117

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

Кроме того, поскольку ваш браузер - Google Chrome, который использует WebKit для рендеринга страницы, они решили (то есть WebKit), что вам лучше вообще не видеть никакого текста, пока веб-шрифт не загружен. Однако если вы разработчик, который предпочел бы, чтобы текст читался подходящим резервным системным шрифтом, вы можете использовать что-то вроде Google WebFont Loader для этого.

завивать волосы щипцами
источник
К сожалению, это неправильный ответ, если вы зайдете на эту страницу один раз, файл шрифта будет находиться в вашей наличной сети; для других страниц на этом сайте или других веб-сайтов, использующих этот шрифт, он будет получен наличными.
user613326
19

Краткий ответ: 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.

KevSheedy
источник
14

У меня часто бывает преднамеренный выбор, чтобы избежать «вспышки нестандартного контента». Если текст, отображаемый до загрузки CSS, вы кратко увидите, как он выглядит необработанным, а затем мигните, когда браузер перерисовывает его. Вводя некоторые базовые встроенные стили для первоначального скрытия содержимого, которые переопределяются в реальной таблице стилей, или используя JS, разработчики избегают этой флеш-памяти.

Грег Х
источник
6
В девяти случаях из десяти это не будет преднамеренным, это просто побочный эффект от встраивания веб-шрифтов самым простым способом. На самом деле, требуется немного больше усилий, чтобы представить видимую альтернативу, пока веб-шрифты начинают работать. См. Developers.google.com/webfonts/docs/webfont_loader
Марсель
@Marcel - это может быть вызвано медленными таблицами стилей, а также медленными шрифтами, см. Phpied.com/css-and-the-critical-path
r3m0t
Код для предотвращения «вспышки полезного контента», как правило, предотвращает появление изображений, а также текста.
Джон Ханна
Я изо всех сил пытаюсь понять, почему текст без стиля хуже, чем текст вообще. Я предпочел бы начать читать акцепт, который может немного колебаться. Я нахожу это более резким, когда он внезапно появляется из ниоткуда, и очень расстраивает, когда страница загружена, и вы вынуждены ждать шрифта.
Ричард Ле Пойдевен
8

Как уже отмечали другие, нестандартные шрифты, вероятно, способствуют задержке.

Чтобы дать немного больше фона, браузер делает примерно следующее, прежде чем он сможет отобразить содержимое страницы на экране:

  1. получить HTML (несколько циклов для DNS, TCP, запрос / ответ)
  2. начать анализировать HTML, открывать внешние ресурсы, такие как внешние CSS и JS. Обратите внимание, что CSS блокирует макет, а JS - парсинг. Поэтому внешние ресурсы, такие как CSS и JS, загруженные в начале документа (например, в заголовке), замедляют время, необходимое странице для отображения содержимого на экране.
  3. извлекать внешние CSS и JS (несколько циклов: DNS и TCP, если эти ресурсы находятся в другом домене, например CDN, а также RTT для запроса / ответа)
  4. как только внешние CSS и JS закончили загрузку, проанализируйте / выполните JS, проанализируйте / примените стили
  5. если CSS ссылается на пользовательские шрифты, эти шрифты теперь также необходимо загружать, что приводит к дополнительным задержкам прохождения в обоих направлениях для рендеринга любых частей страницы, которые зависят от пользовательских шрифтов

Хотя речь идет не о задержках, вызванных именно пользовательскими шрифтами, я недавно написал сообщение в блоге, в котором содержится дополнительная информация о причинах задержек рендеринга. Это дает некоторые предложения, чтобы минимизировать время, чтобы сначала нарисовать для ваших страниц. Надеемся, что это полезно для читателей, заинтересованных в том, чтобы на их страницах быстрее отображался контент, включая те, которые хотят использовать пользовательские шрифты: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -одну секунду/

Брайан МакКуэйд
источник
4

Краткий ответ: разработчики.

Когда теги link и script, ссылающиеся на внешние документы (например, файлы .css или .js), помещаются в заголовок документа (выше по потоку, чем тело и его элементы), они загружаются первыми. JavaScript выполняется из разметки, которая на него ссылается; если требуется много кода для обработки, или это громоздкий код, или чаще, если текст, который вы ожидаете увидеть, отображается на сервере и загружается в документ при загрузке - и этот серверный код также громоздок, большой или блокирующий ввод / вывод из-за обработки нескольких одновременных запросов, вы, безусловно, можете заметить время простоя до того, как у HTML появится возможность даже выполнить рендеринг. Некоторые разработчики предпочитают загружать не связанный с просмотром JavaScript после разметки и стилей (в конце тела),

Скорость интернет-соединения играет определенную роль в медленной загрузке данных, совершенно очевидно, но плохо написанный код или плохо разработанные технологические стеки (для типа веб-сайта) играют все более важную роль в медленной загрузке динамического контента, так как более быстрые сетевые соединения подходить повсеместно.

Бенни
источник
21
Нет - то, что вы описываете, может блокировать отображение элементов DOM, но не только текста. Ответ заключается в замене шрифта, и это вина дизайнеров , а не разработчиков.
Тоби
+1 @ Тоби, потому что это действительно вина дизайнеров. Это очень раздражает, если вы находитесь на медленной линии связи (например, о, я не знаю, мой мобильный телефон или стационарный телефон дома). Подобные вещи просто замедляют работу сайтов и раздражают пользователей без какой-либо выгоды.
Магнус
1
Длинный ответ: разработчики, разработчики, разработчики, разработчики.
Ионо
@Toby Дизайнеры указывают, какие шрифты использовать, да, но каждый хороший разработчик должен сделать правильный выбор во время технической реализации. Хороший разработчик также поймет, почему это происходит (объяснено в ответе выше), что можно сделать, чтобы избежать проблемы (Google Webfont Loader), и как это влияет на работу.
Арбалес
3

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

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

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

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

Майкл Диллон
источник
-1

Ну, есть несколько причин. Одной из причин также является то, что команды для определения фона или поверх HTML-страницы часто или извлекаются в отдельном CSS, который загружается первым. перед загрузкой тела документа, содержащего текст.

Другая причина заключается в том, что, хотя в большинстве случаев веб-дизайнеры не могут использовать размер изображения, это возможно. И поэтому браузер должен сначала загрузить целые изображения на страницах, чтобы он знал, как обернуть текст вокруг него.

Некоторые дизайнеры также хотят показать первые изображения и следующий текст, они достигают этого с помощью некоторого javascript, поэтому, например, на простой странице сначала будет отображаться баннер, а затем все остальное на нем.

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

Я рекомендую всем, кто занимается медленной загрузкой страниц, попробовать fidler. fidler можно использовать с IEexplorer или FireFox (используя функцию прокси). Fidler фактически покажет вам, сколько времени на самом деле это происходит и когда загружаются части веб-страницы. Это инструмент отладки HTML.

user613326
источник
так ты пытаешься помочь людям и получить голосование, разве это не весело? Хорошо, я дважды подумаю, прежде чем объяснять людям технические вещи в терминах непрофессионалов.
user613326
21
Вы объяснили что-то не то, вот почему вас обижают. Как видно на скриншоте, страница полностью загружена, только текст не отображается. Это не имеет ничего общего с изображениями.
Femaref
8
Тело документа почти всегда загружается перед внешним CSS. Браузер не прекращает парсинг страницы только для загрузки внешнего контента. Попытка помочь полезна только в том случае, если вы действительно помогаете. Дезинформация хуже, чем отсутствие информации.
RayLu
1
@raylu Я не знаю об этой дезинформации. Просмотр ответа с большим количеством отрицательных отзывов иногда может быть очень полезным. :-)
LarsTech
7
Привет @ user613326: мы поощряем честное голосование здесь, поскольку мы в первую очередь здесь, чтобы дать полезные ответы для сообщества. Не принимай это на свой счет!
Flimm