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

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

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

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

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

Существует несколько причин, по которым веб-сайты "медленно отображают свой текст". Медлительность на http://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.

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

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

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

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/

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

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

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

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

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

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

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

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

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

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

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

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