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

Что такое WebP и зачем он нужен для оптимизации изображений

WebP — что за формат такой и почему вокруг него столько шума? Если коротко, это разработка Google, которая жмет картинки заметно сильнее старого доброго JPEG и при этом не съедает качество так, как мы привыкли. Сами авторы заявляют экономию веса в 25–35%, а на некоторых типах графики до половины. Для сайта разница ощутимая: страницы открываются быстрее, трафик пользователю обходится дешевле, сервер дышит свободнее. Именно поэтому оптимизация WebP стала за последние годы базовым пунктом любого технического аудита.

Анонсировали формат еще в 2010-м, но «нормально жить» он начал лет через семь, когда поддержку наконец-то докрутили все ключевые браузеры — Chrome, Firefox, Edge, Opera, а потом и Safari (с 14-й версии). Сегодня по данным caniuse.com изображения WebP без проблем открывает 96–97% пользователей. Старые страшилки про «у половины посетителей не отобразится» уже неактуальны — можно расслабиться и работать.

Внутри формат WebP устроен интересно. Есть два режима — с потерями (на базе видеокодека VP8) и без потерь (там собственный алгоритм). При этом WebP умеет в прозрачность как PNG и в анимацию как GIF, только весят такие файлы в разы меньше. Получается почти универсальная замена всему растровому зоопарку, который годами таскали с сайта на сайт.

Почему именно сейчас имеет смысл этим заниматься? Гугл уже давно прямым текстом говорит: Core Web Vitals — фактор ранжирования. А внутри Core Web Vitals главная боль большинства сайтов — это LCP, метрика времени отрисовки самого крупного элемента на первом экране. В девяти случаях из десяти этот «самый крупный элемент» — здоровенная картинка-обложка. Перевели ее в формат WebP — и метрика пошла вниз почти моментально, без переделки верстки и месяцев работы.

Когда использовать WebP, AVIF, JPEG, PNG и SVG

Выбор формата — это всегда история про конкретную задачу. Универсального ответа нет и не будет: одно подходит для фотографий, другое — для иконок, третье существует исключительно ради совместимости со старыми браузерами.

WebP и AVIF для современных сайтов

WebP и AVIF — два основных кандидата для свежей графики на современном сайте. Формат WebP уже стал фактически отраслевым стандартом, AVIF — следующая ступень, более молодая и более «прожорливая» в плане экономии веса.

Изображения WebP уместны почти везде:

• фотографии, баннеры, обложки материалов;
• иллюстрации в статьях и блогах;
• карточки товаров в e-commerce;
• любые сценарии, где важна максимально широкая совместимость.

AVIF имеет смысл, когда:

• проект упирается в трафик и каждый килобайт на счету;
• большая часть аудитории сидит с современных мобильных устройств;
• есть ресурс настроить полноценный fallback на WebP и JPEG.

При одинаковом визуальном качестве AVIF легче WebP примерно на 20–30%. Звучит заманчиво. Но поддержка пока около 90%, а старые версии Safari работают с ним капризно. Поэтому AVIF чаще ставят первым в цепочке, а изображения WebP идут следом — как страховка для случаев, когда AVIF не подхватился.

JPEG и PNG как fallback и форматы для отдельных сценариев

JPEG и PNG никуда не делись. Они работают в двух ролях: как запасной парашют для устаревших браузеров и как самостоятельный выбор в некоторых нишевых ситуациях.

JPEG имеет смысл использовать:

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

PNG держится в нише картинок с прозрачным фоном, скриншотов, графики с резкими гранями и встроенным текстом. WebP, конечно, прозрачность тоже умеет. Но на каких-нибудь мелких иконках с тонкими линиями PNG иногда выдает чуть более чистый результат — глаз дизайнера это ловит.

В реальной жизни JPEG и PNG чаще всего лежат рядом с изображениями WebP именно как страховка. Браузер посмотрел на список форматов в <picture>, понял, что AVIF и WebP не понимает, и спокойно подхватил JPEG. Никто ничего не заметил.

SVG для иконок, логотипов и простой графики

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

• логотипы;
• иконки интерфейса;
• инфографика, схемы, диаграммы;
• декоративные элементы оформления;
• любая графика, которая обязана выглядеть резко на экранах любой плотности.

Главные плюсы — мизерный вес (иконка может занимать сотню байт) и идеальная четкость при любом масштабировании. Бонусом SVG прекрасно стилизуется через CSS и анимируется через JavaScript. Современный фронтенд без него уже сложно представить.

Как оптимизация изображений влияет на скорость сайта и SEO

Графика — самая жирная часть среднестатистической веб-страницы. Соответственно, и эффект от ее ускорения самый заметный. Дальше пройдемся по конкретным метрикам, на которые влияет оптимизация изображений.

Вес изображений и время загрузки страницы

По свежим отчетам HTTP Archive, изображения дают примерно 40–60% от общего веса страниц в современном вебе. Десяток несжатых JPEG по полмегабайта — и страница уже весит 5–8 МБ. На мобильной 4G это 5–10 секунд загрузки, на честной 3G в электричке между станциями — все 30.

Сжатие изображений в формат WebP с адекватными настройками срезает общий вес графики на 30–50%, и при этом разница на глаз не видна. Страница из категории «закрою и пойду к конкурентам» переходит в «нормально, грузится». Отказы падают, глубина просмотра растет — а вместе с ними и поведенческие сигналы для поисковиков.

Влияние изображений на LCP и Core Web Vitals

LCP — это время отрисовки самого большого элемента в видимой области. В 80% случаев этим элементом оказывается главная картинка на первом экране. Логика простая: что увидел пользователь раньше всего, то и считается «контентом».

Google требует уложиться в 2,5 секунды для зеленой оценки. Hero-баннер весом 800 КБ в JPEG на средней мобильной связи спокойно дает LCP в 4–5 секунд — и метрика красная. Перегнали ту же картинку в формат WebP, получили 250 КБ — и LCP вернулся к 2,2 секунды. Никакой магии, просто арифметика.

И это только LCP. Картинки без указанных размеров порождают CLS — страница «прыгает» при загрузке, и это бесит пользователя сильнее, чем долгое ожидание. Тяжелая графика блокирует процессы рендеринга и портит FID/INP — отклик интерфейса на действия. В итоге одна ленивая работа с изображениями ломает сразу три метрики из набора Core Web Vitals.

Роль изображений в мобильном UX и конверсии

На мобильных все гораздо жестче, чем на десктопе. Пользователь с медленным интернетом или ограниченным тарифом не будет ждать. Он закроет вкладку, и вы про это никогда не узнаете — только посмотрите потом на странные отказы в Метрике.

Google в своих исследованиях посчитал: каждая секунда задержки на мобильном режет конверсию на 7–10%. Для интернет-магазина это прямые деньги. Грубо говоря, медленные картинки — это статья расхода, просто в неочевидной форме. Грамотное сжатие изображений возвращает скорость в комфортный диапазон, и часть этих денег остается у бизнеса.

Как внедрить WebP на сайте технически

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

Конвертация изображений в WebP

Способов получить изображения WebP из накопленного архива достаточно — от ручного перетаскивания файлов в браузер до автоматических пайплайнов на сервере.

Если файлов немного и нужно разово:

• Squoosh.app — бесплатный сервис от Google, удобно крутить параметры качества и смотреть результат на лету.
• Convertio, CloudConvert — пакетная обработка через веб-интерфейс.
• ImageMagick — консольная утилита для тех, кому комфортнее в терминале.

Если сайт на CMS и хочется автоматики:

• WordPress — ShortPixel, Smush, Imagify, WebP Express. Любой из плагинов закрывает базовый сценарий и берет на себя сжатие изображений при каждой новой загрузке.
• Bitrix — поддержка встроена начиная с 20-й версии.
• Tilda — WebP включается в настройках проекта.
• 1C-Bitrix, OpenCart, Joomla — есть расширения, которые сами конвертируют загруженные файлы.

Если есть свой сервер и пайплайн:

• модули ImageMagick или GD для PHP;
• утилита cwebp от Google;
• Docker-контейнеры для встраивания в CI/CD.

С параметрами сжатия не нужно мудрить. Для фотографий обычно достаточно качества 75–85, для иллюстраций и графики с текстом — 85–95. Ниже 70 опускаться не стоит: на больших однотонных областях вылезают артефакты, и пользователь это заметит.

Использование picture, srcset и responsive images

Стандартный способ подключить изображения WebP с автоматической страховкой — тег <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>

Браузер пройдется по списку сверху вниз и подхватит первый формат, который понимает. Если ничего из современного не подошло — спокойно покажет JPEG. Атрибуты width и height ставьте обязательно. Без них страница будет дергаться при загрузке, и за это Гугл наказывает через CLS.

Если хотите еще и адаптивность под разные экраны, добавьте srcset:

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

Браузер сам выберет нужный размер. На айфоне подтянется компактная 400-пиксельная версия, на десктопе с retina — полноразмерная 1600-пиксельная. Пользователь не ждет лишнего, вы не платите за лишний трафик — все довольны.

Настройка CDN, CMS и fallback для браузеров

Если проект серьезный и графики много, имеет смысл подключить CDN с автоматической обработкой картинок. Cloudflare Images, BunnyCDN, ImageKit, Cloudinary — выбор есть. Что они делают за вас:

• сами конвертируют загруженные файлы в WebP и AVIF;
• генерируют разные размеры под srcset;
• кэшируют картинки на edge-серверах поближе к пользователю;
• автоматически отдают нужный формат по заголовку Accept браузера.

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

Как выполнить SEO-оптимизацию изображений для сайта

SEO-оптимизация изображений — это не только про сжатие. Это еще и про метаданные, контекст, индексацию в поиске по картинкам и репутацию страницы в глазах робота. Полноценная оптимизация изображений для сайта складывается из работы с alt, именами файлов, sitemap и микроразметкой. Разберем по пунктам.

Alt text, имена файлов и контекст страницы

Alt — главный сигнал поисковику о том, что на картинке. Заодно он помогает людям со скринридерами. Хороший alt:

• описывает изображение по-человечески, без шаманизма;
• содержит ключевую фразу, если это уместно;
• не превышает 125 символов;
• не дублируется на разных картинках одной страницы.

Плохо: alt="image1", alt="фото", alt="купить телефон Москва дешево купить недорого".
Хорошо: alt="iPhone 15 Pro в синем цвете, вид сбоку".

Имена файлов — второй важный момент. IMG_3527.jpg ничего не говорит ни роботу, ни вашему коллеге, который полезет в архив через год. А вот iphone-15-pro-blue-side-view.webp — это уже информация. Латиница, дефисы вместо пробелов, осмысленные слова.

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

Image sitemap и индексация в Google Images

Image sitemap — это либо отдельный XML, либо расширение основного sitemap. В нем перечислены все значимые картинки сайта. Зачем нужно: ускоряет индексацию в Google Images и Яндекс.Картинках, особенно для больших каталогов.

Выглядит примерно так:

<url>
  <loc>https://example.com/page.html</loc>
  <image:image>
    <image:loc>https://example.com/photo.webp</image:loc>
    <image:title>Название изображения</image:title>
    <image:caption>Подпись или описание</image:caption>
  </image:image>
</url>

После сборки sitemap скармливается Google Search Console и Яндекс.Вебмастеру. Для интернет-магазинов с тысячами карточек это не «приятная опция», а обязательный пункт — иначе робот тупо не доберется до большей части графики.

Open Graph, schema.org ImageObject и визуальное представление страницы

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

<meta property="og:image" content="https://example.com/share-image.webp">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

Рекомендованный размер — 1200?630, вес до 1 МБ. Один нюанс: соцсети не очень дружат с WebP в превью, до сих пор. Поэтому для og:image многие на всякий случай оставляют JPEG — спокойнее.

Schema.org ImageObject — это уже разметка для поисковиков. Она дает дополнительный контекст и иногда помогает попасть в расширенные сниппеты или карусели:

{
  "@type": "ImageObject",
  "url": "https://example.com/photo.webp",
  "width": 1200,
  "height": 800,
  "caption": "Описание изображения",
  "author": "Имя автора"
}

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

Как настроить загрузку изображений без потери производительности

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

Lazy loading для изображений ниже первого экрана

Lazy loading — это когда картинка не загружается, пока пользователь до нее не доскроллил. На длинной статье с двадцатью иллюстрациями экономия огромная: вместо одновременной загрузки 20 МБ графики браузер тащит только то, что реально нужно прямо сейчас.

Современные браузеры умеют это нативно, через простой атрибут:

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

Никаких библиотек, никакого JavaScript. Chrome, Firefox, Edge, Safari (с iOS 15.4) — все работает из коробки.

И сразу важный момент, на котором спотыкаются многие. Lazy loading нельзя ставить на картинки первого экрана. Особенно на ту, что формирует LCP. Иначе браузер отложит загрузку самой важной для пользователя графики, и метрика уйдет в красное. То есть оптимизация загрузки изображений ради скорости в итоге убьет скорость. Бывает.

Preload и fetchpriority для LCP-изображений

Для главной картинки первого экрана логика обратная — ее надо тащить как можно раньше. Для этого есть preload и атрибут fetchpriority:

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

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

Связка работает железно: preload и fetchpriority для главной картинки, lazy loading для всего, что ниже первого экрана. Первый экран летит, остальное подтягивается по мере чтения. Это и есть нормальная оптимизация загрузки изображений в одном предложении.

Кэширование и контроль размера файлов

Кэширование настраивается через HTTP-заголовки. Тут стандартный набор:

• Cache-Control: public, max-age=31536000, immutable — год кэширования для файлов, которые не меняются;
• ETag или Last-Modified — проверка актуальности версии;
• хеш в имени файла (типа photo.a3f7b9.webp) — для принудительного обновления, когда картинка реально поменялась.

Размер файлов лучше держать в адекватных рамках еще на этапе загрузки:

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

Как проверить качество оптимизации WebP и изображений

Без замеров вся работа превращается в гадание. Хорошо, что инструментов хватает — и бесплатных, и платных. SEO-оптимизация изображений без регулярного аудита быстро откатывается обратно: контент-менеджеры загружают новые файлы, разработчики правят шаблоны, и где-то обязательно что-то ломается.

Аудит в PageSpeed Insights и Lighthouse

PageSpeed Insights от Google — главный бесплатный инструмент, к которому стоит привыкнуть. Что он показывает:

• баллы по разделам Performance, Accessibility, Best Practices, SEO;
• метрики Core Web Vitals — LCP, CLS, INP;
• конкретные проблемы с графикой: что весит слишком много, что не в современном формате, что не того размера;
• рекомендации с указанием, сколько килобайт можно сэкономить.

Lighthouse — это, по сути, тот же движок, но встроенный прямо в Chrome DevTools. Удобно для частых проверок в процессе работы — не надо никуда ходить, все под рукой.

Особенно полезные пункты в отчете: «Defer offscreen images», «Properly size images», «Serve images in next-gen formats». Если они подсвечены красным — там точно есть что улучшать, и обычно речь именно про сжатие изображений и перевод их в современный формат.

Проверка Core Web Vitals после внедрения

Реальные данные о Core Web Vitals лежат в Google Search Console, в разделе «Удобство страниц». Это важная разница: PageSpeed и Lighthouse делают синтетический тест в идеальных условиях, а Search Console собирает статистику с реальных пользователей. Field Data, как это называется.

После внедрения изображений WebP типичная картина выглядит так:

• LCP падает на 20–40% — почти исключительно за счет более легкой главной картинки;
• CLS уходит к нулю, если правильно проставили width и height;
• общий вес страниц снижается на 30–50%.

Устойчивый результат виден через 2–4 недели. Раньше — мало накопленных сессий, выводы делать рано.

Типичные ошибки при оптимизации изображений

Самые частые косяки, которые сводят на нет всю проделанную работу:

• слишком агрессивное сжатие — пользователь видит «грязь» на изображениях и пишет в поддержку;
• забытый fallback на JPEG — у части аудитории картинки не отображаются вообще;
• одна и та же картинка для всех устройств вместо srcset;
• пропущенные width и height — здравствуй, CLS;
• lazy loading на главной картинке первого экрана — пока, LCP;
• забытые alt-атрибуты — нет индексации в поиске по картинкам;
• одинаковые имена файлов для разных изображений — каша в индексе;
• старая JPEG-версия, которая по инерции грузится параллельно с WebP — вес страницы не падает, хотя должен.

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

Заключение

Оптимизация изображений — это не разовая акция, а привычка. Один раз перегнали все в формат WebP — отлично. Через полгода контент-менеджеры загрузили сотню новых картинок в JPEG по 2 МБ каждая — и метрики снова в красной зоне. Поэтому процесс надо встроить в рутину: автоматическая конвертация на этапе загрузки, периодический аудит через PageSpeed, регулярная проверка Core Web Vitals в Search Console.

Главное — не пытаться накрыть все одним движением. Подключите CDN или плагин CMS для автоматики, разберитесь с тегом <picture> и атрибутами для адаптивности, аккуратно расставьте lazy loading и preload там, где они уместны. Маленькие шаги по очереди дают устойчивый результат. Большая «революция» за один день обычно заканчивается тем, что что-то ломается и потом неделями ищется причина.

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

Константин Крючков

Senior SEO-специалист

Подписаться на ТГ