Выберите правильный шаблон
Resolution switching (переключение по разрешению) сохраняет состав изображения и предлагает несколько ширин файла. Это обычный паттерн для фото товаров, иллюстраций в статьях и карточек. Используйте дескрипторы ширины, такие как 480w или 1200w, когда отрисованная ширина меняется с макетом. Число — это реальная ширина файла в пикселях, а не цель для телефона или CSS-команда.
Density switching (переключение по плотности) обслуживает фиксированный CSS-слот, предоставляя больше исходных пикселей для дисплея с высокой плотностью. Его дескрипторы — 1x, 1.5x или 2x; он подходит для логотипа или иконки, которая стабильно, например, 160 CSS-пикселей в ширину. Не смешивайте дескрипторы ширины и плотности в одном srcset.
Используйте дескрипторы w вместе с sizes, когда компонент растёт или сжимается.
Используйте дескрипторы x без sizes только тогда, когда отрисованный CSS-размер стабилен.
Поймите, как sizes направляет выбор
При использовании дескрипторов ширины браузер оценивает sizes перед загрузкой изображения. Каждая запись сочетает необязательное медиa-условие и длину. Первое совпадающее условие задаёт source size; последний безусловный length — резервный вариант. sizes — это подсказка для выбора, а не CSS-правило.
Браузер сравнивает эту оценку source size с ширинами кандидатов, чтобы вычислить эффективную плотность (effective density), после чего может учесть плотность дисплея, зум и сетевые условия. Браузер не обязан выбирать математически ближайшее имя файла. Поставляйте правдивые кандидаты и достоверную оценку слота; окончательное решение остаётся за пользовательским агентом.
Побеждает первое совпавшее медиa-условие, поэтому пишите список в порядке, где первое совпадение будет корректным.
Карточка, занимающая одну треть ширины на десктопе, при описании как viewport-wide может вызвать выбор неоправданно большого кандидата.
Получайте кандидатов из реального макета
Инвентаризируйте компоненты, а не страницы. Хедер-герой, иллюстрация статьи, галерея товара, миниатюра в поиске и логотип в футере часто имеют разные ширины слотов. Для каждого запишите узкую и максимальную отрисованную ширину, соотношение сторон, поведение обрезки и видимость в начальном экране.
Генерируйте ширины вокруг значимой области слота компонента, с большим вариантом, когда детализация оправдывает рендеринг в высокой плотности. Почти идентичные файлы увеличивают сложность сборки и кэширования; только очень маленький и очень большой файл заставляют идти на компромисс. Тестируйте сгенерированные URL, а не предполагайте, что трансформации изображений работают.
Держите валидный src-фолбэк и значения width и height, которые соответствуют доставляемому соотношению сторон. Они резервируют пространство, но не препятствуют отзывчивому CSS менять финальные размеры.
Кандидат, заявленный как 800w, должен действительно быть 800 пикселей в ширину.
Поддерживайте план слота и кандидатов вместе с изменениями шаблона и дизайна.
Используйте picture для арт‑дирекции
Арт‑дирекция меняет композицию, а не только размер файла. Широкая пейзажная фотография может потребовать более плотного портретного кропа на узком экране, чтобы основной объект оставался видимым. Элемент picture может предложить медиa-специфичные варианты source, а затем один img в качестве фолбэка. Браузер учитывает media, type и srcset каждой source-записи; img несёт альтернативный текст, размеры и поведение фолбэка.
Подготовьте каждый кроп с редакционным и доступностным (accessibility) обзором. Мобильный кроп может убрать деталь продукта или человека, упомянутого в alt. Помещайте alt на img и описывайте информацию или функцию, которую передаёт изображение. Используйте alt="" только для действительно декоративного изображения; для изображений-ссылок или кнопок опишите действие, а не внешний вид. Не вводите picture, если композиция не меняется: обычный srcset по ширине проще.
Загруженный десктопный герой с множеством деталей нуждается в отдельном портретном кропе для телефона.
source в picture может указать type и сохранить функционально пригодный img-фолбэк.
Избегайте дорогостоящих ошибок загрузки и разметки
Частая трата — копировать sizes="100vw" во все изображения. Это может подходить для узкой полноширинной фигуры, но не для ограниченного контейнера или карточки на десктопе. Обратная ошибка — устаревшие sizes после редизайна. Меняйте CSS и sizes вместе.
Не лениво‑загружайте (lazy-load) изображение, важное в первоначально видимом контенте. Рекомендации советуют lazy-loading для изображений ниже фолда и оставлять видимый герой eager. Fetch priority может повысить приоритет действительно критичного изображения, но широкое применение high-priority или preload может повредить производительности. Не полагайтесь на имена файлов или кэш как на доказательство.
CMS, прокси или кэш могут скрывать неверный дескриптор или непреднамеренный запрос изображения.
Не делайте важный текст на странице зависимым только от арт‑директного кропа.
Тестируйте запрос, кроп и исправление
Тестируйте репрезентативные страницы при ширинах, которые меняют макет, включая значения чуть выше и ниже breakpoint сетки. Включите настройку высокой плотности, широкий десктоп и состояния, которые изменяют слот. Подтвердите отрисованные размеры, кроп, альтернативный текст и визуальную резкость.
В Chrome DevTools откройте Network, перезагрузите с отключённым кэшем или используйте Empty Cache And Hard Reload, отфильтруйте запросы изображений и исследуйте URL, размер передачи, заголовки, initiator и тайминги. Ограничьте канал (throttle), чтобы выявить позднюю или избыточную работу. Запишите viewport, device scale factor, слот, кандидат, переданные байты и ожидаемый результат.
Когда шаблон, breakpoint, CDN или конвейер ассетов меняется, делайте это условием релиза. Исправляйте узко: корректируйте sizes, фиксируйте дескриптор, регенерируйте кроп, восстанавливайте фолбэк или удаляйте ненужный preload. Повторно тестируйте через Empty Cache And Hard Reload.
Панель Network фиксирует кандидат, который был реально запрошен.
Это проверяет поведение доставки изображений, а не пропускную способность origin, доступность CDN или общую работоспособность.
Примените это как контроль устойчивости SIU
Адаптивные изображения сокращают избыточную передачу, но не могут гарантировать успешный запрос. Ошибки origin, недоступные трансформации, сторонние хосты и сбои CDN требуют отдельного планирования непрерывности и восстановления.
Для SIU используйте тестовые записи, чтобы рано обнаруживать регрессии доставки, идентифицировать ответственный шаблон или правило трансформации и вносить минимально безопасное исправление перед запуском. Сопроводите это предусмотром доступности и планом отката.
Назначьте владельца компонента и конвейера изображений для каждой неудачной проверки выбора.