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

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

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

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

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

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

439 голосов | спросил this.lau_ 7 FebruaryEurope/MoscowbThu, 07 Feb 2013 10:22:29 +0400000000amThu, 07 Feb 2013 10:22:29 +040013 2013, 10:22:29

8 ответов


483

Одна из причин заключается в том, что веб-дизайнеры в настоящее время любят использовать веб-шрифты (обычно в формате 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 с помощью not рендеринга текста веб-шрифта с резервным шрифтом во время периода загрузки веб-шрифтов. Даже если веб-шрифт кэшируется, будет задержка визуализации . В этом вопросе есть много комментариев, говорящих иначе, и что неверно, что кешированные шрифты ведут себя так, но, к примеру, из приведенной выше ссылки:

  

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

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

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

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

  
  • Firefox (начиная с FFb11 и FF4 Final) больше не имеет 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 , но это был бы другой вопрос. Ссылка на Польский ирландский язык подробно обсуждается по этому вопросу.

ответил Daniel Andersson 7 FebruaryEurope/MoscowbThu, 07 Feb 2013 11:54:44 +0400000000amThu, 07 Feb 2013 11:54:44 +040013 2013, 11:54:44
117

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

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

ответил Marcel 7 FebruaryEurope/MoscowbThu, 07 Feb 2013 15:46:19 +0400000000pmThu, 07 Feb 2013 15:46:19 +040013 2013, 15:46:19
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 . Или, альтернативно, вы можете открыть сайт, используя Internet Explorer 8 , который поддерживает AJAX, но не WOFF. Если сайт все еще медленный, проблема заключается в AJAX, а не в WOFF.

ответил KevSheedy 8 FebruaryEurope/MoscowbFri, 08 Feb 2013 17:40:50 +0400000000pmFri, 08 Feb 2013 17:40:50 +040013 2013, 17:40:50
14

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

ответил Greg H 7 FebruaryEurope/MoscowbThu, 07 Feb 2013 12:26:32 +0400000000pmThu, 07 Feb 2013 12:26:32 +040013 2013, 12:26:32
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-one-second/

ответил Bryan McQuade 7 FebruaryEurope/MoscowbThu, 07 Feb 2013 22:26:46 +0400000000pmThu, 07 Feb 2013 22:26:46 +040013 2013, 22:26:46
4

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

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

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

ответил Benny 7 FebruaryEurope/MoscowbThu, 07 Feb 2013 14:04:45 +0400000000pmThu, 07 Feb 2013 14:04:45 +040013 2013, 14:04:45
3

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

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

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

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

ответил Michael Dillon 13 FebruaryEurope/MoscowbWed, 13 Feb 2013 08:25:57 +0400000000amWed, 13 Feb 2013 08:25:57 +040013 2013, 08:25:57
-1

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

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

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

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

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

ответил user613326 7 FebruaryEurope/MoscowbThu, 07 Feb 2013 15:41:37 +0400000000pmThu, 07 Feb 2013 15:41:37 +040013 2013, 15:41:37

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132