Адаптивные изображения: как браузер выбирает файл и почему sizes не заменяет CSS
Разбор существующих механизмов HTML: варианты разрешения, кадрирование, доступность и загрузка первого экрана. Это руководство по устройству платформы, а не сообщение о новом формате или выпуске браузера.
У изображения есть три независимых размера
Фотография в каталоге имеет собственные пиксельные размеры, занимает определённую область в CSS и отображается на экране с некоторой плотностью физических пикселей. Эти величины связаны, но не совпадают. Например, элемент шириной в несколько сотен CSS-пикселей на плотном дисплее может использовать файл заметно шире этой области. При этом увеличение исходника не меняет автоматически ширину элемента: компоновкой продолжает управлять CSS.
HTML предоставляет браузеру описание доступных ресурсов. Автор сообщает, какие варианты существуют и какое место занимает картинка, а клиент сопоставляет это с экраном и условиями загрузки. Поэтому адаптивность не означает один обязательный файл для каждого номера модели телефона. Такой каталог быстро устаревает и не учитывает разделённые окна, масштабирование, поворот устройства и одинаковую ширину окна при разной плотности дисплея. Выбор происходит для конкретного контекста просмотра, а не для маркетингового названия устройства.
Что сообщают дескрипторы w и x
В srcset можно перечислить файлы с указанием их собственной ширины через w либо относительной плотности через x. Это два способа описать набор, их не смешивают внутри одного списка. Дескриптор ширины относится к реальному файлу: обозначение 800w не является командой растянуть изображение на восемьсот CSS-пикселей. Плотностный вариант подходит для области с известным постоянным размером, где нужны более подробные версии для плотных экранов.
При выборе на основании ширины браузеру требуется предполагаемый размер места в макете. Для этого служит sizes. Он не создаёт колонки, не задаёт max-width и не меняет расположение соседнего текста. Если CSS рисует карточку в узкой боковой панели, а sizes обещает весь экран, браузер получает неверное описание потребности. Избыточный файл может выглядеть совершенно правильно, поэтому ошибка обнаруживается по фактически загруженному ресурсу и переданным байтам, а не по отсутствию визуального дефекта.
Почему условия sizes читаются по порядку
Sizes описывает последовательность условий и соответствующих размеров области. Используется первый подходящий пункт, затем предусмотрен вариант без условия. Порядок поэтому является частью смысла записи. Условная ширина экрана и ширина изображения внутри него остаются разными значениями: карточка может занимать половину окна, одну из нескольких колонок или ограниченный центральный блок.
В актуальном HTML Standard отдельно описано sizes="auto" для лениво загружаемых изображений. В подходящем сценарии браузер использует известный размер элемента; для совместимости можно перечислить запасные значения после auto. Этот механизм связан с условиями обработки изображения и не делает произвольную запись sizes ненужной на любой странице. Атрибуты width и height также имеют другую роль: они помогают определить пропорцию и зарезервировать место, пока сам ресурс ещё не получен. Правильно выбранный файл и стабильная геометрия страницы решают разные задачи.
| Механизм | Что описывает | Чего сам не делает |
|---|---|---|
| srcset с w | Фактическую ширину доступных файлов | Не задаёт ширину элемента в макете |
| sizes | Ожидаемую ширину области изображения | Не создаёт сетку CSS |
| srcset с x | Плотностные варианты одного изображения | Не меняет композицию кадра |
| picture и source | Выбор источника по условию или формату | Не заменяют вложенный img |
| width и height | Размеры и соотношение сторон элемента | Не создают уменьшенные копии |
Источник: HTML Standard, раздел Images
Picture меняет композицию, а не только число пикселей
Когда на маленьком экране исчезает главный объект широкого кадра, уменьшение того же снимка не решает проблему. В таких случаях picture позволяет предложить отдельную композицию: например, крупный план вместо общего. Вложенные source проверяются в указанном порядке, а img остаётся элементом, который действительно отображает изображение и содержит текстовую альтернативу.
Выбор source может зависеть от media или от поддерживаемого MIME-типа. Поэтому отдельные форматы и отдельные кадры можно сочетать, но это не одна операция. Внутри выбранной композиции всё ещё может существовать несколько разрешений. CSS object-fit способен обрезать видимую область, однако не отменяет загрузку скрытой части файла. Если мобильная композиция подготовлена отдельным ресурсом, передаваемые данные действительно могут отличаться. У такого варианта должны сохраняться смысл изображения и соответствие окружающему тексту, особенно когда фотография доказывает конкретное утверждение.
Один альтернативный текст для разных вариантов
У picture нет собственного независимого alt для каждого source: текстовая альтернатива находится у img. Это делает смысловую согласованность кадров существенной частью разметки. Если в разных условиях показываются совершенно разные события или диаграммы, один текст может оказаться неверным для части посетителей. Адаптивные варианты обычно представляют один предмет с разной композицией или детализацией.
Роль изображения определяется контекстом. Декоративный фон не требует такого же описания, как график с данными или единственная подпись на кнопке. Для сложной схемы короткий alt не обязан вместить все значения: подробное объяснение может находиться рядом в обычном тексте. Видимая подпись, лицензия и альтернативное описание также выполняют разные функции. Указание фотографа не сообщает незрячему читателю, что изображено, а хорошее описание не заменяет атрибуцию автора и источника файла.
Размер файла и момент запроса влияют по-разному
Браузер может обнаружить изображение ещё до завершения разбора стилей и скриптов. Поэтому поздняя замена большого src через JavaScript иногда приводит к дополнительному запросу вместо предотвращения первого. Декларативное описание кандидатов доступно на более ранней стадии. При этом уменьшение файла меняет длительность передачи, а loading="lazy" откладывает сам запрос до приближения изображения к видимой области.
Для крупной картинки первого экрана такая отсрочка может увеличить время появления основного содержимого. Fetchpriority сообщает относительную важность ресурса, но не является гарантированной очередью загрузки и не отменяет другие решения браузера. В материале web.dev связь с LCP объясняется конкретно: если крупнейший видимый элемент является изображением, доставка подходящего ресурса может сократить его ожидание. Это не универсальный процент ускорения страницы и не оценка остальных затрат, например выполнения скриптов или ответа сервера.
Подготовка вариантов входит в издательский процесс
Srcset не создаёт уменьшенные копии. Файлы должны быть подготовлены редактором, сборкой или сервисом обработки, а адреса — существовать и отдавать соответствующий контент. Обрезка, сжатие и выбор формата имеют собственные параметры. Разные исходники могут по-разному сохранять мелкие подписи, фактуру и цвет, даже если занимают одинаковую площадь на странице.
У готового набора есть стоимость хранения и обработки; универсального обязательного количества размеров в документации нет. Важны реальные размеры областей сайта и распределение запросов. Кеш также влияет на наблюдение: повторный просмотр может использовать уже полученный крупный файл вместо нового маленького. Поэтому уменьшение окна не обязано вызывать видимую повторную загрузку. Сеть показывает выбранный ресурс и его происхождение из кеша, а макет — фактический размер изображения. Эти сведения описывают разные части одного процесса и объясняют, почему визуально одинаковые страницы могут передавать разное количество данных.
