Alt-текст почти не влияет на позиции страницы напрямую, зато напрямую влияет на трафик из поиска по картинкам и на доступность. Формат WebP/AVIF и правильный размер файла — это то, что реально двигает LCP и Core Web Vitals. Lazy-loading на hero-картинке (первый экран) убивает LCP, а не улучшает его — частая ошибка на карточках товара.
Картинки на сайте правят либо никак (загрузили исходник из CRM 4000×3000 и забыли), либо по мифам из статей 2016 года про «ключ в alt = плюс в ранжирование». Разбираем, что из этого реально имеет значение в 2026.
Зачем вообще этим заниматься
Три причины, в порядке реального веса: во-первых, картинки — это часто самый тяжёлый элемент страницы, и они определяют LCP (Largest Contentful Paint) — один из трёх метрик Core Web Vitals, прямого фактора ранжирования Google. Во-вторых, Google Images — отдельный источник трафика, иногда больше, чем веб-поиск, особенно для интернет-магазинов и визуального контента. В-третьих, альт-тексты — часть доступности сайта для людей с нарушениями зрения, это не про позиции, но это закон в некоторых юрисдикциях и просто порядочность.
Alt-текст: что реально работает
Alt — это описание содержания картинки для тех, кто её не видит (скринридер, медленный интернет, отключённые изображения). Он не прямой фактор ранжирования текстовой страницы — забудь миф «вписал ключ в alt — вырос в топе». Зато это основной текстовый сигнал для Google Images, где решается, покажут ли твою картинку по визуальному запросу.
- Описывай содержание, а не напичкивай ключами. «Белый кухонный гарнитур с островом в современном стиле» — норм. «Кухня кухонный гарнитур купить Минск цена» — спам, и Google такое режет точно так же, как в тексте.
- Декоративные элементы — пустой alt (
alt=""), не отсутствие атрибута вообще. Скринридер должен понимать, что элемент декоративный и пропускать его, а не читать имя файла вслух. - Для карточек товара — включай отличительный признак, не общее название категории. «Кроссовки Nike Air Max 270, синие, вид сбоку» лучше чем просто «кроссовки» на всех 40 карточках модели в разных цветах.
Формат файла: WebP и AVIF против JPEG и PNG
Вот где реальный вес для скорости. WebP при сравнимом визуальном качестве весит на 25-35% меньше JPEG, AVIF — ещё на 20-30% меньше WebP в среднем. На практике для карточки товара с 5-6 фото это разница между 2 МБ и 600 КБ суммарного веса страницы — заметна на мобильном 4G сразу.
Браузерная поддержка в 2026 уже не проблема — WebP поддерживают все современные браузеры, AVIF почти все. Правильная реализация — тег <picture> с fallback на JPEG для древних версий или просто отдача WebP всем (поддержка >97% трафика на большинстве сайтов). Многие CMS (включая 1С-Битрикс и большинство магазинных платформ) конвертируют автоматически через модули — проверь, включено ли это у тебя, а не предполагай, что «наверное, по умолчанию так».
Lazy-loading: где помогает, а где убивает LCP
Атрибут loading="lazy" откладывает загрузку картинки до момента, когда она подъезжает к области видимости. Отличная идея для картинок в середине и конце длинной страницы — браузер не тратит ресурсы на то, что пользователь может вообще не долистать.
Плохая идея — та же самая атрибут на hero-картинке, главном изображении первого экрана. Именно эта картинка почти всегда и есть LCP-элемент — то, что браузер должен показать как можно быстрее. Повесив на неё lazy-load, ты говоришь браузеру «не торопись её загружать», а потом та же картинка — твой самый важный метрика скорости. Результат — LCP растёт, а не падает.
Правильно: на hero-изображении — никакого loading="lazy", а по возможности ещё и fetchpriority="high", чтобы браузер явно понял приоритет. На всём, что ниже первого экрана — lazy грузим смело.
| Приём | Что даёт | Частая ошибка |
|---|---|---|
| Alt-текст | Трафик из Google Images, доступность | Keyword stuffing вместо описания |
| WebP/AVIF | Меньше вес страницы, лучше LCP | Конвертация не включена в CMS, грузят исходники |
| Resize под реальный размер вывода | Не грузить 4000px картинку в блок 400px | Берут фото из CRM как есть |
| loading="lazy" | Экономия на картинках ниже экрана | Ставят и на hero-картинку — убивает LCP |
| Понятное имя файла | Доп. сигнал для Google Images | IMG_8743.jpg вместо chernoe-plate-midi.jpg |
Имя файла — мелочь, которую все игнорируют
Файл IMG_20260512_143022.jpg не даёт поисковику вообще никакого контекста. Файл chernoe-vecherneye-plate-midi.jpg даёт дополнительный текстовый сигнал, который суммируется с alt-текстом и окружающим контентом страницы. Это не решит исход борьбы за топ само по себе, но это бесплатно и занимает пять секунд при выгрузке — нет причины этого не делать.
Полгода назад разбирал каталог мебельного интернет-магазина — карточки товара грузили исходники прямо из CRM, 4000×3000 пикселей, без единого ресайза, в формате JPEG максимального качества. LCP на мобильном замере — 6.8 секунды, это уже не «медленно», это «страница не загрузилась, пока ты не психанул и не закрыл вкладку». Поменяли на WebP с resize до реального размера вывода (максимум 1200px по длинной стороне) — LCP упал до 2.1 секунды. Позиции сдвинулись не мгновенно, но органический CTR с мобильного поиска подрос в течение следующего месяца — сниппет с хорошим LCP реже проигрывает конкуренту в поведенческих факторах.
Ты вообще смотрел, в каком формате и каким весом у тебя грузятся картинки на карточках товара, или просто доверяешь тому, что «разработчики всё сделали правильно»?
loading="lazy". Проверяется за 10 секунд через DevTools → вкладка «Сеть» → смотришь, когда грузится первая картинка экрана. Если позже текста — это она и есть, твоя проблема с LCP.
Картинки — не самостоятельный фактор, который сам по себе вытащит сайт в топ. Но на фоне конкурентов с одинаковым контентом разница в LCP на 3-4 секунды — это разница между сайтом, который открылся, и сайтом, с которого ушли до того, как он успел это сделать.
Хочешь аудит скорости и картинок на своём сайте — пиши на mostlycorp@gmail.com. Обычно хватает часа через DevTools, чтобы найти все больные места.