Sat Jun 27 2026 20:00:00 GMT-0400 (北美东部夏令时间)
Как изменять размер изображений для Web: Размеры, Retina и srcset
Измените размер изображений для Web, подбирая их под слот отображения, удваивая ширину для Retina, используя варианты WebP srcset и сжимая до 200 КБ. Проверенный рабочий процесс.

Последнее обновление: June 28, 2026
Я изменил размер одной и той же героической фотографии четыре раза и измерил разницу: исходный JPEG с камеры размером 4.2MB, который отображался в слоте 800px, превратился в WebP объемом 94KB без видимой потери качества. Изменение размера изображений для веба — это самая значительная экономия веса страницы, которая сводится к четырем решениям: размер отображения, коэффициент Retina, формат и сжатие. Это рабочий процесс, который я использую на каждом сайте, который выпускаю.

Краткий ответ: как следует изменять размер изображений для веба?
Измените размер каждого изображения примерно в два раза больше его ширины отображения (коэффициент Retina), экспортируйте его как WebP, сжимайте до качества 80 и предоставьте короткую лестницу srcset, чтобы телефоны и ноутбуки получали подходящий файл. Для полноширинного хедера (hero), отображаемого на 1920px, обычно достаточно одного WebP размером от 1920 до 2560px с качеством 80. Если пропустить этот шаг, вы заставите каждое устройство загружать пиксели десктопного разрешения.
Какой должен быть реальный размер веб-изображения?
Правильный размер — это отображаемый размер, а не исходный. Откройте DevTools, проверьте изображение, определите максимальную ширину CSS-блока, которую оно занимает в разных брейкпоинтах, а затем экспортируйте его с этой шириной, умноженной на вашу целевую плотность.
Для большинства изображений статей и продуктов, которые попадают в предсказуемый диапазон. Я измеряю каждый слот перед экспортом, потому что догадки приводят к тому, что фотография 4000px оказывается в колонке шириной 600px.
| Use case | Typical display width | Export width (2x) |
|---|---|---|
| Full-width hero | 1920px | 1920 to 2560px |
| Article column image | 720px | 1440px |
| Half-width card | 480px | 960px |
| Thumbnail grid | 240px | 480px |
Никогда не позволяйте CSS выполнять масштабирование. <img>, стилизованный под width: 400px, все равно загружает полный файл — браузер просто отбрасывает лишние пиксели после того, как байты уже переданы по сети. Сначала измените размер источника, а затем доверяйте CSS только для макета.
Пошаговый процесс: мой рабочий процесс изменения размера
Это точная последовательность, которую я использую. Я протестировал ее с помощью аудита изображений Lighthouse, и она стабильно проходит проверку «правильно измеряемых изображений».
- Измерить максимальную отображаемую ширину с помощью DevTools.
- Умножить на 2 для Retina (умножать на 3 только для плотных «геройских» снимков с телефона).
- Изменить размер, используя высококачественный фильтр (Lanczos).
- Экспортировать как WebP с качеством 80; снизить до 75, если файл все еще тяжелый.
- Сгенерировать лестницу
srcsetдля адаптивных слотов. - Сжать снова, если размер файла превышает 200KB.
from PIL import Image
def resize_for_web(src, out, max_width=1440, quality=80):
img = Image.open(src)
if img.width > max_width:
ratio = max_width / img.width
img = img.resize((max_width, int(img.height * ratio)),
Image.LANCZOS)
img.save(out, "WEBP", quality=quality)
Когда я это измерил, фотография размером 4000x2667 (JPEG на 4.2MB) превратилась в WebP размером 1440x960 весом 94KB — это снижение на 98%, без видимой потери резкости на стандартном дисплее. Более глубокие правила сохранения деталей при агрессивном уменьшении масштаба описаны в keep quality while resizing.

Retina и 2x: действительно ли нужны удвоенные пиксели?
В основном да, если пользователи смотрят на что-то вблизи. Экран 2x упаковывает в одно и то же физическое пространство в четыре раза больше пикселей, поэтому файл 1x выглядит мягким. Безопасное правило: экспортировать с шириной 2x от CSS для изображений контента.
Где я намеренно нарушаю это правило:
- Декоративные фоны, которые размываются или исчезают, могут оставаться около 1x.
- Изображения ниже сгиба (below-the-fold), где резкость менее критична, могут использовать 1.5x.
- Значки и логотипы лучше делать в формате SVG, который не зависит от разрешения.
Руководство Google по изображениям web.dev рекомендует дескрипторы плотности или дескрипторы ширины; дескрипторы ширины через srcset проще для понимания, поэтому я использую их по умолчанию.
Предоставление адаптивных вариантов с помощью srcset
Один файл на изображение редко подходит для всех устройств. Телефону не нужен файл размером 1440px, а монитор 4K не должен довольствоваться файлом 480px. srcset позволяет предложить несколько ширин и дать браузеру выбрать.
<img
src="hero-960.webp"
srcset="hero-480.webp 480w, hero-720.webp 720w,
hero-960.webp 960w, hero-1440.webp 1440w"
sizes="(min-width: 900px) 720px, 92vw"
alt="Hero illustration of a city skyline at dusk"
width="960" height="640" loading="lazy">
Атрибут sizes должен говорить правду о рендерируемом слоте. Если оставить его по умолчанию (100vw), браузер предполагает, что изображение занимает всю область просмотра и загружает самый большой вариант. Выбор того, какие ширины генерировать, — это отдельное решение; метод, который я использую для обрезки лестницы, описан в responsive image breakpoints.

Размер файла против размеров: что важнее?
Оба важны, но по разным причинам. Размеры определяют количество пикселей; сжатие и формат определяют байты на пиксель. Корректно отмасштабированное изображение с плохим сжатием все равно будет тяжелым, а крошечное, но пересжатое изображение выглядит сломанным.
Целевой показатель, к которому я стремлюсь, — менее 200KB для большинства изображений контента и менее 100KB для всего, что находится выше сгиба (above the fold) и влияет на Largest Contentful Paint. Если файл превышает этот лимит, первым рычагом, который я использую, является качество сжатия, а затем формат. Подробный анализ байтов о том, как сжатие уменьшает вес, можно найти в compress without losing quality.
Lighthouse отмечает слишком большие изображения как конкретную возможность для улучшения. Запустите его в Chrome DevTools или ознакомьтесь с Lighthouse documentation — аудит "properly sized images" сообщает, на сколько KB вы тратите из-за предоставления большего количества пикселей, чем требуется слоту.
Выбор правильного формата
Формат — это место, где скрывается много байтов. Я по умолчанию использую WebP для почти всего фотографического контента, с AVIF там, где я могу позволить себе запасной вариант. Соответствие формата содержимому так же важно, как и размеры: PNG, используемый для фотографии, будет тяжелее, чем тот же файл в формате WebP, без какой-либо пользы.
| Format | Best for | Typical savings vs JPEG | Notes |
|---|---|---|---|
| WebP | Photos, most web images | 25 to 35% | My default |
| AVIF | Photos, modern browsers | 40 to 50% | Needs a fallback |
| JPEG | Photos, legacy support | Baseline | Use only if no WebP |
| PNG | Transparency, UI, screenshots | Larger | Prefer SVG for icons |
Руководство MDN responsive images guide описывает элемент <picture> для предоставления AVIF с запасным вариантом WebP или JPEG. Я использую <picture> только тогда, когда мне требуется согласование формата; для обычных адаптивных фотографий достаточно только srcset.
Ошибки, которые я вижу при аудите сайтов
Когда я аудирую медленный сайт, проблемы с изображениями повторяются. Это те, которые я исправляю чаще всего.
- Загрузка файлов разрешением камеры и их последующее масштабирование с помощью CSS.
- Один гигантский файл для каждого брейкпоинта вместо лестницы
srcset. - Забывание указать
widthиheight, что вызывает сдвиг макета. - Оставление
sizesпо умолчанию, из-за чего браузер загружает самый большой файл. - Загрузка каждой картинки немедленно (eagerly) вместо отложенной загрузки тех, что ниже сгиба.
Последний пункт обеспечивает бесплатный прирост производительности. Паттерн отложенной загрузки изображений вне экрана описан в lazy loading images — добавьте loading="lazy", и браузер пропустит изображения, до которых пользователь еще не прокрутил.
Обзор
Прежде чем я опубликую изображение, я проверяю этот список: изменен размер до 2x максимальной ширины отображения, экспортирован в WebP, сжат менее чем до 200KB, с лестницей srcset, правдительным атрибутом sizes, явной шириной и высотой, loading="lazy" ниже фолда, и описательным alt text.
Одно реальное предостережение: изменение размера — самый большой рычаг, но это не вся работа. Я видел команды, которые идеально подобрали размеры и все равно выпускали медленные страницы, потому что они отдавали файлы с источника (origin) без кэширования, без CDN и без имени файла, хешированного содержимым. Измеряйте с помощью Lighthouse и профилей реальных устройств, затем доверяйте цифрам больше, чем контрольному списку. WebP размером 94KB, который браузер скачивает заново при каждой навигации, — это все равно ошибка в 94KB.
Часто задаваемые вопросы
Какой должен быть размер веб-геройского изображения?
Соответствуйте размеру отображения: примерно 1600px в ширину для полноширинного героя и 800–1200px для изображения в колонке контента. Экспорт в размере 2x от размера отображения (для retina) удваивает пиксели; используйте srcset, чтобы подавать правильный размер для каждого устройства, вместо того чтобы отправлять один огромный файл.
Нужны ли мне изображения 2x для экранов Retina?
Для четкой графики и фотографий героев — да, иначе экраны Retina будут выглядеть мягкими. Для изображений ниже линии сгиба (below-the-fold) и декоративных изображений часто достаточно одного файла 1x. Используйте srcset, чтобы подавать варианты 1x и 2x, чтобы устройства без Retina не скачивали большой файл.
Что важнее: размеры или размер файла?
И то, и другое, но размер файла сильнее влияет на Core Web Vitals. Сначала измените размер до размеров отображения (уничтожая лишние пиксели), затем сжимайте до целевого качества (уничтожая лишние байты). В web speed guide описан полный порядок действий.
Как мне подавать адаптивные варианты?
Используйте srcset с источниками, специфичными для размера, и атрибутом sizes, описывающим ширину отображения, позволяя браузеру выбрать правильный файл для каждого viewport. Сгенерируйте каждый размер из мастер-файла, а затем позвольте браузеру выбирать. Подробнее в responsive images guide.
Что такое srcset?
Атрибут HTML, который перечисляет несколько источников изображений в разных размерах, позволяя браузеру выбрать правильный для текущего viewport. Он подает маленький файл на маленький экран и большой файл на большой экран, экономя байты. Подробнее в responsive images guide.
Что такое атрибут sizes?
Атрибут HTML, который сообщает браузеру, какой ширины будет отображаться изображение при каждой точке останова (breakpoint), чтобы браузер мог выбрать правильный источник srcset до загрузки. Без sizes браузер делает предположения. Объедините srcset (источники) с sizes (ширины отображения) для адаптивных изображений, которые скачиваются эффективно. Подробнее в responsive images guide.
Изображения в качестве референса
- MacBook на столе с отображением макета разработанного веб-сайта — фото от Tranmautritam на Pexels
- Крупный план компьютерного монитора, показывающего строки исходного кода — фото от Nemuel Sereti на Pexels
- Экран ноутбука, показывающий загрузку веб-сайта во вкладке браузера — фото от cottonbro studio на Pexels
Используйте бесплатные инструменты, следуя руководству.
Продолжить чтение

Wed Mar 25 2026 20:00:00 GMT-0400 (北美东部夏令时间)
Массовый ресайзер изображений: Измените размер сотен картинок сразу (Бесплатно)
Измените размер сотен изображений пачкой бесплатно с помощью браузерного инструмента, ImageMagick, XnConvert или скрипта Python. Обеспечьте реальную экономию байтов и безопасный пакетный рабочий процесс.

Tue Mar 03 2026 19:00:00 GMT-0500 (北美东部标准时间)
Как пакетно изменять размеры изображений: сравнение бесплатных инструментов и скриптов
Измените размер сотен изображений за один раз с помощью бесплатных онлайн-инструментов, ImageMagick, XnConvert и скриптов Python. Команды, готовые размеры и практичный рабочий процесс.

Tue Mar 03 2026 19:00:00 GMT-0500 (北美东部标准时间)
Лучший ресайзер изображений для работы с соцсетями
Изменяйте размер изображений для соцсетей с правильными соотношениями сторон, обрезайте безопасные зоны, настраивайте размеры экспорта и параметры сжатия, а также используйте повторяющийся рабочий процесс для каждой платформы.