В первой части автор упомянул проблемы, связанные с созданием и размещением отзывчивых изображений, а также привел пример, в котором использовано свойство srcset, позволяющее помочь браузеру подобрать оптимальный источник, что значительно повышает скорость сайта. Однако при таком подходе существует одна проблема: для подбора подходящего исходника необходимо знать размер макета изображения. А мы не можем попросить браузер отложить выбор, пока не загрузятся и не интерпретируются HTML, CSS и JavaScript страницы. Поэтому нам нужно дать браузеру возможность оценить ширину отображения картинки с помощью еще одного нового атрибута: sizes.
Как у меня получилось скрыть от вас эту неприятную правду до этого момента? Детальные изображения на нашей странице-примере представляют собой особый случай. Они занимают всю ширину окна -100vw—которая, как случайно оказалось, по умолчанию имеет значение sizes. Наши изображения целых одеял, однако, подогнаны под ширину абзаца и часто занимают существенно меньшую площадь. Это помогает нам сообщить браузеру непосредственную ширину с помощью атрибута sizes.
sizes принимает значения длины CSS. Поэтому:
sizes="100px"
… он говорит браузеру: это изображение будет отображаться с фиксированной шириной 100px.
Наш пример более сложный. Так как изображения одеял стилизованы с помощью простого правила width: 100%, значения, которые его размещают, имеют максимальную ширину (max-width) 33em. К счастью, sizes позволяет нам делать две вещи:
1. Он позволяет задавать несколько значений длины в списке, разделенном запятыми.
2. Он позволяет нам подключать к значениям длины условия среды.
Например, так:
sizes="(min-width: 33em) 33em, 100vw"
Это означает, что если окно шире, чем 33em? Тогда это изображение будет иметь ширину 33em. В противном случае, оно будет 100vw.
Это уже ближе к тому, что нам нужно, но не совсем то. Относительная сущность em делает наш пример коварным. Размер шрифта (font-size) тела нашей страницы имеет значение 1.25em, поэтому «1em» в отношении CSS нашей фигуры будет равен 1,25 х стандартного размера шрифта браузера. В рамках обработчика (а потому и в рамках атрибута sizes), em всегда равно стандартному размеру шрифта. То есть, уместно умножение на 1,25: 1,25 х 33 = 41,25.
sizes="(min-width: 41.25em) 41.25em, 100vw"
Таким образом довольно прилично улавливается ширина наших одеял и, честно говоря, это хорошо. Это на 100% подходит для атрибута sizes, чтобы он предоставлял браузеру приблизительный расчет ширины макета изображения; зачастую, жертвование небольшим количеством точности в пользу увеличения читабельности и технологичности – это правильный выбор. С другой стороны, давайте пойдем дальше и сделаем наш пример более точным путем разложения его на множители в em отступов с обеих сторон фигуры: 2 стороны х 1,25 условий среды em каждой = 2,5 em учитываемого отступа.
<img
srcset="quilt_3/large.jpg 1240w,
quilt_3/medium.jpg 620w,
quilt_3/small.jpg 310w"
sizes="(min-width: 41.25em) 38.75em,
calc(100vw - 2.5em)"
src="quilt_3/medium.jpg"
alt="A crazy quilt whose irregular fabric scraps are fit into a lattice of diamonds." />
Давайте посмотрим, что мы здесь сделали. Мы предоставили браузеру крупную обертку и небольшие версии нашего изображения с помощью srcset, и указали их ширину в пикселях с помощью параметра w. А также мы сообщили браузеру, сколько пространства будут занимать изображения, с помощью sizes.
Если бы это был простой пример, мы бы задали браузеру простую длину CSS в виде sizes=«100px» или sizes=«50vw». Но нам так не повезло. Нам пришлось задать браузеру два значения длины CSS и указать, что первую длину необходимо использовать только когда имеет место определенное условие.
К счастью, вся эта работа была не напрасна. С помощью srcset и sizes мы дали браузеру все, что ему нужно для выбора исходника. Когда он знает ширину исходников в пикселях и ширину макета изображения, браузер рассчитывает соотношение ширины «исходник-макет» для каждого исходника. Поэтому, предположим, что sizes равно 620 пикселей. Исходник шириной 620w будет равен 1х пикселей изображения. Исходник шириной 1240w будет равен 2х. 310w? 0.5x. Браузер рассчитывает эти соотношения, после чего выбирает, который из исходников ему нравится больше.
Стоит отметить, что условия позволяют устанавливать соотношения непосредственно, и что исходники без характеристики получают стандартное соотношение 1x, позволяя вам описывать разметку следующим образом:
<img src="standard.jpg" srcset="retina.jpg 2x, super-retina.jpg 3x" />
Это неплохой компактный способ для создания рисунков с высоким разрешением. Но! Он работает только для изображений с фиксированной шириной. Все изображения на нашей странице лоскутных одеял «жидкие», поэтому это последний раз, когда мы упоминаем характеристику x.
Измерение
Теперь, когда мы переписали нашу страницу про лоскутные одеяла с помощью srcset и sizes, что мы получили с точки зрения производительности?
Вес нашей страницы теперь (наконец-то!) отвечает условиям загрузки. Он изменяется, поэтому мы не можем представить его одним числом. Я перезагружал страницу кучу раз в Chrome и измерял ее вес на большом количестве окон разной ширины:
Ровная серая линия вверху представляет вес исходного варианта в размере 3,5 Мб. Толстая (1x) и тонкая (2x) зеленые линии представляют вес нашей страницы, обновленной с помощью srcset и size в окнах с различной шириной от 320 до 1280 пикселей.
На 2х с шириной 320 пикселей мы сокращаем вес нашей страницы на две трети – раньше страница весила 3,5 Мб; теперь мы отправляем всего 1,1 Мб. На 1х при ширине 320 пикселей, наша страница весит меньше одной десятой своего изначально размера: 306 Кб.
С этой точки, размеры в байтах постепенно увеличиваются при загрузке более крупных исходников, заполняющих более крупные окна. На устройствах 2х мы сильно перескакиваем на окно шириной около 350 пикселей и возвращаемся на вес статус-кво после 480 пикселей. На 1х разница ощутима – мы отсекаем от 70 до 80 процентов изначального веса страницы, пока не пересекаем границу в 960 пикселей. Здесь мы упираемся в страницу, которая все равно на 40% меньше, чем изначальное значение.
Такие сокращения -40%, 70%, 90% — должны остановить вас. Мы урезаем около двух с половиной мегабайтов при каждой загрузке на iPhone с экраном Retina. Посчитайте все это в миллисекундах или умножьте на тысячи просмотров страницы, и вы поймете, к чему вся эта суета.
Существует еще один подход к решению проблемы отзывчивых изображений, о котором, мы расскажем в третьей части.
Автор: Irina_Ua
