Pull to refresh

Comments 32

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

На телефоне невозможно было что-то почитать, пока шрифт не загрузится
Мне нравится использовать специальные шрифты с иконками внутри. Тогда они векторные и не зависят от разрешения экрана.
UFO just landed and posted this here
UFO just landed and posted this here
Для вашего случая – не экономит, но этот вариант удобен для разросшихся проектов с множеством интерфейсных мелочей.
UFO just landed and posted this here
Сделал один сайт с использованием шрифтов Google. Использовал два шрифта в четырех начертаниях каждый.

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

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

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

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

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

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

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

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

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

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

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

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

Articles