Оптимизация изображений для SEO: alt, размер, WebP и ленивая загрузка

Картинки часто съедают больше половины веса страницы. Один незажатый JPEG на 4 МБ убивает LCP и заставляет пользователя ждать, пока сайт «дорисуется» — а поисковик фиксирует медленную загрузку и понижает страницу в выдаче. При этом оптимизация картинок для SEO — одна из самых недооценённых работ: разово настроил формат, размеры, alt-ы и ленивую загрузку — и годами получаешь бонус к скорости и дополнительный трафик из поиска по картинкам. В этом гайде разберём, что делать с изображениями в 2026 году: какие форматы использовать, как писать alt, как считать правильные размеры, что такое srcset и lazy loading, и как проверить, что всё работает.

Почему изображения — узкое место в скорости

По данным HTTP Archive, изображения в среднем занимают около половины веса типичной веб-страницы — больше, чем скрипты, шрифты и стили вместе взятые. Когда пользователь открывает страницу интернет-магазина или блога, браузер сначала загружает HTML, потом CSS и шрифты, а параллельно тянет картинки. Если самая крупная картинка (обычно баннер первого экрана) весит 3 МБ и грузится 4 секунды — именно она определит показатель LCP (Largest Contentful Paint), и пользователь увидит «готовую» страницу только через 4 секунды.

LCP — один из трёх Core Web Vitals, которые Google явно учитывает при ранжировании. Порог «хорошо» — 2,5 секунды на мобильном 4G. Медленные картинки — самая частая причина, по которой сайт не попадает в этот порог. Про сами Core Web Vitals и способы разгона — отдельно в статье как ускорить сайт: TTFB и Core Web Vitals.

Второй эффект — прямой трафик из поиска по картинкам. Яндекс.Картинки и Google Images индексируют миллиарды изображений и приводят на сайт пользователей, которые искали визуальный контент. Без alt-текста и правильного имени файла картинка в этот индекс попадёт хуже, а если попадёт — по нерелевантным запросам.

Атрибут alt: доступность и SEO

Alt (alternative text) — текстовое описание картинки, которое пишется в атрибуте alt тега <img>. Два конкретных сценария, ради которых он существует.

Доступность. Скринридеры (JAWS, NVDA, VoiceOver) читают alt вслух незрячим пользователям. Без alt пользователь услышит просто «изображение» — и не поймёт, что на нём. По российскому ГОСТ Р 52872-2019 и международному WCAG 2.2 alt для содержательных изображений обязателен.

SEO. Поисковик не «видит» картинку — он читает alt, имя файла, окружающий текст и подпись. Alt — основной сигнал о том, что изображено. По нему картинка попадает в поиск по картинкам, а страница получает дополнительный контекст для основного ранжирования.

Правила заполнения alt

• Опишите, что реально изображено. «Красный кроссовок Nike Air Max 90 вид сбоку», а не «фото товара».
• Коротко: 5–15 слов. Длинные простыни alt поисковики обрезают, скринридеры утомляют пользователя.
• Без «фото», «картинка», «изображение» в начале — это и так изображение.
• Ключ — уместно, один раз. Если карточка кроссовка — упомянуть «кроссовок Nike Air Max 90» естественно. Забивать alt десятком ключей — спам.
• Декоративным картинкам — пустой alt. Иконки-разделители, фоновые узоры: <img src="divider.svg" alt="">. Скринридер их пропустит, поисковик поймёт, что смысла нет.

Пример корректного тега:

<img src="/img/nike-air-max-90-red-side.jpg" alt="Красный кроссовок Nike Air Max 90 вид сбоку" width="800" height="600">

Чего избегать

• Одинаковый alt на десятках картинок («товар», «фото»).
• Ключи через запятую: «купить кроссовки, кроссовки москва, кроссовки недорого» — прямой сигнал спама.
• Копирование alt в атрибут title (см. следующий раздел).
• Alt длиной в абзац на 200 слов.

Атрибут title: нужен ли

Title у картинки — это всплывающая подсказка, которая появляется при наведении курсора. На мобильных не работает вообще (там нет курсора), на десктопе большинство пользователей его не видит, потому что не наводит.

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

Практический вывод: не тратьте время на заполнение title для каждой картинки. Если он нужен для конкретного UX-сценария (например, подсказка про интерактивный элемент) — заполните индивидуально. Массово дублировать alt в title — бессмысленно.

Имя файла

Имя файла — второй по важности сигнал после alt. Поисковик считывает его и использует как контекст. Правила простые.

• Транслит, не кириллица. krasnyj-krossovok-nike.jpg, а не красный-кроссовок-найк.jpg. Кириллица в URL превращается в %D0%BA%D1%80%... — это ломает читаемость, часть CDN и старых CMS с ней работают криво.
• Дефис как разделитель, не подчёркивание. Google официально говорит: - — разделитель слов, _ — соединитель. nike-air-max.jpg читается как два слова, nike_air_max.jpg — как одно.
• Ключ — уместно. Если товар — Nike Air Max 90, файл nike-air-max-90.jpg полезнее, чем IMG_20261016_083412.jpg с фотоаппарата.
• Длина — 3–6 слов. Слишком длинные имена (kupit-krossovki-nike-air-max-90-krasnye-nedorogo-v-moskve-s-dostavkoy.jpg) читаются как спам.
• Только строчные буквы, латиница, цифры, дефисы. Никаких пробелов, скобок, спецсимволов.

Плохо: IMG_1234 (2).JPG, Скриншот 2026-10-10 в 14.30.png, Photo_final_FINAL_v3.jpeg.
Хорошо: nike-air-max-90-red.jpg, seo-audit-dashboard.png, chek-list-shema.svg.

Форматы: JPEG, PNG, WebP, AVIF, SVG

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

JPEG

Классика для фотографий. Сжатие с потерями (lossy) — часть информации выбрасывается ради веса. Работает с плавными переходами цветов, градиентами, снимками камеры. Плохо справляется с резкими границами и текстом (появляются артефакты).

Уместно: фотографии товаров, портреты, пейзажи, скриншоты интерфейсов с фотографическим содержимым.

PNG

Сжатие без потерь (lossless) + поддержка прозрачности. Идеален для картинок с чёткими границами: логотипы, скриншоты интерфейсов, иконки со сложной формой, схемы. Весит существенно больше JPEG на фотографиях того же размера, поэтому фотки в PNG хранить не надо.

Уместно: логотипы, скриншоты приложений с UI-элементами, иконки, изображения с прозрачным фоном.

WebP

Разработан Google. Поддерживает и lossy, и lossless сжатие + прозрачность + анимацию. При том же визуальном качестве обычно даёт файлы на 25–35% меньше JPEG и на 20–50% меньше PNG. Поддерживается всеми современными браузерами (Chrome, Firefox, Safari 14+, Edge) — по состоянию на 2026 год фактически везде.

Уместно: везде, где раньше был JPEG или PNG. Единственная причина оставить старый формат — необходимость поддержки очень старых браузеров (IE11, Safari до 14), что для большинства проектов уже неактуально.

AVIF

Формат нового поколения на базе кодека AV1. При том же качестве обычно на 20–30% меньше WebP. Поддерживается в Chrome, Firefox, Safari 16.4+, Edge. На 2026 год поддержка достаточна для основного трафика, но для страховки используйте <picture> с фолбэком на WebP или JPEG.

Уместно: сайты, где скорость критична (e-commerce, медиа), готовые заморочиться с многоформатной выдачей.

SVG

Векторный формат — не пиксели, а математическое описание фигур. Масштабируется без потери качества на любых экранах (от Retina до 4K), весит копейки на простых формах.

Уместно: логотипы, иконки, простая инфографика, декоративные элементы. НЕ для фотографий — вектор для них не подходит.

Быстрая таблица

• Фото товара — WebP (fallback JPEG).
• Логотип с прозрачностью — SVG или WebP lossless.
• Скриншот интерфейса — WebP lossless или PNG.
• Иконка — SVG.
• Баннер главной с текстом — WebP или AVIF.
• Анимированная гифка — WebP animated или MP4.

Правильные размеры и адаптивная выдача

Самая частая и самая дорогая ошибка — отдавать 4000×3000 картинку в блоке, где она рендерится 800×600. Браузер загружает мегабайты, потом уменьшает картинку в памяти. Пользователь ждёт впустую.

Правило простое: физический размер картинки (в пикселях) должен соответствовать месту, где она показывается, с учётом Retina-экранов (умножить на 2).

Если баннер на десктопе — 1200 пикселей ширины, то картинка нужна 2400×N. Если превью товара в каталоге — 300 пикселей, то картинка 600×N достаточно.

srcset и picture

Одна проблема: на мобильном пользователю не нужна десктопная картинка на 2400 пикселей — там экран 400. Отдавать всем один размер — расточительно. Решение — атрибут srcset или тег <picture>.

srcset для одинакового формата. Браузер сам выберет нужный размер:

<img src="/img/hero-800.jpg"
     srcset="/img/hero-400.jpg 400w,
            /img/hero-800.jpg 800w,
            /img/hero-1600.jpg 1600w,
            /img/hero-2400.jpg 2400w"
     sizes="(max-width: 600px) 100vw, 800px"
     alt="Дашборд SEO Crawler на ноутбуке"
     width="800" height="450">

picture для разных форматов. Отдаём AVIF там, где поддерживается, WebP — на всех современных, JPEG — как последний фолбэк:

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Дашборд SEO Crawler" width="800" height="450">
</picture>

Обязательно указывайте width и height в HTML — браузер зарезервирует место, вёрстка не поедет при загрузке, показатель CLS (Cumulative Layout Shift) не пострадает.

Сжатие: lossy vs lossless

Два подхода к сжатию.

Lossless (без потерь) — оптимизация служебных данных файла, метаданных, повторяющихся паттернов. Пиксели остаются как есть, качество не меняется. Экономия — 10–30% от исходного веса. Подходит, когда картинку могут увеличивать и разглядывать (медицина, схемы, документы).

Lossy (с потерями) — часть визуальной информации отбрасывается по алгоритмам, незаметным для человеческого глаза. Экономия — 50–90% в зависимости от настроек. Стандарт для веба.

Инструменты

• Squoosh (squoosh.app) — бесплатный веб-инструмент от Google. Сравнение форматов и уровней качества в реальном времени, для разовых картинок незаменим.
• TinyPNG / TinyJPG (tinypng.com) — веб-сервис с хорошим алгоритмом lossy, бесплатно до 20 картинок за раз.
• imagemin — npm-пакет для автоматизации в сборке (webpack, Vite, Gulp). Ставится один раз, потом все картинки в проекте сжимаются автоматически.
• cwebp / avifenc — консольные утилиты для конвертации в WebP и AVIF. Ставятся через apt/brew.
• Sharp — JavaScript-библиотека для сервера. Ей пользуются Next.js, Nuxt, многие CMS для генерации разных размеров и форматов на лету.

Ориентир по качеству: для WebP/JPEG уровень 75–85 обычно неотличим на глаз от оригинала, но весит в 3–5 раз меньше. Ниже 60 — заметны артефакты.

Lazy loading — ленивая загрузка

Ленивая загрузка — картинка загружается не сразу со страницей, а когда пользователь до неё доскроллит. Экономит трафик, ускоряет первую отрисовку.

Нативный loading="lazy"

С 2019 года браузеры поддерживают ленивую загрузку без JavaScript — просто добавляете атрибут:

<img src="/img/product.webp" alt="Товар" loading="lazy" width="400" height="300">

Поддержка: Chrome, Firefox, Safari 15.4+, Edge — то есть на 2026 год везде. JS-либы для lazy loading больше не нужны в 95% случаев.

Что НЕ ленить

Картинки первого экрана (hero-баннер, логотип в шапке) ленить нельзя — они и так нужны сразу, а loading="lazy" заставит браузер отложить их запрос и ухудшит LCP.

LCP-картинку (та, что определяет Largest Contentful Paint — обычно самая большая на первом экране) наоборот — стоит пометить как приоритетную:

<img src="/img/hero.webp" alt="…" fetchpriority="high" width="1200" height="600">

Атрибут fetchpriority="high" говорит браузеру загружать эту картинку в первую очередь.

Правило

• Первый экран — без loading="lazy", LCP-картинке добавить fetchpriority="high".
• Всё остальное (второй экран и ниже) — loading="lazy".

CDN и WebP-конвертация на лету

Если вручную готовить AVIF, WebP и JPEG для каждой картинки, а потом писать <picture> в каждом шаблоне — уйдёт месяц на средний сайт. Решение — сервисы, которые делают это автоматически.

Cloudflare Images / Cloudflare Polish. При включении Polish (тариф Pro и выше) Cloudflare сам конвертирует картинки в WebP или AVIF на лету, в зависимости от того, что поддерживает браузер пользователя. Ничего в коде менять не надо.

Bunny.net Optimizer. Дешёвый CDN с фичей on-the-fly оптимизации: добавляете параметр в URL (?width=800&format=webp) — получаете нужный размер и формат.

imgproxy, Thumbor. Open-source-решения для самохоста. Ставятся на свой сервер, работают как прокси перед картинками.

Next.js Image, Nuxt Image. Встроенные компоненты фреймворков, которые генерируют разные размеры и форматы автоматически при сборке или на лету.

Экономия времени — многократная. Экономия трафика для пользователя — 30–70% в зависимости от исходного качества картинок.

Sitemap для изображений и Schema.org

Два способа помочь поисковикам быстрее и точнее индексировать картинки.

Image sitemap

Отдельный XML-файл или расширение основного sitemap.xml, где перечислены картинки на страницах. Формат по стандарту Google:

<url>
  <loc>https://site.ru/product/nike-air-max</loc>
  <image:image>
    <image:loc>https://site.ru/img/nike-air-max-90-red.webp</image:loc>
    <image:title>Кроссовки Nike Air Max 90 красные</image:title>
  </image:image>
</url>

Особенно полезно для интернет-магазинов и сайтов с большим количеством картинок, которые не всегда попадают в основной HTML (например, слайдер подгружает их через JS).

Schema.org ImageObject

Микроразметка для изображений на странице. Помогает поисковикам понять контекст, автора, лицензию. Пример JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://site.ru/img/nike-air-max-90-red.webp",
  "name": "Кроссовки Nike Air Max 90 красные",
  "description": "Классические кроссовки Nike Air Max 90 в красной расцветке, вид сбоку",
  "width": "800",
  "height": "600"
}

Про Schema.org в целом и синтаксис JSON-LD — в статье про микроразметку JSON-LD. Не забудьте также про og:image в мета-тегах для красивых превью в соцсетях — про это в материале про мета-теги для SEO.

Как проверить, что всё работает

Пять инструментов для контроля.

PageSpeed Insights (pagespeed.web.dev). Показывает LCP, вес картинок, даёт рекомендации по форматам и размерам. Первый экран проверки.

WebPageTest (webpagetest.org). Детальнее PageSpeed: покажет, в каком порядке грузятся ресурсы, где самая тяжёлая картинка, что тормозит.

Chrome DevTools → Network → Img. Открываете страницу в Chrome (F12), фильтруете сеть по типу Img — видите все картинки, их размер, время загрузки, формат. Быстро находит незажатые файлы.

Lighthouse (встроен в DevTools). Отдельная вкладка Performance даёт готовые рекомендации: «Serve images in next-gen formats», «Properly size images», «Efficiently encode images».

SEO Crawler. Обходит сайт и находит картинки без alt, крупные незажатые файлы, битые ссылки на изображения. Даёт список URL с проблемами, а не абстрактную оценку.

Проверять картинки удобно в рамках общего чек-листа — см. полный чек-лист SEO-аудита сайта.

Быстрая шпаргалка

• Формат. Фото — WebP или AVIF (fallback JPEG). Иконки/логотипы — SVG. Скриншоты — WebP lossless или PNG.
• Размер. Физический размер = размер отображения × 2 (для Retina). Не больше.
• srcset или picture для адаптивной выдачи.
• width и height в HTML — обязательно, чтобы не поехала вёрстка.
• alt — коротко, по делу, ключ уместно один раз. Декоративным — пустой alt="".
• Имя файла — транслит, дефисы, ключ в тему.
• loading="lazy" на всё, что ниже первого экрана.
• fetchpriority="high" на LCP-картинку первого экрана.
• Сжатие — качество 75–85 для WebP/JPEG.
• CDN с автоконвертацией — Cloudflare Polish, Bunny.net, imgproxy.
• Image sitemap для магазинов и сайтов с большим количеством картинок.
• Проверять — PageSpeed Insights, DevTools Network, SEO Crawler.

Часто задаваемые вопросы