Оптимизация изображений: форматы, размеры и загрузка

Редакция Romanov Lab · Обновлено 13 октября 2026

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

Полезный результат работы выглядит просто: изображение понятно, достаточно чёткое на нужных экранах и не загружает больше данных, чем требуется сценарию. Изменения следует проверять на реальных страницах. Общие показатели скорости помогают увидеть эффект, но подбор файлов требует отдельной работы; связь с ними разобрана в материале о Core Web Vitals.

Начните с инвентаризации

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

Отдельно проверьте картинки, спрятанные в слайдерах, фоновые изображения и дубли для мобильного экрана. Иногда браузер скачивает варианты, которые посетитель не видит. Сохраните исходное измерение в одинаковых условиях: иначе после изменения трудно понять, уменьшилась нагрузка или просто сработал кеш.

Выбирайте формат по содержимому

• Фотографии: сравните AVIF, WebP и JPEG при приемлемом визуальном качестве конкретного изображения.
• Растровые схемы и интерфейсы: проверьте сохранение тонких линий и текста; для некоторых материалов подходит формат без потерь.
• Логотипы и простые иконки: рассмотрите подготовленный SVG, если исходник действительно векторный.
• Прозрачность: учитывайте её поддержку и проверьте края объекта на светлом и тёмном фоне.
• Анимация: сначала решите, нужна ли она для задачи; сравните подходящие форматы и способ воспроизведения.

MDN перечисляет свойства и поддержку форматов, но не устанавливает универсальный победитель для любого файла. Не обещайте одинаковое сокращение веса всем фотографиям. Сложная фактура, градиенты и мелкий текст по-разному переносят сжатие. При необходимости предусмотрите запасной формат для поддерживаемых проектом браузеров.

Подготовьте нужные размеры

Храните качественный оригинал отдельно от файлов публикации. Экспортируйте несколько обоснованных размеров под используемые компоненты: карточку, широкую иллюстрацию и крупный просмотр. Не создавайте десятки почти одинаковых вариантов без реальной потребности. Лучше связать набор с шириной компонентов и плотностью пикселей целевых экранов.

Для одного сюжета в разных разрешениях используются srcset и sizes. Первый перечисляет доступные файлы, второй описывает предполагаемую ширину изображения в макете. Браузер выбирает ресурс с учётом этих подсказок и условий устройства. Ошибочное sizes способно свести пользу подготовленных вариантов к минимуму.

Проверяйте выбор по фактическому сетевому запросу и свойству currentSrc. Маленькая картинка на экране не доказывает, что скачан маленький файл. Для чистого сравнения откройте страницу в новом контексте или очистите соответствующий кеш: браузер может повторно использовать уже загруженный крупный вариант.

Отделяйте кадрирование от разрешения

Если на телефоне нужно показать другой фрагмент фотографии, простого уменьшения файла недостаточно. Элемент picture позволяет задавать разные источники, в том числе для художественного кадрирования. Например, широкий снимок рабочего пространства и более тесный вертикальный кадр могут сохранять главный объект на разных экранах.

Сначала согласуйте, что должно остаться видимым: лицо, изделие, подпись на схеме. Автоматическое обрезание по центру иногда удаляет существенную часть. Для каталога и портфолио полезно определить правило выбора фокусной точки, чтобы редактор не исправлял каждую карточку после публикации.

Настройте момент загрузки

Изображения далеко ниже первого экрана могут загружаться отложенно. Для важной картинки первого экрана, особенно вероятного LCP-элемента, web.dev рекомендует избегать lazy loading. Решение принимают по роли изображения на странице, а не массовой установкой одного атрибута для всех файлов.

Указывайте корректные width и height либо иным способом резервируйте нужное соотношение сторон в макете. Это помогает браузеру оставить место до загрузки. При этом размеры в разметке не запрещают адаптивное отображение. Проверьте ситуацию с медленной сетью: текст и кнопки не должны неожиданно уезжать при появлении фотографии.

Проверьте качество и доступность

Сравнивайте варианты при размере, в котором они действительно показываются. Увеличение снимка в несколько раз полезно для поиска артефактов, но не должно быть единственным критерием. Особое внимание уделите лицам, границам предметов, мелкому тексту и плавным переходам цвета.

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

Рассчитайте варианты для конкретного компонента

Учебный пример: фотография услуги показывается в карточке шириной около 360 CSS-пикселей. Для экрана с плотностью 2× может понадобиться примерно 720 пикселей по ширине исходного ресурса. Это ориентир для подготовки, а не приказ браузеру скачать строго такой файл: выбор зависит от разметки и условий. Отправлять в карточку оригинал шириной 4000 пикселей только потому, что он уже есть, обычно нерационально.

Предположим, та же фотография используется в широком блоке до 1200 CSS-пикселей. Вместо одного универсального файла подготовьте небольшой набор производных размеров, покрывающий оба сценария. Затем посмотрите реальные запросы на узком и широком экране. Если карточка всё равно скачивает самый большой вариант, сначала проверьте разметку и подсказку размера, а не снижайте качество всех изображений.

При использовании списка кандидатов с дескрипторами ширины значение sizes должно описывать ширину изображения в макете для соответствующих условий. Оно не задаёт размер через CSS. Ошибка «везде 100vw» сообщает браузеру, что картинка занимает всю ширину окна, хотя в трёхколоночном каталоге это не так. Поэтому изменение сетки и изменение подсказок изображений следует проверять вместе.

Разделите три решения, которые часто смешивают

Если лицо человека пропало при мобильном кадрировании, увеличение качества не поможет. Если мелкая подпись в схеме не читается, перевод в другой формат может не исправить слишком маленькое отображение. Если файл готов правильно, но начинает загружаться поздно, дальнейшее сжатие не устраняет задержку обнаружения ресурса. Такая последовательность помогает работать с причиной, а не с одним числом в килобайтах.

Проведите воспроизводимое сравнение

Возьмите несколько разных изображений: гладкий фон с градиентом, фотографию с мелкими деталями, предмет на прозрачном фоне и иллюстрацию с текстом. Для каждого подготовьте кандидатов и сравните в конечном размере. Один выигрышный снимок не является доказательством, что выбранная настройка подходит всей медиатеке. Числа качества у разных кодировщиков также не следует считать единой шкалой.

1. Зафиксировать исходный ресурс: размеры, формат, объём и назначение.
2. Сделать варианты одинакового кадра и разрешения, чтобы сравнивать именно кодирование.
3. Оценить края предметов, волосы, мелкие детали, текст, прозрачность и переходы цвета.
4. Выбрать наименьший приемлемый вариант для данного применения.
5. Подключить его к странице и проверить фактический запрос в сетевой панели.
6. Повторить загрузку в одинаковых условиях и записать результат вместе с ограничениями теста.

Можно завести внутренний ориентир по размеру файла для карточки и большого баннера, но он должен вытекать из макета, содержания и общего бюджета страницы. Универсальное правило «любое изображение не больше заданного числа килобайт» способно испортить техническую схему и одновременно оставить избыточно тяжёлую иконку.

Для главного изображения проверьте всю цепочку загрузки

Большая фотография первого экрана может оказаться элементом LCP. Сначала подтвердите это измерением: на другой странице или ширине таким элементом может стать текст. В руководстве web.dev оптимизация LCP рассматривает не только передачу файла, но и задержки до начала загрузки и до отображения. Поэтому полезно узнать, когда браузер вообще получает адрес изображения.

Если адрес появляется только после выполнения скрипта или запроса данных, файл может начать загружаться поздно даже при малом размере. Для подтверждённого важного ресурса рассмотрите раннее обнаружение в исходной разметке и подходящий приоритет. Атрибут fetchpriority — подсказка, а не гарантия порядка. Не назначайте высокий приоритет всей галерее: нужно выделять действительно важный ресурс и проверять эффект.

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

Подготовьте понятные правила для редактора

Редактору удобнее выбрать тип блока и фокусную точку, чем вручную рассчитывать srcset. Поэтому повторяющуюся обработку стоит перенести в публикационный процесс: система создаёт размеры, шаблон подключает варианты, а человек проверяет смысл и кадр. Для схем предусмотрите отдельный режим без агрессивного сжатия и возможность открыть крупную версию, если она нужна для чтения.

В инструкции укажите, где хранится оригинал, какие права на изображение должны быть подтверждены, какие пропорции подходят компонентам и как проверить опубликованный результат. Также объясните замену файла: после обновления нужно убедиться, что страница показывает новую версию, а необходимые старые ссылки не потеряны. Не удаляйте исходники только потому, что текущий дизайн использует маленькую карточку: следующий макет может потребовать другого кадра.

Финальная проверка оптимизации объединяет три результата: посетитель видит нужную информацию, браузер получает подходящий ресурс, а редактор способен повторить процесс для следующего материала. Если выполнен только второй пункт, сайт может стать легче, но менее понятным; если только первый — нагрузка быстро вернётся после новых публикаций.

Закрепите процесс для новых материалов

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

Оптимизация становится устойчивой, когда встроена в публикацию контента. Разовая обработка старых файлов быстро теряет эффект, если редактор снова загружает оригинал на всю ширину камеры. Поэтому задачу удобно включать и в разработку сайта, и в план его сопровождения.

Источники

MDN: форматы изображений; MDN: адаптивные изображения; web.dev: отложенная загрузка и размеры изображений.

web.dev: оптимизация LCP.