Животные меняются при загрузке страницы
Оптимизация изображений для мобильного поиска: WebP + lazy‑loading
Карточки, чек-листы, таблицы и примеры помогают быстро найти нужный ответ.
Мобильный поиск стал ключевым фактором ранжирования. Сжатие изображений и отложенная загрузка – два простых, но мощных способа ускорить сайт и улучшить пользовательский опыт.
Главные шаги: 1) анализировать текущую нагрузку изображений, 2) конвертировать в WebP с учётом качества, 3) внедрять lazy‑loading через атрибуты и IntersectionObserver, 4) кэшировать контент на CDN, 5) проверять Core Web Vitals и корректировать.
Понимание требований мобильного поиска
Core Web Vitals — три метрики, которые Google использует как сигнал качества пользовательского опыта: Largest Contentful Paint (LCP), First Input Delay (FID) и Cumulative Layout Shift (CLS). На мобильных страницах они особенно важны, потому что большинство запросов теперь приходят с устройств с ограниченной пропускной способностью и меньшим экраном. Если LCP превышает 2,5 с, FID выше 100 мс или CLS выше 0,1, страница может получить «негативный» сигнал в Page Experience, что напрямую снижает позицию в поиске.
Изображения часто становятся главной причиной ухудшения этих показателей. Большие файлы, не сжатые или с неподходящим форматом, блокируют рендеринг, заставляя браузер ждать, пока загрузится самый крупный элемент, что удлиняет LCP. На слабых сетях мобильных операторов даже 300 кБ изображения могут занимать десятки секунд, а при отсутствии оптимизации изображения могут сдвигать контент во время загрузки, увеличивая CLS. Кроме того, каждая лишняя загрузка увеличивает общий объём трафика, что влечёт за счёт мобильных операторов дополнительные расходы и тормозит последующие запросы.
Оптимизация изображений для мобильного поиска начинается с понимания того, что мобильные пользователи ожидают мгновенной отдачи. Если LCP превышает порог, поисковый робот может считать страницу «медленной» и отдать предпочтение более быстрым конкурентам. Поэтому важно не только уменьшить размер файлов, но и убедиться, что они загружаются только тогда, когда пользователь их увидит, и в формате, который поддерживается большинством браузеров. Это снижает нагрузку на сеть, ускоряет рендеринг и повышает шансы на лучшую позицию в мобильном поиске.
Выбор формата WebP: когда и как
WebP – это формат, созданный Google, который объединяет возможности JPEG и PNG в одном файле. Он поддерживается почти всеми современными браузерами: Chrome, Edge, Firefox, Opera, а также Safari начиная с версии 14 и Android‑Chrome с 2017 года. На iOS Safari WebP доступен только в режиме “WebP‑Only” (из‑за ограничений MIME‑типов). Для старых браузеров, которые не распознают MIME‑тип image/webp, применяют <picture>‑элемент: сначала указывают <source type="image/webp">, затем <img src="fallback.jpg">. В noscript‑блоке можно добавить стандартный <img>‑тег, чтобы гарантировать отображение даже без JavaScript. Для поисковых систем важно, чтобы MIME‑тип был корректно указан в заголовках сервера; иначе Google может не распознать WebP как валидный ресурс.
| Формат | Тип сжатия | Оценка размера (сравнительно) | Качество при 80% качества JPEG | Типичные случаи использования |
|---|---|---|---|---|
| JPEG | Потерянное (lossy) | 100 % | 80 % (сравнение по PSNR) | Фотографии, динамичные сцены |
| PNG | Без потерь (lossless) | 110 %–120 % | 100 % | Иконки, графика с прозрачностью, текстовые изображения |
| WebP (lossy) | Потерянное (lossy) | ≈65 %–70 % от JPEG | ≈80 % (сравнение по PSNR) | Фотографии, фоновые изображения, hero‑блоки |
| WebP (lossless) | Без потерь (lossless) | ≈70 %–80 % от PNG | 100 % | Иконки, SVG‑заменители, графика с прозрачностью |
Преобразование и автоматизация конвертации
- Установить инструменты: imagemin, Sharp, ImageMagick, npm‑пакеты
imagemin-webp,sharp,gm. - Создать скрипт
scripts/convert-images.js: - Внутри скрипта пройти по
src/assets/images, для каждого файла: - • Если расширение
.jpgили.png, сгенерировать.webpс оптимизацией 80‑90%. - • Сохранить оригинал и WebP в
dist/assets/images, добавив вsrcsetатрибуты. - • Если файл уже WebP, пропустить.
- После конвертации запустить
npx imageminдля минификации PNG/JPG. - В шаблонах заменить
<img src="…">на<img src="…webp" srcset="…webp 1x, …webp 2x" loading="lazy">. - В CI/CD (GitHub Actions, GitLab CI) добавить шаг
node scripts/convert-images.jsдо сборки. - Проверить результат: в
dist/assets/imagesдолжны появиться файлы.webp, размер уменьшен, в исходниках атрибутloading="lazy"присутствует.
const fs = require('fs');
const path = require('path');
const sharp = require('sharp');
const imagemin = require('imagemin');
const imageminWebp = require('imagemin-webp');
const srcDir = path.join(__dirname, '..', 'src', 'assets', 'images');
const outDir = path.join(__dirname, '..', 'dist', 'assets', 'images');
async function convert() {
const files = fs.readdirSync(srcDir);
for (const file of files) {
const ext = path.extname(file).toLowerCase();
if (!['.jpg', '.jpeg', '.png'].includes(ext)) continue;
const input = path.join(srcDir, file);
const base = path.basename(file, ext);
const outWebp = path.join(outDir, `${base}.webp`);
await sharp(input)
.webp({ quality: 85 })
.toFile(outWebp);
}
await imagemin([path.join(outDir, '**/*.{jpg,png}')], {
destination: outDir,
plugins: [imageminWebp({ quality: 80 })]
});
}
convert().catch(console.error);Lazy‑loading: принципы и реализация
- Добавьте атрибут
loading="lazy"к каждому<img>в шаблоне. Это сразу активирует нативный lazy‑loading в современных браузерах. - Для поддержки старых браузеров подключите скрипт IntersectionObserver, который будет ставить
srcтолько при пересечении изображения с областью видимости. В SSR‑режиме выводитеdata-srcвместоsrcи<noscript>‑fallback с полной картинкой. - Проверьте работу: откройте страницу в DevTools → Network, отфильтруйте по
imgи убедитесь, что файлы загружаются только при скролле. В Lighthouse включите аудит «Lazy loaded images» и посмотрите, что все изображения считаются lazy‑loaded.
<img src="image.webp" alt="Пример" loading="lazy">
<script>
(function(){
if('loading' in HTMLImageElement.prototype) return;
const imgs = document.querySelectorAll('img[data-src]');
const observer = new IntersectionObserver((entries, obs)=>{
entries.forEach(entry=>{
if(entry.isIntersecting){
const img = entry.target;
img.src = img.dataset.src;
img.removeAttribute('data-src');
obs.unobserve(img);
}
});
},{rootMargin:'200px'});
imgs.forEach(img=>observer.observe(img));
})();
</script>
<img src="placeholder.jpg" data-src="image.webp" alt="Пример" loading="lazy">
<noscript><img src="image.webp" alt="Пример"></noscript>
Кэширование и CDN‑оптимизация изображений
Cache‑control, ETag и версии файлов – ключи для долгосрочного кэширования. Когда браузер запрашивает изображение, сервер отвечает заголовками, которые определяют, как долго его хранить. Cache‑control: max‑age, s‑maxage, must‑revalidate. ETag: уникальный идентификатор версии. Если файл меняется, генерируется новый ETag, и клиенту отправляется 304. Версионирование через имя файла (example‑v2.webp) гарантирует, что старый кэш не будет использоваться, даже если ETag не меняется. Edge‑кэширование в CDN – копирует файлы ближе к пользователю, но при изменении контента важно правильно настроить правила invalidation. Обычно при релизе меняется имя файла или обновляется ETag, а в настройках CDN указывают правила purge по паттерну *.webp. Это позволяет быстро удалить устаревшие копии из edge‑серверов и заставить их запрашивать свежую версию. Без корректных заголовков и invalidation может возникнуть ситуация, когда пользователи видят старые изображения, а поисковые боты получают 200 с устаревшими данными, что негативно влияет на индексацию и пользовательский опыт.
Проверка производительности и Core Web Vitals
Перед публикацией убедитесь, что изображения в WebP и с lazy‑loading отвечают Core Web Vitals. Используйте Lighthouse, PageSpeed Insights и RUM, чтобы измерить LCP и CLS и сравнить их с порогами: LCP
- Запустите Lighthouse в Chrome DevTools на мобильном устройстве, включив опцию «Mobile» и «Fast 3G».
- Проверьте результаты в PageSpeed Insights, выбрав «Mobile» и «Fast 3G».
- Соберите RUM‑данные через GA4 или собственный сервис, чтобы увидеть реальные LCP и CLS в разных сетевых условиях.
- Убедитесь, что изображения имеют атрибуты loading="lazy" и srcset с WebP‑вариантами.
- Проверьте, что MIME‑тип для WebP — image/webp, а для PNG/JPG — image/png/image/jpeg.
- Проверьте, что не возникает layout‑shift из-за динамических размеров изображений.
- Сравните показатели LCP и CLS с порогами из таблицы ниже.
| Параметр | Пороговое значение |
|---|---|
| Largest Contentful Paint (LCP) | меньше 2.5 с |
| Cumulative Layout Shift (CLS) | меньше 0.1 |
| Общее количество layout‑shift элементов | 0 |
| Процент WebP‑изображений | ≥ 70 % |
| Процент изображений с lazy‑loading | ≥ 90 % |
SEO‑риски и как их избежать
- Отсутствие alt‑тегов и дублирование: без описания поисковые боты не распознают контекст, а одинаковые alt‑теги создают канонические проблемы. Убедитесь, что каждая картинка имеет уникальный, описательный alt, отражающий смысл изображения.
- Неправильная lazy‑загрузка и broken links: если скрипт не инициализируется до первого скролла, поисковый бот не видит контент, а broken links ломают структуру. Используйте атрибуты loading="lazy" и проверяйте, что URL остаётся валидным до загрузки.
- Перегрузка качества и потеря семантики: слишком высокий битрейт WebP оборачивает изображение, но при этом теряется семантическая информация, если изображение содержит текст. Снижайте качество до 80–85 % и сохраняйте текст в отдельном alt‑теге.
Мониторинг после релиза и корректировка
После внедрения WebP и lazy‑loading ключевой задачей становится проверка того, как поисковые боты и пользователи реагируют на изменения. В Search Console в разделе «Изображения» ищите ошибки 404 и убедитесь, что новые файлы попадают в индекс. В Google Analytics отслеживайте Bounce‑rate и среднее время на странице – снижение отказов и рост времени свидетельствуют о лучшем UX. Периодический аудит – это цикл: каждые 4–6 недель пересматривайте отчёты, корректируйте атрибуты, обновляйте sitemap, если появилось новое изображение.
- В Search Console: наличие ошибок 404 для WebP‑файлов.
- В Search Console: количество проиндексированных изображений.
- В GA: Bounce‑rate по страницам с изображениями.
- В GA: среднее время на странице.
- Core Web Vitals: LCP, CLS, FID.
- Lighthouse: показатели скорости и доступности изображений.
- Код: наличие атрибутов loading="lazy" и srcset.
- Сайтмап: ссылки на изображения присутствуют.
- Сервисный воркер: кэширование WebP‑файлов.
Вопросы и ответы
Как убедиться, что поисковые роботы видят изображения после внедрения lazy-loading?
Проверьте страницу в Google Search Console через URL Inspection и Rich Results Test. Убедитесь, что теги <img> присутствуют в отрендеренном HTML и что robots.txt не блокирует их. Также важно, чтобы скрипт lazy‑loading не задерживал загрузку изображения дольше, чем Googlebot может обработать.
Можно ли использовать WebP для всех типов изображений, включая графику и логотипы?
WebP отлично подходит для фотографий, но для логотипов и сложной графики с прозрачным фоном PNG иногда предпочтительнее, особенно если требуется точная цветовая передача. Старые браузеры могут не поддерживать WebP, поэтому стоит сохранять резервный PNG.
Как проверить, что WebP-изображения корректно загружаются на мобильных устройствах?
Откройте страницу в мобильном браузере, включите инструменты разработчика и перейдите во вкладку Network. Убедитесь, что MIME‑тип image/webp и размер файла меньше, чем оригинальный PNG/JPG, и что изображение отображается без ошибок.
Что делать, если поисковый робот не индексирует изображения с lazy‑loading?
Убедитесь, что изображения находятся в пределах видимой части DOM и не загружаются только при скролле. Добавьте атрибут srcset с базовым изображением и используйте <noscript> fallback, чтобы бот видел контент.
Как оптимизировать размер WebP-изображений без потери качества?
Используйте утилиту cwebp с параметром -q 80‑90. Проводите A/B тесты, сравнивая визуальное качество при разных значениях. Сохраняйте оригинал для резервного fallback, если требуется точная цветопередача.
Нужно ли использовать lazy‑loading для всех изображений на странице?
Lazy‑loading полезен для больших списков изображений, но для hero‑изображений и логотипов, которые находятся в видимой области, лучше оставить их сразу, чтобы не задерживать рендер и не ухудшать UX.
Как убедиться, что изображения с WebP доступны для поисковых систем?
Включите URL‑адреса изображений в формате WebP в sitemap и проверьте через Search Console, что они индексируются. Убедитесь, что robots.txt не блокирует папку с WebP, иначе бот не сможет их прочитать.
Какие проблемы могут возникнуть при использовании WebP в старых браузерах?
Старые версии IE и Safari до 14 не поддерживают WebP. Для них необходимо задать fallback через <picture> с <source type="image/png">. Это гарантирует, что пользователь увидит изображение, но может увеличить размер страницы.
Как правильно настроить lazy‑loading для изображений с прозрачным фоном?
Используйте атрибут loading="lazy" и убедитесь, что placeholder имеет тот же размер, чтобы избежать смещения контента. Для PNG с альфа‑каналом лучше оставить без lazy, если они важны для UX и не занимают много места.
Как измерить влияние WebP и lazy‑loading на скорость загрузки?
Запустите Lighthouse или PageSpeed Insights до и после изменений. Сравните показатели First Contentful Paint и Largest Contentful Paint, а также размер страницы и количество запросов. Это даст объективную оценку улучшений.
Важно
Материал носит информационный характер. Перед внедрением рекомендаций учитывайте нишу, регион, конкурентов, текущее состояние сайта и бизнес-цели проекта.
Материал подготовлен и проверен редакцией AX.SEO
Редакция AX.SEO готовит материалы о SEO, разработке, AI, аналитике, маркетинге и росте digital-проектов.
Проверяет практическую применимость рекомендаций, корректность терминов и соответствие материала digital-тематике.