Точки останова адаптивных изображений: Практическое руководство по WebP

Последнее обновление: June 28, 2026

Точки останова для адаптивных изображений — это ширины изображений, которые вы генерируете, чтобы телефоны, планшеты, ноутбуки и экраны с высокой плотностью пикселей могли загрузить файл размером, максимально приближенным к фактическому размеру отображения. Выбрать слишком мало точек останова, и мобильные пользователи получат десктопные пиксели. Выбрать слишком много — и ваш build, cache и CDN будут заполнены вариантами, которые никому не нужны.

В этом руководстве мы рассмотрим практический баланс: измерьте слот макета, сгенерируйте короткую WebP лестницу (ladder), напишите srcset и sizes, а затем проверьте, что браузер выбирает правильный файл из CDN.

Краткий ответ: какие брейкпоинты для адаптивных изображений использовать?

Используйте брейкпоинты, соответствующие фактическому отображаемому слоту изображения, а затем добавьте запас по плотности для экранов Retina. Для многих изображений статей полезной лестницей WebP является 480w, 720w, 960w, 1200w, и 1440w. Для полноширинных hero-изображений добавьте 1920w, если дизайн действительно может отобразить такую ширину.

Не копируйте CSS брейкпоинты вслепую. На странице может быть брейкпоинт макета 1280px, в то время как само изображение отображается внутри колонки статьи шириной 720px. В этом случае изображение 1440w может уже покрывать дисплей 2x, а вариант 1920w может оказаться лишним.

Надежный метод прост: проверьте максимальную ширину слота в CSS, умножьте на самую высокую плотность, которую вы хотите поддерживать, округлите до разумных ширин и удалите почти дублирующиеся файлы. Затем свяжите эти файлы с правдивым атрибутом sizes, чтобы браузер мог выбрать правильно.

Что такое точки останова для адаптивных изображений?

Точки останова для адаптивных изображений — это сгенерированные ширины файлов, а не обязательно точки останова дизайна. CSS breakpoints меняют макет. Image breakpoints предоставляют браузеру меню из файлов, таких как 480w, 720w, 960w и 1440w.

В руководстве MDN по responsive images объясняется основная проблема: браузеру нужна достаточно информации, чтобы выбрать изображение подходящего размера до завершения макета. Атрибут srcset перечисляет кандидатов, а sizes описывает слот, который займет изображение.

Это разделение имеет значение. Если srcset корректен, но sizes — нет, браузер может все равно загрузить файл большего размера, чем необходимо. Если sizes корректен, но сгенерированные файлы пропускают полезные ширины, у браузера не будет хорошего выбора.

Для выбора формата объедините точки останова с современным веб-форматом. WebP — это безопасный вариант по умолчанию для широкой поддержки, а AVIF может быть полезен при работе с большими фотоархивами. Компромисс форматов рассмотрен в AVIF vs WebP Comparison.

Как выбрать ширины точек останова?

Начинайте с отображаемого слота, а не с исходного файла. Фотография продукта в 4000px не нуждается в варианте для веба размером 4000px, если самый крупный видимый слот составляет 760px. Ей нужно достаточно пикселей, чтобы выглядеть четко в этом слоте на экранах, которые вас интересуют.

Используйте следующий порядок:

1. Откройте страницу в узкой мобильной раскладке, типичной ширине планшета, ширине ноутбука и широкой десктопной ширине.
2. Измерьте отображаемый слот изображения в CSS pixels.
3. Умножьте каждый слот на 1x и 2x, если вам нужна поддержка высокой плотности.
4. Округлите до небольшой лестницы, такой как 480, 720, 960, 1200, 1440 и 1920.
5. Удалите ширины, которые отличаются менее чем на 15 процентов.
6. Остановитесь на самой большой ширине, которую может использовать дизайн.

Я закодировал четыре графика в этой статье локально размером 1400x788 как WebP. Каждый измеренный файл весит менее 35 KB, потому что это плоские учебные графики. Фотография с такими же размерами обычно будет намного больше, поэтому измеряйте собственную выходную продукцию перед установлением бюджетов.

Если целая папка нуждается в этих ширинах, используйте повторяющийся шаг изменения размера. Batch Resize Guide описывает шаблон командной строки для создания производных изображений без перезаписи мастер-файлов.

Как должны выглядеть srcset и sizes?

Для большинства адаптивных контентных изображений используйте дескрипторы ширины с sizes. Дескрипторы ширины сообщают браузеру реальную пиксельную ширину каждого кандидата. Значение sizes сообщает браузеру, насколько широко изображение будет отображаться в макете.

<img
  src="https://cdn.example.com/blog/photo-960.webp
  srcset="
    https://cdn.example.com/blog/photo-480.webp 480w,
    https://cdn.example.com/blog/photo-720.webp 720w,
    https://cdn.example.com/blog/photo-960.webp 960w,
    https://cdn.example.com/blog/photo-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  width="1440"
  height="810"
  alt="Product photo displayed in a responsive article layout">

Пример sizes гласит: когда область просмотра имеет ширину не менее 900px, место для изображения составляет 720px; в противном случае место составляет 92% от области просмотра. Телефон шириной 390px может выбрать файл около 720w для отображения в 2x вместо загрузки файла 1440w.

Руководство web.dev по адаптивным изображениям демонстрирует тот же принцип выбора браузером: предоставьте браузеру точные кандидаты и информацию о макете, чтобы он мог выбрать до того, как будет сделан запрос на изображение.

Используйте элемент <picture>, когда меняется обрезка или формат, а не при каждом нормальном изменении размера. Например, арт-директированные изображения в качестве заголовков могут требовать квадратной мобильной обрезки и широкой десктопной обрезки. Простые изменения ширины обычно проще реализовать с помощью одного <img> и хорошего srcset.

Сколько брейкпоинтов для изображений — это слишком много?

Больше вариантов не означает автоматически лучше. Каждая дополнительная ширина увеличивает время сборки, хранилище, записи кэша, поверхность инвалидации CDN и объем работы по проверке. Если два кандидата очень близки, экономия байтов браузером может быть слишком мала, чтобы оправдать еще один файл.

Используйте компактный набор, если только ваш трафик и объем изображений не требуют более тонкой настройки. Пяти ширин на изображение часто достаточно для статей и маркетинговых страниц. Сайтам с продуктами, зумом, сетками и множественными кадрами может потребоваться больше, но они должны генерироваться конвейером (pipeline), а не вручную.

Обращайте внимание на эти признаки того, что "лестница" слишком плотная:

• Существуют 640w, 700w и 760w для одного и того же изображения.
• Логи CDN показывают, что некоторые варианты почти никогда не запрашиваются.
• Время сборки растет, потому что каждая загрузка создает десять или более производных копий.
• Редакторам трудно определить, какой файл должен быть в frontmatter, Open Graph и основном контенте.
• Визуальный QA начинает проверять имена файлов вместо отображенных страниц.

Обращайте внимание на эти признаки того, что "лестница" слишком разреженная:

• Телефоны скачивают файл 1440w или 1920w для обычных изображений в теле статьи.
• Экраны Retina на настольных компьютерах выглядят мягкими, потому что самый крупный кандидат слишком мал.
• Браузер всегда выбирает один и тот же резервный src.
• PageSpeed или Lighthouse отмечают слишком большие изображения на мобильных устройствах.

[image SEO best practices] от Google рекомендуют сканируемые URL-адреса изображений, полезный окружающий текст и описательный alt text. Адаптивная доставка должна сохранять эти основы. Не прячьте важные изображения в фоновых стилях CSS, если они должны быть проиндексированы или поняты как контент страницы.

Как брейкпоинты влияют на Core Web Vitals?

Адаптивные брейкпоинты влияют на производительность, потому что байты изображений часто доминируют в первом экране. Если главное изображение также является элементом Largest Contentful Paint, неправильный брейкпоинт может заставить самый важный рендеринг ждать файл, который в два раза больше, чем необходимо.

Руководство web.dev по оптимизации Largest Contentful Paint рекомендует сделать вероятные изображения LCP обнаружимыми на раннем этапе и приоритизировать их в соответствующих случаях. Брейкпоинты не заменяют эту работу. Они гарантируют, что приоритетный файл имеет правильный размер.

Для изображений выше сгиба (above-the-fold):

1. Установите явные width и height, чтобы зарезервировать место.
2. Избегайте ленивой загрузки вероятного изображения LCP.
3. Используйте fetchpriority="high" только для изображения, которое действительно в этом нуждается.
4. Поддерживайте точность sizes для начальной раскладки.
5. Проверьте выбранный currentSrc в DevTools.

Для изображений ниже сгиба (below-the-fold):

1. Используйте ленивую загрузку обычных галерейных и статейных изображений.
2. Используйте ту же лестницу брейкпоинтов, если только достаточно не будет меньшей обрезки.
3. Сжимайте после изменения размера, а не до него.
4. Сохраняйте alt text, специфичный для видимого изображения.
5. Проверяйте водопады мобильной сети, а не только десктопные.

Если ваша проблема в основном связана с задержкой обнаружения главного актива (hero asset), прочтите Critical Image Extraction. Если файлы просто слишком тяжелые, пройдитесь по Image Compression Ratio Guide перед изменением разметки.

Какие проверки CDN следует запустить перед публикацией?

Breakpoints работают только тогда, когда конечные URL-адреса функционируют. Чистый черновик в Markdown все равно может завершиться неудачей, если путь CDN неверен, объект имеет неправильный тип содержимого или страница случайно ссылается на локальный файл /blog/....

Запустите эту проверку перед публикацией:

В Chrome DevTools проверьте отрендерированное изображение и проверьте currentSrc. Затем измените область просмотра (viewport) и коэффициент пикселей устройства (device pixel ratio). Выбранный URL должен пройти через всю лестницу. Если он никогда не меняется, это может означать, что разметка или компонент изображения фреймворка переопределяют ваши кандидаты.

Для более широкого прохода публикации используйте Complete Image Optimization Checklist. Для бюджетов, специфичных для мобильных устройств, сочетайте это с Mobile Image Optimization Guide. Решения о ленивой загрузке (Lazy loading) рассматриваются отдельно в Lazy Load Images.

Контрольный список точек останова для адаптивных изображений

Используйте эту краткую версию при проверке pull request:

• Основное изображение должно быть больше, чем самый большой сгенерированный вариант.
• Сгенерированные ширины соответствуют реальным отображаемым слотам.
• Ширины не должны быть упакованы в крошечные, малозначимые инкременты.
• Файлы WebP сжимаются после изменения размера.
• srcset использует правильные дескрипторы ширины.
• sizes соответствует макету, а не предполагаемому 100vw.
• Вероятное изображение LCP не должно быть загружено лениво (lazy-loaded).
• Изображения ниже линии сгиба должны быть загружены лениво (lazy-loaded).
• Присутствуют ширина и высота, чтобы избежать смещения макета.
• URL CDN возвращают HTTP 200 до публикации.
• Внутренние ссылки направляют читателей к следующим шагам по сжатию, мобильной версии и ленивой загрузке (lazy-loading).

Полезный набор точек останова — это самый маленький набор, который сохраняет четкость изображений, не заставляя телефоны скачивать файлы для настольных компьютеров. Измерьте слот, сгенерируйте лестницу (ladder), опубликуйте файлы WebP и убедитесь, что браузер выбирает ожидаемый вами файл.