От автора: пользовательский шрифт не является чем-то новым в Интернете, но его использование все же может стать одним из факторов замедления сайта и увеличения стоимости для конечного пользователя. Если вы не очень внимательный, все очень быстро повалится из рук, как в запросе, который я сделал в HTTP Archive.
Учитывая это, мы в MDN Web Docs экспериментируем с уменьшением влияния пользовательских шрифтов на конечного пользователя. Это включает воспринимаемую производительность, реально измеренную производительность и цену для конечного пользователя.
Пейзаж немного «волосатый», мягко говоря, и мы определенно не приукрашиваем. В этой статье я хочу рассказать об известных и менее известных способах использования пользовательских шрифтов в Интернете.
Обратите внимание, что этот пост посвящен тому, как можно лучше загружать кастомные шрифты для повышения производительности и улучшения UX. Прежде чем перейти к этому, необходимо проверить свои шрифты на сайте, сколько они добавляют к весу страниц. После этого необходимо принять честное решение, нужен ли вам весь этот вес, варианты и символы.
@font-face
Самый широко поддерживаемый и распространенный способ подключения кастомных веб-шрифтов. Тем не менее, у подхода есть свои минусы. Как отметил Manuel Matuzovic в своей замечательной статье: «Чем хорош @font-face, так это тем, что шрифты загружаются лениво. Но это так же и недостаток.»
Рассмотрите следующую таблицу
Это прекрасная демонстрация непредсказуемости работы ленивой загрузки @font-face в браузерах. Это еще больше добавляет уверенности цитате сверху.
Как бы то ни было, это отправная точка подключения пользовательских шрифтов на сайте.
font-display
Это новый дескриптор, добавленный в @font-face, как часть CSS Fonts Module Level 4. Это дает нам, разработчикам контроль над поведением загрузки шрифтов и их отображением. Можно задать одно из пяти значений auto, block, swap, fallback и optional.
Свойство font-display имеет очень хорошую поддержку, если игнорировать IE и Edge – отличный кандидат для прогрессивного улучшения. Это первое из того, что мы реализуем на MDN Web Docs.
Я не буду подробно останавливаться на всех пяти значениях. Я бы лучше рассказал о спецификации, но кратко опишу некоторые значения.
auto и block очень похожи, не стоит их применять. Единственный случай использования – когда рендер текста в любом другом шрифте напрямую влияет на юзабилити. Причина? Если указать font-display: block;, текст отрисовывается невидимыми чернилами до 3 секунд до применения фолбека.
Самый полезные — swap, fallback и optional.
Swap
Время блокирования равно нулю, но и время замены бесконечно. То есть любой текст со свойством font-display: swap; будет незамедлительно отрисован фолбек шрифтом, и как только загрузится нужный шрифт, браузер сделает подмену.
Стоит аккуратно использовать это значение, оно может вызвать дергания и ухудшение UX для конечного пользователя. Удобно использовать для логотипа компании.
Fallback
Мы добрались до самого полезного из пяти значений. У него очень короткое, около 100ms время блокирования и время подмены в 3 секунды. То есть если пользовательский шрифт не доступен сразу, браузер использует фолбек.
Если кастомный шрифт загрузился раньше времени, он будет заменен. Если нет, браузер оставит фолбек на все время жизни текущей страницы. Удобно для основного текста.
Optional
Как понятно из названия, значение используется для основного текста там, где хорошо подходит пользовательский шрифт. Блокирующее время такое же, как у fallback, но время подмены равно 0. Это как сказать «если шрифт уже загружен, используй его. Если нет, браузер, я доверяю тебе, сделай как лучше для моих пользователей, реши сам.».
Над последними опциями мы сейчас экспериментируем на MDN Web Docs.
Link type preload
Использование font-display – шаг в правильном направлении. Но что делать, если необходимо как можно быстрее загрузить критические шрифты. Как увеличить шанс их загрузки к моменту, когда браузер начнет их запрашивать?
Существует 2 метода на основе стандартов. В этой статья я расскажу о спецификации preload. Но также советую взглянуть на CSS Font Loading Module.
Первое, что нужно отметить, это то, что preload отличается от resource hints. Это примитив декларативного извлечения, который инициирует выборку, а не просто подсказку. Плюс preload в том, что он отделяет выборку ресурсов от парсинга и выполнения.
То есть браузер извлечет ресурс, но кроме мелкого парсинга CSS не будет парсить, выполнять и применять ресурс к текущему контексту. Это дает механизм предзагрузки критических ресурсов без блокирования window события onload и процесса рендера.
Стоит обратить внимание на пару вещей. Помимо ключевого слова preload в атрибуте rel необходимо указать тип ресурса, который будет предварительно загружаться. Это важно, так как позволяет браузеру устанавливать приоритет, применять политику CSP и устанавливать правильный заголовок Accept.
Тип ресурса задается через атрибут as. У атрибута as есть ряд возможных значений. Для шрифтов, как вы догадались, используется значение font.
Еще один полезный атрибут, который необходимо использовать, особенно со шрифтами – type. Как вы догадались, он позволяет указывать MIME-тип загружаемого шрифта. Так браузер может определить поддержку. И если MIME-тип не поддерживается, он не будет загружать шрифт, тем самым разгружая соединение.
Последний атрибут, о котором нужно знать — crossorigin. Как ясно из имени, атрибут необходим, если шрифт загружается с чужого домена.
Помимо этого Addy Osmani написала обширную статью по preload и resource hints в Chrome на сайте Medium. Пост очень важен, не пропустите его.
Предзагруженный шрифт без crossorigin удвоит выборку! Обязательно добавьте атрибут crossorigin при получении шрифтов с помощью preload. Иначе они будут загружаться дважды. Они запрашиваются через анонимный режим CORS. Это применимо, даже если шрифты и страница из одного места. Применимо и к другим анонимным выборкам (по умолчанию к XHR).
Соберем все вместе и предзагрузим пользовательский шрифт:
<link rel="preload" href="./fonts/OpenSans-Regular.woff2" as="font" type="font/woff2" crossorigin />
Всего одна строка кода может позитивно повлиять на производительность и UX сайта. Это будет следующее, что мы выкатим на MDN Web Docs. Надеюсь, вы, как и я, поражены этим потенциалом.
Надеюсь, вам понравилась статья, и вы узнали что-то, что сможете использовать для улучшения производительности на своих сайтах. А какие другие стратегии вы используете для пользовательских шрифтов? С нетерпением жду ваших ответов в комментариях.
Автор: Schalk Neethling
Источник: https://medium.com/
Редакция: Команда webformyself.