Разврат и декаданс text-rendering: optimizeLegibility

Слушайте, я возлюбил типографику как ближнего своего, может быть, даже немного больше. Когда появилось CSS-свойство, которое обещало решить задачи, связанные с лигатурами и аккуратно рассчитанным кернингом, не каким-то дешёвым подобием — настоящим кернингом — я сразу же на него набросился. Я добавил text-rendering: optimizeLegibility в заголовки, в тексты статей, в ссылки. Даже изображениям добавил — просто на всякий случай, например, если лигатура окажется на фоне фотографии, размытая, как неприлично довольное привидение.

Нет, правда — это были мои золотые деньки в веб-типографике. Эра, напичканная лигатурами fi, fft и покорившей моё сердце st. Буквы слова «нож» подгонялись друг к другу так плотно, что между ними нельзя было бы протиснуть и лезвия этого ножа, и я отчаянно искал повод написать AVAST в верхнем регистре, как будто чтобы позлить слово с самым жутким кернингом из мне известных.

Скриншот

Разница между text-rendering: optimizeLegibility (слева) и text-rendering: auto (справа) незначительна, даже если у вас изрядно наметан глаз.

Однако подсознательно я понимал, что мои новообретённые крылья сделаны из воска. Вся эта типографская сила не дается бесплатно: text-rendering: optimizeLegibility — медленное свойство, и под «медленное» я подразумеваю, что оно способно «положить» всю страницу, начиная от времени первоначального рендеринга и заканчивая перерисовками. Более того, оно ещё и глючное: в частности, в Android серьезные проблемы при рендеринге страниц, на которых активно используется свойство optimizeLegibility, особенно в его старых версиях, которые, к сожалению, всё ещё широко распространены.

Но глюки не играют большой роли, а вот проблемы со скоростью — играют. При расчёте кернинга для больших объёмов текста могут возникать тысячи мелких вычислительных процессов, и это создает серьёзную нагрузку на процессор. В современном десктопном браузере, например, в Chrome, ну, всё не очень хорошо, а на мобильных с их ограниченными ресурсами это становится настоящим кошмаром, особенно когда в дело вступает @font-face. При использовании свойства optimizeLegibility вся работа происходит ещё до того, как шрифт вообще можно отрендерить, что выливается в чудовищно длительную задержку при отрисовке текста или затягивающееся отображение текста шрифтом, предназначенным для мягкой деградации, в зависимости от способа, которым подгружаются шрифты.

Иллюстрация

Таймлайн отображения страницы при медленном соединении, созданный с помощью WebPageTest.org. Единственное отличие между страницами — p { text-rendering: optimizeLegibility; } и p { text-rendering: optimizeSpeed; }

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

На самом деле, даже значение по умолчанию — text-rendering: auto — не оставит нас совсем уж без лигатур и с конским расстоянием между буквами. В Firefox (и, возможно, в скором времени WebKit с Blink), optimizeLegibility включается для любого шрифта c размером кегля font-size: 20px и более. На таких крупных надписях эффект намного заметнее, и пара коротких строк текста не так уж сильно повредит производительности, чтобы это можно было ощутить.

Конечно, если мы хотим полностью отключить это свойство, всегда есть значение text-rendering: optimizeSpeed, которое сработает вне зависимости от кегля шрифта и полностью исключит любую нагрузку, которая связана с использованием text-rendering. Я почти всегда предпочитаю оставлять значение по умолчанию text-rendering: auto, но если вы работаете со страницей, на которой присутствует значительный объем текста со значением font-size больше 20px, возможно, стоит попробовать text-rendering: optimizeSpeed.