Оптимизация изображений из коробки
Для интересующихся: изображения в 11ty сжимает библиотека sharp.
Встроенный в 11ty плагин оптимизации хорош. Он автоматом проходится по всем изображениям на сайте и оптимизирует их для быстрой загрузки, не уменьшая размеров в пикселях и не ухудшая качество.
Представим, что я приложил в эту заметку скан первой страницы газеты The Evening Star от дня сброса атомной бомбы на Нагасаки (оригинал). Я сказал «представим», потому что этот PNG-файл с разрешением 5500×8000 пикселей весит 29 Мб и если я действительно его приложу, вес исходников Триремы раздует где-то на треть.
Так вот, в этой гипотетической ситуации вы, как читатель, скачаете не 29 Мб, а от силы 7, если даже не 3. Качество не упадёт, размеры изображения останутся теми же — а скачается всё в 4–10 раз быстрее.
Сравните оригинал и оптимизированное изображение сами на примере фрагмента статьи. Я выбрал газету для иллюстрации потому, что при компрессии первыми искажаются мелкие детали.
Напомню, что если вы захотите уменьшить размеры изображения, вы можете сделать это, не выходя из заметочника: строке с изображением ! [alt text] (image.jpеg) добавьте |желанная_ширина_в_пикселях справа от альт-текста — должно получиться ![alt text|500] или ![|500]. Вы поймёте, что всё сделали правильно, когда Обсидиан уменьшит размер картинки в заметке.
Но есть одна загвоздка.
Пиксели в вебе ≠ пиксели изображения
Совет на сайте Бюро: «Почему ширина смартфонов при веб-разработке 320 пикселей?»
Кажется, что если указать ![alt text|500] — Обсидиан отрендерит тебе картинку шириной в 500 экранных пикселей шириной? Фигушки! Обсидиан рендерит заметки через ХТМЛ, а пиксели в вебе отвязаны от их физических представителей. Это логично — иначе бы текст с кеглем 16 пикселей был бы абсолютно нечитаем на 2K экранах смартфонов, где каждый физический пиксель раз в 9 меньше пикселя на экране компьютера. Не менее логично, что такие пиксели кличут логическими (или виртуальными).
Соотношение физических пикселей к логическим называют Device Pixel Ratio и девайсов, где DPR равен единице, сейчас всё меньше. Из этого вытекает следующее: если вам нужен элемент шириной в 100 логических пикселей с чётким изображением на фоне, вам почти никогда не хватит изображения шириной в 100 физических пикселей — нужно генерировать набор изображений под разные DPR, а браузер пользователя уже сам скачает нужный файл исходя из плотности пикселей.
В коде это так:
<img src="image.jpg" srcset="image-1x.jpg 1x, image-2x.jpg 2x, image-3x.jpg 3x">
В 11ty пока нет опции «сгенерируй набор изображений под разные DPR», только опция «сгенерируй из этого файла набор изображений шириной в X, Y, Z пикселей и одно с изначальной шириной в таких-то форматах». Более того, ширина и высота изображения в физических пикселях прописывается в размеры его ХТМЛ-элемента, где работают уже логические пиксели. Результат — мутная картинка, занимающая больше пикселей, чем ей нужно.
Я не придумал ничего лучше, чем пройтись по всем сгенерированным ХТМЛ-файлам и уменьшить изначальную высоту и ширину для <img> тегов в два раза — так картинки будут очень хорошо выглядеть на устройствах с DPR в окрестностях числа 2, а таких устройств — большинство.
Это всё ещё костыль, но это лучше, чем мыльные картинки. Придумаю, что новое — дам вам знать.