Комментарии 30
Внутри @font-face
не нужно указывать text-rendering
. Это делается на уровне селекторов, например, :root { text-rendering: optimizeLegibility; }
.
Заканчивается 2023 год, поэтому форматы woff и ttf не нужны, только если вы не поддерживаете браузеры типа IE9.
Перевести SVG код в CSS вам поможет этот сервис.
Нагло скопированный с https://yoksel.github.io/url-encoder/
Удобней всего это сделать в сервисе «Оптимизация шрифтов».
Понимаю, что рекламируете свой сервис, но transfonter удобнее.
Заканчивается 2023 год, поэтому форматы woff и ttf не нужны, только если вы не поддерживаете браузеры типа IE9.
Полностью согласен. Но малоопытные пользователи, при сравнении 2 сервисов, выберут именно тот который генерирует woff и ttf форматы тоже. Пользователи очень часто делают выбор в пользу избыточной функциональности из соображений "на всякий случай". Поэтому, исходя этих, пускай и немного некорректных критериев оценки, чтобы выглядеть не хуже других сервисов, мы тоже эти форматы поддерживаем.
Нагло скопированный с https://yoksel.github.io/url-encoder/
Да, действительно. Причём сходство настолько близкое, что, скорее всего, код этого проекта и используется. Но в поисковых системах ищется именно страница https://bloggerpilot.com/en/tools/svg-to-css/, так как на ней есть текст, картинки, ссылки. То есть, авторы позаботились о продвижении.
Понимаю, что рекламируете свой сервис, но transfonter удобнее.
У нас интерфейс более наглядный и простой. Так же у нас можно точно перечислить символы которые попадут в итоговый файл шрифта. Точное управление набором символов - ключевая функция, которая помогает сократить размер файлов шрифтов. У transfonter необходимо самому указывать список символов в полях "Characters" или "Unicode ranges", что крайне неудобно. Так же интерфейс transfonter содержит множество редко используемых опций, которые отпугивают пользователей. Всё это приводит к тому, что весомое количество пользователей бросают задачу по оптимизации шрифтов на сайте, ещё на этапе выбора онлайн сервиса.
Внутри
@font-face
не нужно указыватьtext-rendering
. Это делается на уровне селекторов, например,:root { text-rendering: optimizeLegibility; }
.
Согласен.
Поскольку статья рекламная, есть в ней небольшие манипуляции.
Урезать знаковый состав нужно о-очень осторожно. Если ваш сайт подразумевает UGC или хотя бы регистрацию пользователей — это верный способ прострелить себе ногу. Потому что если оставить только базовую латиницу, 10-20% европейцев (моя субъективная оценка) не сможет даже корректно написать собственное имя. Ну вот статья у вас на английском, а в комментаторах французы, поляки, чехи, словаки, турки, румыны и прочие скандинавы. И все они активно используют диакритику.
Google Fonts хорош тем, что умеет разбивать шрифты на несколько файлов с разными сабсетами, каждый из которых загрузится только по необходимости, в зависимости от реального контента страницы. Причем, если браузер это не поддерживает, ему подсунут фоллбек.
А ещё не знаю как сейчас, а раньше было, что Google Fonts даже мог отдавать разные версии шрифтовых файлов в зависимости от ОС и браузера пользователя — с оптимизацией под разные системы рендеринга.
Урезать знаковый состав нужно о-очень осторожно.
Тут нет ничего срашного. Удалённые символы всегда можно вернуть обратно, просто перезапустив сервис.
Ну вот статья у вас на английском, а в комментаторах французы, поляки, чехи, словаки, турки, румыны и прочие скандинавы.
У нас можно подготовить сразу несколько языковый версий файлов. То есть, исходный фал шрифа загружаете один, а на выходе получаете сразу все нужные версии для разных языков и общий CSS, который их подключает.
Google Fonts хорош тем, что умеет разбивать шрифты на несколько файлов с разными сабсетами
У него эти сабсеты предопределены. У нас же вы можете свой сабсет подготовить. Мы прям исследование провели. В статье в разделе "Оставляем только используемые символы" есть таблица о том, что лучше: CDN гугла или файлы, сгенерированные в нашем сервисе. В итоге, используя наш сервис, удалось сократить размер файлов на 15% и делать не 2 запроса, а 1.
Например: у вас сайт по продаже корейской косметики. Названия товаров у вас на корейском и английском языках, а сам сайт на русском. Google предлагает вам загрузить 3 отдельных файла, а с помощью нашего сервиса вы сгенериурете 1 файл сразу для 3 языков. Более того, в нашем файле отсутствуют заведомо не используемые символы вроде ½, ±, § и т.д.
А ещё не знаю как сейчас, а раньше было, что Google Fonts даже мог отдавать разные версии шрифтовых файлов в зависимости от ОС и браузера пользователя
Вот это интересно. Могли бы вы поподробней об этом рассказать? При скачивании шрифтов, даже платных, ни разу не видел, чтобы в архиве были разные версии файлов, например, для операционных систем.
У него эти сабсеты предопределены.
Да, предопределены, но так безопаснее. Крутить сабсеты руками – да, можно сэкономить несколько килобайт, но очень большая вероятность что-то недоучесть. Рядовой разработчик, не имеющий экспертизы в этом узком вопросе, накосячит почти наверняка.
ни разу не видел, чтобы в архиве были разные версии файлов, например, для операционных систем.
При скачивании такого и не бывает. Дать пользователю стопиццот версий – это только запутать его. В случае Гугла это работает, потому что всё упрятано под капот: они могут в реальном времени определить ось/браузер посетителя и отдать ему наилучшую версию. Самостоятельно такое реализовывать очень хлопотно.
Ссылку на источник навскидку не подскажу, очень давно читал у них где-то в блоге.
И я не уверен, что сейчас это актуально. Первые годы существования Хрома было очень заметно, что он рендерит шрифты иначе. Но потом разница сгладилась, то ли сам бразуер допилили, то ли новые версии винды влияют, то ли всё вместе. Поэтому в теории они могли дропнуть эту фичу.
Рядовой разработчик, не имеющий экспертизы в этом узком вопросе, накосячит почти наверняка.
Именно для этого в своём интерфейсе мы прям перечислили все символы. Например, для русского языка это 118 символов. Чтобы управлять набором символов достаточно просто отредактировать 1 поле формы.
Я сейчас имею в виду не техническую реализацию, а само перечисление всех необходимых символов. В реальности это сложнее, чем кажется, потому что языковые ареалы часто пересекаются, и может пригодиться немыслимое (немыслимое – в картине мира разраба, сидящего в условной Твери).
Вот даже ваш пример с русским языком очень скользкий. Формально как будто верно, но на практике придет на ваш русскоязычный сайт беларус и спросит – а где моя У с краткой, как мне отзыв на вашу косметику написать? Или украинец, или татарин, или казах.
Просто при генерации файла перечислите нужный алфавит. Сервис для каждого файла составит параметр `unicode-range`. Если на странице присутствуют символы, перечисленные в `unicode-range`, то загрузится именно этот `@font-face`. Вот как этот выглядит для русского языка и всех знаков препинания.
@font-face {
font-family: 'roboto-regular';
font-style: normal;
font-weight: 400;
src: url('roboto-regular-russian.woff2') format('woff2'),
url('roboto-regular-russian.woff') format('woff'),
url('roboto-regular-russian.ttf') format('truetype');
unicode-range: U+21-23,U+25-40,U+5B-5F,U+7B-7E,U+AB,U+BB,U+401,U+410-44F,U+451,U+2013,U+2014,U+2018,U+2019,U+201C-201E,U+2026,U+20BD;
}
Для максимального ускорения загрузки шрифтов
... надо просто не загружать шрифтов. "Джентльменский набор" шрифтов есть у каждого пользователя в его операционной системе.
Идеальный вариант - чтобы производители операционных систем, добавили все популярные, бесплатные шрифты в свои дистрибутивы. Прям взять весь google fonts и добавить в каждую операционную систему.
Ну или можно попросить производителей браузеров сделать это.
Вообще, нужна какая-нибудь организация, объединяющая разработчиков сайтов, чтобы такие прикладные инициативы продвигать. Существующие организации вроде w3c занимаются больше стандартизацией.
Для этого случая в ваших рекомендация по @font-face следовало бы сначала прописывать local() и только потом всякие там woff2/woff и т.п. Потому что сейчас ваша рекомендация будет игнорировать локально установленный шрифт и заставит браузер его скачивать.
Идея хорошая, но популярные веб шрифты редко бывают установлены в ОС. Пожалуй только дизайнеры устанавливают себе все шрифты. То есть, покрытие будет меньше 0.2%, а заморочек с указанием правильного названия шрифта много.
Я уже несколько лет рублю шрифты банерорезкой. Не чувствую при этом никакого дискомфорта. Arial, Verdana и прочий "джентельменский набор" покрывают все потребности.
Шрифты для сайтов нельзя брать из стандартных наборов так как наборы шрифтов у разных ОС не совпадают. То есть, нет одного шрифта, чтобы он был по умолчанию установлен и на виндовс, и на линукс и и на андройд. Поэтому директива local() не применима.
Вы хотите сказать, что банальная Verdana или Serif - есть не везде?
В идеале нужно использовать только 2 шрифта: обычный и жирный. Это полезно не только с точки зрения быстроты загрузки страницы, но и с точки зрения дизайна.
Ну, замечу, что именно шрифтов (font-family) в хорошей типографической верстке рекомендуется два - один для текста, другой для заголовков. Один с засечками, другой - без. Ну и толщина у каждого по надобности.
Если использовать кэш сервис воркеров, можно и больше шрифтов иметь - будет красивая (в меру, конечно) страница, а время загрузки шрифтов после второго захода - мгновенное. Оптимизация через локальное кэширование SW - самая эффективная. Намного эффективней вытаскиванием глифов.
Ну, замечу, что именно шрифтов (font-family) в хорошей типографической верстке рекомендуется два - один для текста, другой для заголовков.
Верно. Я это и имел ввиду, что жирный шрифт для заголовков, а обычный для текста. Вы получше сформулировали.
Ещё хочется обратить внимание на такую вещь: для веб дизайна шрифты с засечками по сути не нужны. Шрифт с засечками нужен для того, чтобы при чтение не путать строку. Вы наверняка замечали, как при чтении книги легко потерять строку и начать читать не следующую строку, а эту же или через одну. В книгах применяют шрифты с засечками, чтобы читатель реже терял строку. В веб дизайне это проблема решается увеличением междустрочного интервала (интерлиньяж). В книге увеличить междустрочный интервал нельзя, так как тогда на странице будет помещаться меньше текста и возрастут затраты на бумагу.
При этом шрифты с засечками замедляют скорость чтения на 10-30%. Переводя на язык веба это означает, что пользователь будет медленней изучать содержимое страницы. Значит за отведённое время посмотрит меньше товаров, прочитает меньше статей/новостей.
Вот и получается, что в веб дизайне и дизайне мобильных приложений шрифты с засечками если и используются, то носят скорее декоративную функцию.
С одной стороны оптимизированное лучше, чем не оптимизированное. С другой - такая оптимизация походит на суету на ровном месте, вдобавок можно на этом же месте получить проблем.
Если сравнивать выигрыш с объемом голой страницы, то вроде как он есть. Но я вот слабо представляю юзера, который будет интерактивничать с макетом, где не видны картинки. Если же ждать картинок, то шрифты покажутся сущими копейками.
Не стоит овчинка выделки
С другой - такая оптимизация походит на суету на ровном месте
Добавление шрифтов - работа всего на пол часика - часик. И можно выиграть от 0.1 до 0.2 секунд при загрузке страницы. Что крайне приятно.
Если сравнивать выигрыш с объемом голой страницы, то вроде как он есть. Но я вот слабо представляю юзера, который будет интерактивничать с макетом, где не видны картинки.
На компьютере с быстрым интернетом, пользователь действительно предпочтёт подождать ещё 0.2-0.4 секунды пока не загрузятся картинки. Но, если интернет медленный, как например на мобильных устройствах, где до появления картинок может иногда пройти 3-5 секунды, то пользователь старается себя чем-то занять в это время. Например начинает читать названия товаров, изучать и сравнивать цены, может даже сразу начать фильтровать товары.
Учитывая, что пользователь принимает решение о том, остаться на странице или уйти за 15 секунд, то за счёт оптимизации шрифтов вы выигрываете дополнительно 1 секунду. То есть, логика такая: после клика по ссылке в поисковой системе пользователь за 15 секунд решает, останется ли он на сайте. Если страница грузится 5 секунд, то на изучение контента остаётся 10 секунд. Но если страница грузится за 4 секунды, то пользователь поизучает ассортимент сайта уже 11 секунд. А там, глядишь, глаз за что-то зацепится, и он останется на сайте.
А почему вы сравниваете с ttf от fonts.google.com, а не woff2 оттуда же, которые заботливо разбиты на unicode-range (см. например https://fonts.googleapis.com/css2?family=Roboto)? Не потому ли, что в этом случае разницы практически не будет (для Roboto: 15.4Кб латиница, 9.4Кб кириллица, и т.д.)?
Для скачивания доступен именно крупный файл в формате ttf со всеми глифами. Да и большинство платных шрифтов именно в таком формате в архиве лежат. То есть, мы прям скачали с fonts.google.com архив со шрифтом, взяли и загрузили в сервис файл "Roboto-Regular.ttf", а затем оптимизировали. То есть, в этом абзаце говориться именно о том, что скачиваемые шрифты обязательны к оптимизации.
Чуть ниже, есть вторая таблица, где сравниваются оптимизированные шрифты с CDN сервисом гугла. И выигрыш опять же в пользу первых.
Не потому ли, что в этом случае разницы практически не будет (для Roboto: 15.4Кб латиница, 9.4Кб кириллица, и т.д.)?
Можно добавить сноску/оговорку/лирическое отступление, чтобы акцентировать внимание читателя, что мы именно про скачиваемые шрифты говорим. Это сделает текст честнее, но раздует объём статьи, уведёт внимание читателя от основной темы и снизит мотивацию специалиста заниматься проблемой оптимизации шрифтов. К тому же, вычитывание статьи и исправление таких деталей может занять столько же времени, сколько написание самой статьи. Лучше потратить это время и силы на написание следующей статьи.
У Google Fonts есть API для тонкой настройки. Например, можно указать url-параметр subset
с набором глифов, характерных для того или иного языка. Или можно указать url-параметр text
с нужными глифами. Если взять набор символов из вашего сервиса для русского и английского языка, то в Google Fonts также получим один файл размером 8Kb. Причем именно один формат, который сервис определил сам на основе HTTP-заголовков, а не целую россыпь из устаревших otf, ttf, woff, svg, как уже и отметил @dom1n1k.
У Google Fonts, вообщем-то, только один недостаток в плане сетевой производительности – CSS запрашиваются с одного домена, а сами шрифты – с другого домена.
Интересное API, не знал о нём. Но, видимо они его немного недоработали. Я нашёл баг.
Вот файл для русскоязычных символов генерируемым гуглом. В нём указан вот такой woff2 файл. Любопытно, что оптимизированный под определённый набор символов файл гугл шрифта весит 11.4КБ, а аналогичный в нашем сервисе весит 15.1КБ.
Я стал разбираться, как так, и проанализировал оба файла в https://fontdrop.info/. Оказалось, что гугл просто удалил часть запрашиваемых глифов из своего файла напрмиер ₽"#%&'()*+,-./ и т.д. Но при этом добавил ӹ, Ӂ, Ӑ и т.д.
Я было подумал, что это из-за хеша в URL. И попробовал вот такую ссылку, убрав только хеш символ. И мне выдали вот такой файл шрифта весом 4.6КБ, который содержит только буквы кириллицы. Во общем, как-то странно это функция работает, проще и надёжней сгенерировать шрифты самому. К тому же, 99.9% пользователей не знает о существовании этой фичи и поэтому наверняка её не используют. То есть, сложность использование этой фичи и тот факт, что о ней крайне сложно узнать - серьёзнейшие отсекающие факторы. Сгенерировать и загрузить шрифт, используя наш сервис, может любой джун. А вот с гуглом, как вы убедились выше, надо с бубном плясать даже опытному специалисту.
Что касается предоставления разных форматов в зависимости от браузера, то тут тоже баг есть. Открывал шрифт Roboto Mono с UserAgent современного бразера и с UserAgent Internet Expore 10. Действительно, во втором случае мне предоставили формат файлов woff вместо woff2. Один нюанс, что там был только один набор символов, вместо 6. Файл woff для IE 10 весит 15.3КБ и в нём отсутствует кириллица.
В целом, я отношусь к гуглу, как к создателям бесплатных, качественных плагинов для WordPress. Да, ребята молодцы, старались, сделали приятную вещь, но чтобы соответствовать стандартам отрасли надо допиливать задачу самому.
В URL есть hash, который обрезает часть символов
Верно. Но остаётся следующий вопрос, зачем гугл добавляет непонятные глифы "ӹ, Ӂ, Ӑ" в файл по такому url с хешем? Вот версия ссылки с убранным текстом после хеша. Откуда там символы Ў, Ӭ и т.д.?
Так же не понятно, почему при удалении символа хеша генерируется файл на 4.6КБ где остаются буквально несколько символов? Вот идетичная ссылка с удалённым хеш символом. Куда 150+ символов подевалось? Скорее всего дело в том, что я как-то не правильно кодирую символы в параметре URL. То есть, тут требуется поплясать пол денёчка-денёчек с бубном, чтобы разобраться.
И даже если я сгенерирую верный URL, то гугл CDN всё равно проигрывает по ряду факторов:
Как вы подтверждали, потребуется дополнительное время на установление 2 соединений с CDN серверами гугла.
Запросов будет на 1 больше. Так как CSS код подключения шрифта всегда добавляется в сквозной CSS файл сайта вида common.css, main.css или template.css. А при использовании гугла потребуется загружать код CSS подключения шрифтов отдельным запросом.
Тонкая настройка у гугла попросту сложная. Выполнимая, но сложная. Заказчик/работодатель врят ли заплатят за 8-12 человеко часов за настройку шрифтов от гугл. Скажут, есть задачи поважнее. А вот заплатить за часик работы, чтобы оптимизировать шрифты в нашем сервисе - легко. То есть, конечная стоимость внедрения при использовании технологий от гугла - кошмарная.
Гугл сервис явно имеет баги и работает нестабильно. Примеры я предоставил.
"Также рекомендую проверить ваш сайт сервисом Быстрый Апгрейд Сайта, который проверит соблюдение вышеописанных рекомендаций." - а что за сервис, там ссылка не работает?)
Оптимизируем шрифты и ускоряем сайт на 5-12%