Новый способ уменьшить влияние загрузки шрифтов: CSS-дескрипторы шрифтов

Загрузка шрифтов долгое время была пугалом веб-производительности, и здесь действительно нет хороших вариантов. Если вы хотите использовать веб-шрифты, вы можете выбрать в основном Flash of Invisible Text (также известный как FOIT), где текст скрыт до тех пор, пока шрифт не загрузится, или Flash of Unstyled Text (FOUT), где вы сначала используете резервный системный шрифт, а затем обновляете его до веб-шрифт при загрузке. Ни один из вариантов на самом деле не «выиграл», потому что, честно говоря, ни один из них не является удовлетворительным.

Разве font-display не должен был решить эту проблему?

Свойство font-display для @font-face предоставило этот выбор веб-разработчику, в то время как раньше браузер решал, что (в прошлом IE и Edge предпочитали FOUT, тогда как другие браузеры предпочитали FOIT). Однако помимо этого это не решило проблему.

Ряд сайтов перешли на font-display: swap , когда он впервые появился, а Google Fonts даже сделал его шрифтом по умолчанию в 2019 году. Мысль здесь заключалась в том, что для производительности лучше отображать текст как можно быстрее , даже если это резервный шрифт, а затем заменить шрифт, когда он наконец загрузится.

Я тоже поддерживал это тогда, но меня все больше разочаровывает «эффект гидратации», когда веб-шрифт загружается, а символы расширяются (или сжимаются) из-за различий между шрифтами. Smashing Magazine, как и большинство издателей, использует веб-шрифты, и на приведенном ниже снимке экрана показана разница между первоначальным рендерингом (с резервными шрифтами) и окончательным рендерингом (с веб-шрифтами):

Теперь, когда их кладут рядом, веб-шрифты выглядят значительно лучше и соответствуют бренду Smashing Magazine. Но мы также видим некоторую разницу в расположении текста для двух шрифтов. Шрифты очень разных размеров, и из-за этого содержимое экрана смещается. В наш век Core Web Vitals и Cumulative Layout Shifts, которые (совершенно справедливо!) признаны вредными для пользователей, из-за этого font-display: swap — плохой выбор.

Я вернулся к font-display: block на сайтах, за которыми я ухаживаю, так как я действительно нахожу сдвиг текста довольно резким и раздражающим. Хотя это правда, что block не остановит сдвиги (шрифт по-прежнему отображается как невидимый текст), он, по крайней мере, делает их менее заметными для пользователя. Я также оптимизировал загрузку шрифтов, предварительно загрузив шрифты, которые я сделал как можно меньше, разместив подмножества шрифтов на собственном хостинге, поэтому посетители часто видели резервные шрифты только в течение небольшого периода времени. Для меня «период блокировки» swap был слишком коротким, и я, честно говоря, предпочел бы подождать немного дольше, чтобы получить правильный первоначальный рендеринг.

Использование font-display: optional может решить FOIT и FOUT — за дополнительную плату

Другой вариант — использовать font-display: optional . Эта опция в основном делает веб-шрифты необязательными или, другими словами, если шрифта нет к тому моменту, когда он нужен странице, браузер никогда не заменяет его. С этой опцией мы избегаем как FOIT, так и FOUT , в основном используя только уже загруженные шрифты.

Если веб-шрифт тогда недоступен, мы возвращаемся к резервному шрифту, но при навигации по следующей странице (или перезагрузке этой страницы) будет использоваться этот шрифт, поскольку к тому времени он должен был завершить загрузку. Однако, если веб-шрифт настолько неважен для сайта, то может быть хорошей идеей просто полностью удалить его — что даже лучше для производительности в Интернете!

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

Таким образом, все варианты шрифтов имеют свои недостатки, в том числе возможность вообще не использовать веб-шрифты или использовать системные шрифты (что ограничивает — но, возможно, не так ограничивает, как многие думают!).

Как сделать ваш запасной шрифт более близким к вашему шрифту

Святой Грааль загрузки веб-шрифтов заключался в том, чтобы сделать резервный шрифт ближе к реальному веб-шрифту , чтобы максимально уменьшить заметное смещение, чтобы использование swap было менее эффективным. Хотя мы никогда не сможем полностью избежать сдвигов, мы можем сделать лучше, чем на скриншоте выше. Приложение Font Style Matcher от Моники Динкулеску часто цитируется в статьях о загрузке шрифтов и дает фантастическое представление о том, что здесь должно быть возможно. Он позволяет вам накладывать один и тот же текст двумя разными шрифтами , чтобы увидеть, насколько они различаются, и настраивать параметры шрифта, чтобы сделать их более близкими:

К сожалению, проблема с сопоставлением стилей шрифтов заключается в том, что мы не можем применить эти стили CSS только к резервным шрифтам, поэтому нам нужно использовать JavaScript и API FontFace.load, чтобы применить (или отменить) эти различия стилей, когда веб-сайт загружается шрифт .

Объем кода невелик, но все же кажется, что это требует немного больше усилий, чем должно быть. Хотя есть и другие преимущества и возможности использования JavaScript API для этого, как объяснил Зак Лезерман в этом фантастическом выступлении еще в 2019 году, — вы можете уменьшить количество перекомпоновок и обрабатывать режим data-server данных и prefers-reduced-motion (обратите внимание, однако что оба с тех пор подверглись воздействию CSS после того разговора).

Также сложнее обрабатывать кэшированные шрифты, которые у нас уже есть, не говоря уже о различиях в различных резервных стилях. Здесь, в Smashing Magazine, мы попробуем несколько запасных вариантов, чтобы наилучшим образом использовать системные шрифты, установленные разными пользователями и операционными системами:

 font-family: Mija,-apple-system,Arial,BlinkMacSystemFont,roboto slab,droid serif,segoe ui,Ubuntu,Cantarell,Georgia,serif;

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

Приближается лучшее решение

Итак, это краткий обзор того, как обстоят дела на сегодняшний день. Однако на горизонте начинает появляться дым.

В восторге от дескриптора CSS «настройка размера» для шрифтов: уменьшите сдвиги макета, сопоставив резервный шрифт и основной веб-шрифт с помощью масштабного коэффициента для глифов (в процентах).

См. https://t.co/mdRW2BMg6A от @cramforce для демонстрации (Chrome Canary/FF Nightly с флагами) pic.twitter.com/hEg1HfUJlT

— Адди Османи (@addyosmani) 22 мая 2021 г.

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

Это именно то, что делает новый набор дескрипторов шрифтов , предлагаемый как часть модуля CSS Fonts Module Level 5. Они применяются к объявлениям @font-face , где определяется отдельный шрифт.

Саймон Хирн написал об этом предлагаемом обновлении спецификации дескрипторов шрифта, которое включает четыре новых дескриптора: ascent-override , descent-override , line-gap-override и advance-override (с тех пор как было удалено). Вы можете поиграть с игровой площадкой F-mods, созданной Саймоном, чтобы загрузить свои собственные и резервные шрифты, а затем поиграть с переопределениями, чтобы получить идеальное соответствие.

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

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

Как это работает? Допустим, у вас есть следующий CSS:

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } h1 { font-family: Lato, Arial, sans-serif; }

Затем вы должны создать @font-face для резервного шрифта Arial и применить к нему дескрипторы корректора . Вы получите следующий фрагмент CSS:

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } @font-face { font-family: "Lato-fallback"; size-adjust: 97.38%; ascent-override: 99%; src: local("Arial"); } h1 { font-family: Lato, Lato-fallback, sans-serif; }

Это означает, что при первоначальном использовании Lato-fallback (поскольку Arial является local шрифтом и может использоваться сразу без какой-либо дополнительной загрузки), тогда size-adjust и ascent-override позволяют приблизить его к шрифту Lato. Это дополнительное объявление @font-face для написания, но, безусловно, намного проще, чем обручи, через которые нам приходилось прыгать раньше!

В целом, в эту спецификацию включено четыре основных дескриптора @font-face : size-adjust , ascent-override , descent-override и line-gap-override , а некоторые другие все еще рассматриваются для нижнего индекса, верхнего индекса и других вариантов использования. .

Malte Ubl создала очень полезный инструмент для автоматического расчета этих настроек с учетом двух шрифтов и браузера, который поддерживает эти новые настройки (подробнее об этом чуть позже!). Как отмечает Мальте, компьютеры хороши в таких вещах! В идеале мы могли бы также предоставить эти настройки для распространенных шрифтов веб-разработчикам, например, дать эти подсказки в коллекциях шрифтов, таких как Google Fonts? Это, безусловно, помогло бы увеличить принятие.

Теперь разные операционные системы могут иметь несколько разные настройки шрифта, и добиться их точного соответствия практически невозможно, но это не цель. Цель состоит в том, чтобы сократить разрыв, поэтому использование font-display: swap больше не является таким неприятным опытом, но нам не нужно впадать в крайности с optional или отсутствующими веб-шрифтами.

Когда мы можем начать использовать это?

Три из этих параметров уже поставляются в Chrome, начиная с версии 87 , хотя дескриптор size-adjust ключа пока недоступен ни в одном стабильном браузере. Тем не менее, у Chrome Canary он есть, как и у Firefox под флагом, так что это не какая-то абстрактная, далекая концепция, а то, что может появиться очень скоро.

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

Chrome заявил о своем намерении сделать size-adjust доступной в Chrome 92, который должен быть выпущен 20 июля, что, по-видимому, указывает на то, что она почти готова.

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