Как не сойти с ума, используя кастомные шрифты в web?

Пользователи часто встречают такую ситуацию, когда web-страница загружает картинки и внешнее оформление, но в окне нет текста, он «запаздывает» на несколько (десятков?) секунд. Такая ситуация возникает при загрузке кастомных web-шрифтов.

Стоит разъяснить, из-за чего это проявляется и как можно избежать подобных багов.

На собеседовании при приеме на работу программистов или ops-инженеров задают классический вопрос: в адресной строке браузера записано meduza.io и после этого Вы нажимаете «Ввод», что происходит на экране? (Ответ будет на 10 листах).

Если для своего текста было указано font-family: PFRegal, «Times New Roman». В этом случае что будет? Браузер просматривает, существует для PFRegal объявление по font-face. Когда оно есть, то начинается загрузка самого файла указанного шрифта. При этом что увидять пользователи за те секунды (десятки на 3G) во время такой загрузки?

В Safari: текст станет занимать на странице свое место, но он останется прозрачным, просто НЕвидимым для пользователя. Для просчета занимаемого места будет использован fallback font (стандартный шрифт). В нашем варианте — Times New Roman, но это рассмотрим немного ниже.

В Firefox или Chrome будет 3 секунды виден прозрачный текст, а далее используется свой системный fallback font.

А вот IE сразу продемонстрирует fallback font. Internet Explorer не такой же и плохой!

Заметим, что все приведенные 3 подхода вполне отвечают заявленному стандарту: «in cases where textual content is loaded before downloadable fonts are available, user agents may render text as it would be rendered if downloadable font resources are not available or they may render text transparently with fallback fonts to avoid a flash of text using a fallback font.»

Как можно побороть «прозрачный текст» в Chrome или Safari?

Существует несколько методов:

  1. Создать отдельно css-файл с инлайном самого шрифта, и подключать его уже после html кода с нужным текстом. Сам HTML документ станет обрабатываться по мере загрузки (и отображаться на дисплее), от начала файла до его конца. Такой способ позволит управлять шрифтами, и без использования JavaScript. Принципиально сделать не просто подключение внешнего файла со шрифтом, а именно инлайн. Данный метод не годится для Desktop Safari. Он может не срабатывать и если нету достаточного «зазора» времени между подключением css-шрифта и самим запросом на рендеринг текста текстом. Можно поэкспериментировать.
  2. Использовать avascript-хак в котором invalid media type. Такой метод поможет сразу же отобразить весь текст с помощью fallback-шрифта, однако на тестах fallback-шрифт зависал немного больше, чем на первом способе. Такой подход имеет проблемы для FireFox и Internet Explorer, но в остальном, на данный момент, он смотрится наиболее логично.
  3. Попробовать Font Loading API, он дает сразу начать неблокирующую загрузку шрифта при открывании страницы. Такое новое js-API поддерживается лишь в Chrome или на самом «свежем» Safari.

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

Но теперь ВСЕ моргает на рефреше!

Решив одну проблему, нам «удалось» построить следующую. После «доработок» текст неприятно моргает при рефреше, а шрифт изменяется прямо на глазах у пользователя. В таком случае приходится определяться: что важнее?

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

Важно не забывать о некоторых системных вещах:

Нужно на стороне сервера (в cache headers) сделать настройку нормального кеширования.

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

Как протестировать, что все теперь работает хорошо? У меня чересчур шустрый Интернет.

1. Воспользуйтесь встроенным инструментарием Google Chrome Здесь предусмотрена возможность эмуляции «плохого» Интернета. Для отладки Медузы нашим выбором будет Good 3G.

Есть сброс кеша правой кнопкой мышки (действует лишь при открытых Developer Tools). Существует также суперзнание, помогающее блокировать загрузку определенных адресов, либо маски адресов в Chrome:

Включить Developer Tools Experiments в chrome://flags, → открыть Chrome Developer Tools → выбрать Настройки (запрятаны на трех точках справа вверху в углу) → найти Experiments → нажать 6 раз Shift→ Поставить галочку на Request blocking.

После этого Вы сможете поставить себе «Лайк»

1. Чтобы провести отладку в Desktop Safari необходимо инсталлировать Network Link Conditioner (чтобы скачать, нужен Apple Developer Account). Чтобы отладить iOS Webview и iOS Safari нужно использовать в настройках своего устройства Network Link Conditioner (Выбрать Settings→ Нажать Developer→Выбрать Network Link Conditioner). Необходимо учесть, что настройка по ограничению скорости будет актуальна не только для Safari, а для всей системы.

Что по поводу нового стандарта?

Это тоже возможно. Есть свойство font-display, которое доступно в Chrome Canary. С его помощью можно решать все проблемы, описанные в статье. Следующие пару-тройку лет можно будет «дышать» спокойно.

Я перфекционист, можно ли что-нибудь еще улучшить?

Естественно! Нужно сжать файл шрифта, настраивая его под себя. Полезно будет вырезать глифы, не используемые в текстах ( к примеру, у Регала по умолчанию из насчитывается свыше 800). Рекомендуется отключить ненужные Open Type Features. Чтобы все это реализовать Вам понадобится специальный софт и глубокое понимание внутреннего устройства шрифтов.

Выводы?

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

К оглавлению Опубликовано: 18.08.2017