Вопрос: Почему веб-сайты не отображают свой текст в наши дни?


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

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

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

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

enter image description here


439
2018-02-07 06:22


Источник


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


Ответы:


Одна из причин заключается в том, что веб-дизайнеры в настоящее время любят использовать веб-шрифты (обычно в Уофф формат), например. через Веб-шрифты 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
  • Будет: Отображение кэшированного ttf / otf / woff
  • Будет: Загрузка и отображение данных-uri ttf / otf / woff
  • Будет: Отображение кэшированных данных-uri ttf / otf / woff
  • Не будет: Отображение шрифта, который уже установлен и указан в вашем традиционном стеке шрифтов
  • Не будет: Отображение шрифта, который установлен именован, используя локальное () местоположение

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

Ирландский также имеет некоторые обновления относительно поведения браузера с 2011-04-14 в нижней части сообщения:

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

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


483
2018-02-07 07:54



Попросил ли кто-нибудь из браузеров сначала выполнить рендеринг текста в доступном шрифте и повторную рендеринг его после загрузки предпочтительного шрифта? - Steve Bennett
О, да, прокомментируйте следующий ответ: paulirish.com/2009/fighting-the-font-face-fout - Steve Bennett
@ratchetfreak было бы обескураживающе, чтобы переформатировать страницу, поскольку шрифты, вероятно, не будут иметь одинаковые показатели - Samuel Edwin Ward
некоторые предпочли бы перейти к чтению страницы просмотра веб-страницы, а не ждать возраста для загрузки шрифта - ratchet freak
@SteveBennett Я уверен, что это именно то, что делает Internet Explorer 10. Я никогда не видел, чтобы текст появлялся позже. Для меня это всегда текст, появляющийся в некотором «стандартном шрифте», и через несколько секунд он изменяется на стилизованный / загруженный. Я не уверен, выбрал ли он следующий CSS-код или только по умолчанию для системы. Edit: Ах, хорошо, так что это просто Webikit со скрытым текстом? Я бы подумал, что это раздражает и плохое поведение. Есть ли браузер, игнорирующий / скрывающий прогрессивную загрузку изображений? - Mario


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

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


117
2018-02-07 11:46



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


Короткий ответ: AJAX или Уофф

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

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

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

Традиционно веб-сайты:

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


WOFF Веб-сайты:

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


Веб-сайты AJAX:

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


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

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


19
2018-02-08 13:40





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


14
2018-02-07 08:26



Девять раз из десяти он не будет преднамеренным, это просто побочный эффект внедрения веб-шрифтов самым простым способом. Фактически, требуется немного дополнительных усилий, чтобы представить видимую альтернативу, пока веб-шрифты спускаются по трубе. Видеть developers.google.com/webfonts/docs/webfont_loader - Marcel
@Marcel - это может быть вызвано медленными таблицами стилей, а также медленными шрифтами, см. phpied.com/css-and-the-critical-path - r3m0t
Код для предотвращения «вспышки полезного контента», как правило, предотвращает появление изображений, а также текст. - Jon Hanna
Я изо всех сил пытаюсь понять, почему текст без текстуры хуже, чем никакой текст. Я предпочел бы начать читать, соглашаясь, что он может немного пошевелиться. Я нахожу его более резким, когда он внезапно появляется в никуда, и это очень неприятно, когда страница загружается, и вы вынуждены ждать шрифта. - Richard Le Poidevin


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

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

  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-one-second/


8
2018-02-07 18:26





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

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

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


4
2018-02-07 10:04



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


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

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

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

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


3
2018-02-13 04:25





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

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

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

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

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


-1
2018-02-07 11:41



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