Картинки — это, как правило, самая тяжёлая часть страницы. Они занимают 60–70% от общего веса загружаемых ресурсов. При этом большинство сайтов грузит PNG там, где хватило бы WebP, отдаёт изображения без сжатия и загружает всё сразу, даже то, что пользователь никогда не увидит.

Если сайт тормозит — начинать нужно именно с картинок.

Какой формат выбрать

Это первый вопрос, который нужно решить. Форматов много, но реально актуальных — четыре.

JPEG — классика для фотографий и сложных изображений с плавными переходами. Хорошо сжимается при качестве 75–85, практически без видимых потерь. Не поддерживает прозрачность.

PNG — когда нужна прозрачность или чёткие линии (логотипы, иконки, скриншоты интерфейсов). Файл тяжелее JPEG, но сжатие без потерь.

WebP — формат от Google, который сочетает лучшее от JPEG и PNG. Поддерживает прозрачность, анимацию и при этом весит на 25–35% меньше аналогичного JPEG при сопоставимом качестве. Поддерживается всеми современными браузерами. Если проект не должен работать в IE, WebP — выбор по умолчанию.

AVIF — новый формат, основанный на кодеке AV1. Сжимает ещё лучше WebP — иногда на 50% меньше при том же качестве. Поддержка браузеров хорошая, но не стопроцентная: Safari до версии 16 не понимает AVIF. На практике его используют с фолбэком.

SVG — для векторной графики: логотипы, иконки, иллюстрации. Масштабируется без потерь, весит мало, индексируется поисковиками. Если есть возможность использовать SVG вместо растра — используйте.

Как совмещать форматы

Практичный подход — тег <picture> с несколькими источниками:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Описание" width="800" height="600">
</picture>

Браузер берёт первый поддерживаемый формат. AVIF для новых браузеров, WebP для остальных современных, JPEG как запасной вариант. Это работает автоматически — пользователь получает оптимальный формат без каких-либо скриптов.

Размеры и responsive images

Отдавать картинку 2000px для мобильного экрана — это расточительство. Браузер её скачает, уменьшит до 400px и отобразит. Полный трафик потрачен зря.

Атрибут srcset позволяет указать несколько версий изображения для разных разрешений:

<img
  srcset="image-400.webp 400w, image-800.webp 800w, image-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  src="image-800.webp"
  alt="Описание"
>

sizes говорит браузеру, какой ширины будет картинка при разных размерах экрана. Браузер сам выберет нужный файл. На мобиле 400px, на планшете 800px, на десктопе 1600px.

Подготовить такие версии можно через Sharp (Node.js), ImageMagick или прямо в сборщике — Webpack, Vite, Astro умеют генерировать адаптивные изображения из исходников.

Сжатие

Даже правильный формат можно испортить, если не сжать изображение перед публикацией.

Для JPEG и WebP ключевой параметр — качество (quality). При качестве 85 визуальная разница с оригиналом практически незаметна, а файл весит в 2–3 раза меньше. Для большинства контентных изображений 75–80 — вполне приемлемый вариант.

Инструменты:

  • Squoosh (squoosh.app) — браузерный инструмент от Google. Удобно для ручной оптимизации с визуальным сравнением до/после.
  • Sharp — Node.js-библиотека для программной обработки. Быстро, гибко, легко встраивается в сборку.
  • ImageOptim — десктопное приложение для macOS, хорошо работает с PNG.
  • svgo — оптимизатор для SVG, убирает лишние метаданные и атрибуты.

Если CMS — WordPress, например, — можно использовать плагины типа ShortPixel или Imagify. Они автоматически сжимают и конвертируют в WebP при загрузке.

Типичный результат после оптимизации — снижение веса на 40–70% без видимой потери качества.

Lazy load

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

Подключается одним атрибутом:

<img src="image.webp" alt="Описание" loading="lazy">

Всё. Браузер сам определит, когда картинка попадёт в зону видимости, и загрузит её. Поддерживается во всех современных браузерах без каких-либо скриптов.

Что важно учитывать:

Не ставьте lazy на hero-изображения. Картинка в шапке страницы должна загружаться сразу — это LCP (Largest Contentful Paint), ключевая метрика Core Web Vitals. Lazy load на ней только навредит.

Указывайте width и height. Без этих атрибутов браузер не знает, сколько места резервировать под картинку, и страница будет прыгать при загрузке — это CLS (Cumulative Layout Shift), ещё одна метрика, которая влияет на SEO.

<img src="image.webp" alt="Описание" width="800" height="600" loading="lazy">

fetchpriority для важных изображений. Если изображение критично (hero, первый экран), можно явно повысить его приоритет:

<img src="hero.webp" alt="Заголовок" fetchpriority="high">

Это подсказывает браузеру загрузить картинку в первую очередь.

CDN для изображений

CDN (Content Delivery Network) — это сеть серверов, распределённых по миру. Когда пользователь запрашивает картинку, CDN отдаёт её с ближайшего к нему сервера, а не с вашего хостинга в Москве или Амстердаме.

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

Популярные варианты:

Cloudflare — бесплатный тариф покрывает большинство задач. Автоматически сжимает изображения, конвертирует в WebP (фича Polish), кеширует на своих серверах. Подключается на уровне DNS за 15 минут.

Bunny.net — хороший баланс цены и возможностей. Есть CDN с трансформацией изображений: можно передавать параметры через URL (?width=400&format=webp) и получать нужный размер и формат на лету. Без предварительной генерации версий.

Imgix / Cloudinary — специализированные сервисы для работы с изображениями. Позволяют трансформировать картинки через URL, хранить оригиналы и отдавать нужные версии автоматически. Удобно для проектов с большим количеством пользовательского контента.

ImageKit — аналог Cloudinary с более щедрым бесплатным тарифом для старта.

Если использовать CDN с трансформацией, можно хранить один оригинал высокого качества и генерировать нужные размеры и форматы через параметры запроса:

https://cdn.example.com/image.jpg?w=800&format=webp&q=80

Это упрощает работу: не нужно держать десять версий каждой картинки на сервере.

Preload для критичных изображений

Если на странице есть большое изображение, которое браузер видит поздно (например, задаётся через CSS как background-image), его можно принудительно загрузить заранее через <link rel="preload">:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

Для адаптивных изображений:

<link
  rel="preload"
  as="image"
  imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  imagesizes="100vw"
>

Это особенно актуально для LCP-элементов — Google смотрит на время загрузки самого большого видимого элемента первого экрана.

Что проверить прямо сейчас

Если хотите быстро оценить состояние изображений на своём сайте:

  1. Откройте Chrome DevTools → вкладка Network → отфильтруйте по Img. Посмотрите, что и в каком формате грузится.
  2. Запустите PageSpeed Insights (pagespeed.web.dev) — он явно покажет, какие картинки нужно сжать, каким задать размеры и где включить lazy load.
  3. Проверьте вкладку Lighthouse → раздел Opportunities. Там будут конкретные картинки с потенциальной экономией в килобайтах.

Типичные находки: PNG там, где достаточно WebP, изображения без атрибутов width/height, hero-картинка с loading="lazy", файлы по 500–800 КБ без сжатия.

Автоматизация в процессе разработки

Ручная оптимизация работает, но при регулярном обновлении контента утомляет. Лучше встроить её в процесс.

Для проектов на Vite или Webpack есть плагины, которые автоматически генерируют WebP и AVIF версии при сборке, создают адаптивные варианты по конфигурации и добавляют нужные атрибуты.

Для Next.js — встроенный компонент next/image делает это из коробки: сжимает, конвертирует в WebP, генерирует адаптивные версии и добавляет lazy load. Достаточно использовать <Image> вместо <img>.

Для Astro — аналогично, компонент <Image /> из astro:assets.

Если проект разрабатывается с нуля, стоит заложить оптимизацию изображений в архитектуру с самого начала — это дешевле, чем переделывать потом. В REEXY при разработке корпоративных сайтов и интернет-магазинов это часть стандартного процесса: настраивается на этапе сборки, не требует ручного вмешательства при обновлении контента.

Практический чеклист

Что сделать, чтобы изображения не тормозили сайт:

  • Конвертировать всё в WebP (или AVIF с фолбэком на WebP)
  • Сжать с качеством 75–85 через Sharp или Squoosh
  • Задать атрибуты width и height каждому изображению
  • Добавить loading="lazy" всем картинкам, кроме первого экрана
  • Для hero-изображения использовать fetchpriority="high" и <link rel="preload">
  • Подготовить адаптивные версии через srcset и sizes
  • Подключить CDN или хотя бы включить кеширование на уровне сервера
  • Использовать SVG для логотипов и иконок

Эти шаги не требуют специальных инструментов или сложных настроек. Большинство из них — атрибуты в HTML и правильный формат файла. При этом влияние на скорость загрузки и позиции в поиске может быть очень ощутимым: страница, которая грузилась 4 секунды, после оптимизации изображений вполне может начать грузиться за 1,5.