☰

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

tag-icon • tag-icon performance browser display webkit
Почему в наши дни веб-сайты не отображают текст сразу?

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

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

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

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

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

решение1

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

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

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

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

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

В конце поста Irish также приводит некоторые обновления, касающиеся поведения браузера по состоянию на 2011–04–14 гг.:

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

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

решение2

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

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

решение3

Короткий ответ:АЯКСилиУОФФ

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

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

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

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

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

Веб-сайты WOFF:

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

Сайты AJAX:

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

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

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

решение4

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

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

  1. извлечение HTML (несколько циклов для DNS, TCP, запрос/ответ)
  2. начать анализировать HTML, обнаружить внешние ресурсы, такие как внешний CSS и JS. Обратите внимание, что CSS блокирует макет, а JS блокирует анализ. Поэтому внешние ресурсы, такие как CSS и JS, загруженные в начале документа (например, в head), замедляют время, необходимое странице для отображения контента на экране.
  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/

Связанный контент