Пользователь
0,0
рейтинг
23 ноября 2012 в 14:49

Дизайн → Производительность веб-шрифтов



Применение веб-шрифтов становится все популярнее: согласно HTTP Archive, за последний год число сайтов, использующих дополнительные шрифты, выросло вдвое — с 6 до 12%.

Слабым местом веб-шрифтов является производительность, однако ситуация постепенно меняется в лучшую сторону: появляются более совершенные методы сжатия, улучшается поддержка браузерами, unicode, отдельные наборы шрифтов и т.д.

Оптимизация


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

  • WOFF (Web Open Font Format): открытый сжатый формат шрифта OpenType или TrueType, поддерживающий дополнительные метаданные.
  • TTF: всем знакомый, старый добрый TrueType.
  • EOT (Embedded OpenType): компактный формат OpenType-шрифтов.
  • SVG (Scalable Vector Graphics): формат векторной графики (об это я уже писал).


Но ни один из них не обеспечивает кроссбраузерность (проверить поддержку можно на сайте caniuse.com: woffttfeotsvg), поэтому желательно использовать несколько форматов одновременно. И тут мы сталкиваемся с проблемой производительности: файл шрифта сам по себе достаточно массивен, к примеру шрифт Arial, поддерживающий все языки, весит 22 мегабайта! Конечно на обычных страницах нет смысла подключать сразу все символы набора, поэтому необходим инструмент, позволяющий использовать только часть шрифта (например только кириллицу).

К примеру шрифт Open Sans — один из самых популярных Google Web Fonts, включающий все языки, весит 217 килобайт, но размер можно уменьшить, если использовать только один набор — latin. тогда размер уменьшится до 36 килобайт:



Вот, как можно подключить только часть шрифта (latin):

<link href="http://fonts.googleapis.com/css?family=Open+Sans&subset=latin" rel="stylesheet" />


Размер файла может быть снижен, если удалить дополнительные метаданные Font-хинтинга для браузеров, где эта технология не поддерживается. Font-hinting — часть процесса растеризации шрифта, используется для улучшения отображения текста на странице.

Улучшенные алгоритмы сжатия позволяют сократить размер файла на 15%, а ожидаемый в скором будущем формат WOFF 2.0 позволить сжимать на 30% лучше.

Для подключения только части символов («H», «e», «l» и «o») можно использовать следующий код:

<link href="http://fonts.googleapis.com/css?family=Inconsolata&text=Hello" rel="stylesheet" />


Использование


Все шрифты из Google Web Fonts являются открытыми, что позволяет успешно использовать межсайтовое кэширование. Например упомянутый выше Open Sans используется на более чем миллионе сайтов, а это значит, что для увеличения производительности можно кэшировать шрифт в браузере пользователя при посещении предыдущих сайтов с данным шрифтом.

Вот как это работает:



CSS-стили, используемые в сервисе Google Web Fonts являются динамическими: они автоматически определяют подходящий формат для конкретного пользователя и его браузера. CSS-стили кэшируются на 24 часа. Внутри стиля находится ссылка на сам файл шрифта. Кэш самого шрифта хранится целый год! Учитывая популярность веб-шрифтов, очевидно, что в кэше уже есть копия того же Open Sans.

Существует также полезный инструмент — Javascript Font Loader от Google, позволяющий отображать процесс загрузки веб-шрифтов. Использовать достаточно просто:

h1 {
    visibility: hidden;
}
.wf-active h1 {
    visibility: visible;
}


А javasript обрабатывает действия:

WebFontConfig = {
    google: {
        families: [ 'Tangerine', 'Cantarell' ] // Google example
    },
    typekit: {
        id: 'myKitId' // Typekit example
    },
    loading: function() {
        // JavaScript to execute when fonts start loading
    },
    active: function() {
        // JavaScript to execute when fonts become active
    },
    inactive: function() {
        // JavaScript to execute when fonts become inactive (time out)
    }
};


Документация Loader'а

В заключение, небольшая сводная таблица скорости загрузки одного и того же шрифта (Open Sans) при использовании различных сервисов и браузеров (числа в мс):



Вывод


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

Использованные материалы:
@grokru
карма
407,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Дизайн

Комментарии (32)

  • +6
    >> Слабым местом веб-шрифтов является производительность
    Особенно если их «назначают» не заголовкам на каком-нибудь сайте-портфолио, а всем текстам и на большом «текстовом» проекте. Пример неудачного использования — недавний редизайн «Газеты.ру»: в свежезапущенном FF на не самых слабых машинах (i3-2120 и Phenom-1055T) текст появляется только через секунду полторы.
    • 0
      На SmashingMagazine такое было раньше (?)

      На телефоне невозможно было что-то почитать, пока шрифт не загрузится
  • +1
    Мне нравится использовать специальные шрифты с иконками внутри. Тогда они векторные и не зависят от разрешения экрана.
    • +1
      Готовые или сами делаете?
      • 0
        Вот, например.
        • 0
          Вот используете вы пять значков из сотни: в чём смысл такого шрифта? Он ничего не экономит.
          • 0
            Для вашего случая – не экономит, но этот вариант удобен для разросшихся проектов с множеством интерфейсных мелочей.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Сделал один сайт с использованием шрифтов Google. Использовал два шрифта в четырех начертаниях каждый.

    Объем шрифтов получился почти 600 КиБ — больше половины объема всей страницы. :(

    Это нормально?
    • +1
      > Использовал два шрифта в четырех начертаниях каждый.

      Вы сами ответили на свой вопрос. Нужно быть аскетичнее.
      • +1
        Всего два шрифта же. Один для основного текста, другой для заголовков. У основного текста я не могу отказаться от начертаний, у заголовков, скажем, могу оставить два из четырех. Меньше никак.

        Это все равно получается порядка 450 КиБ!
        • +1
          А после gzip level 9?
          • +1
            Шрифты отдаются Гуглом. Думаю, компрессия там максимальная.
            • +1
              В таком случае речь о распакованном или упакованном варианте?
              Может быть ссылку для проверки?
            • +1
              Судя по ответу сервера и тому, что файлы ужимаются GZIP примерно на 20%, Гугл отдаёт их не сжатыми. Ну и степень сжатия я оценил — около 20%
              • +1
                Вообще, если внимательно посмотреть, то гугл отдает каждому браузеру свой набор.
                В ИЕ вы не увидите формата .woff, также, как в хроме нет .eot.
                Про gzip, вы что имеете ввиду? Общее сжатие css? Потому, как woff и eot и так уже сжатые шрифты(в статье, кстати написано), а ttf.gz использовать почти отпала необходимость, т.к. большинство современных браузеров поддерживают .woff.
                На самом деле, такой подход к раздаче наборов гуглом можно объяснить лишь экономией на css коде, т.к. в любом случае хром, встретив в css шрифт формата .eot не сделает на него запрос на сервер.
                • 0
                  Я не про CSS. .woff и другие форматы ведь тоже можно сжать перед выдачей. Даже если у формата есть своё внутреннее сжатие, то оно кажется недостаточно хорошим. Потому как получаемый файл сжимается примерно на 20%.
              • +1
                Прошу прощения за мою неграмотность, похоже, Firebug показывает размеры компонентов страницы без учета сжатия при передаче.

                Однако я попробовал сжать на компе 218 КиБ файл алгоритмом gzip со степенью сжатия ultra, получилось 182 КиБ. То есть максимальная степень сжатия для этого файла — порядка 17% («примерно на 20%»?).
                • +1
                  Скажите, какие шрифты вы используете? Ну ради интереса.
                  • 0
                    PT Sans и PT Serif
                • 0
                  Да, именно об этих примерно 20% я и говорил. woff ведь тоже можно сжать перед выдачей. Даже если у формата есть своё внутреннее сжатие, то оно кажется недостаточно хорошим.
                  • 0
                    20% погоды не делает. Факт в том, что при использовании вэб-шрифтов размер страницы увеличивается вдвое.
                    • 0
                      Они присоединяются отдельным ресурсом, как и любая картинка. На многих страницах, графики огромное кол-во, просто считайте это за одну из картинок. Тем более, шрифт может быть важнее.
                      • 0
                        Ну… Представьте, что вы в какой-нибудь глуши мучительно пытаетесь открыть сайт с мобильника. И Webkit вообще не показывает текст сайта, пока не прогрузятся 600 КиБ шрифтов!

                        Это при том, что во всем, кроме объема страницы, сайт для мобильника адаптирован.
                        • 0
                          Прошу простить мне возможно глупый вопрос, но разве никак нельзя сделать так, чтобы часть кода ответственная за подгрузку шрифтов срабатывала после того, как загрузится контент страницы?
                          • 0
                            Можно.

                            Проблема в том, что объем страницы при этом меньше не станет.

                            А Webkit-браузеры (а это все мобильники!) не показывают текст вообще, пока не загрузится файл шрифтов.

                            Google выпустила JS-приблуду, которая решает эту проблему. К сожалению, не сумел заставить ее работать на моем сайте. :(
                    • 0
                      Может стоит сделать поправку на то, что это происходит однократно? Ведь если шрифт кешируется, как указано в статье, то любая последующая загрузка страницы ресурса уже будет обращаться к кешу и съедать траффика на те самые 450-600кб меньше…
                      • +1
                        Мобильники кэшируэт совсем не так хорошо. на том же iPad кнопка обновить приводит к временному исчезновению текста со страниц.

                        Да и однократный подарочек в 600 КиБ — для многих большая проблема.
  • +2
    Меня вот немного смущают возможные артефакты, например www.fontspring.com/blog/smoother-web-font-rendering-chrome

    Сам столкнулся с чем-то похожим, на некоторых компьютера с Win7 + Chrome шрифт становится настолько некрасивым, что не хочется пользоваться сайтом. Причем грузятся шрифты с typekit'a и поменять порядок SVG / WOFF так просто не выйдет.

    Проблема еще в том, что не получается точно установить, какие настройки влияют на некрасивый рендер.
  • +1
    Данная статья освещает размер файла шрифтов и скорость загрузки шрифта. А кто знает сколько оперативной памяти израсходует браузер дополнительно чтобы использовать шрифт для сайта? Помимо размера самого файла шрифтов если этот шрифт не установлен в ОС. И будет ли использоваться браузером оперативная память дополнительно если эти шрифты уже установлены в ОС?
  • +2
    По хорошему они должны кешироваться. Другой вопрос, что для их отрисовки уже работает браузер, а как переложить это на функции ОС и видеокарты например?
    • +2
      IE, начиная с 9й версии, рендерит шрифты через DirectX, и там уже сам графический движок решает, лучше ли использовать CPU или GPU (интегрированный ли дискретный). Думаю, для Mac и Linux тоже есть хорошее решение. Остаются устройства, но может быть, OpenGL ES тоже что-то похожее умеет.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.