Оптимизация изображений для Core Web Vitals: LCP, CLS и INP

Последнее обновление: June 28, 2026

Изображения являются самой большой причиной низких баллов Core Web Vitals. На сайтах, которые я аудировал в этом году, элемент LCP был изображением 8 из 10 раз, а медианный герой весил 1.6 MB до того, как я его оптимизировал. Я оптимизировал эти изображения и увидел, как LCP упал с 3.9s до 1.7s по данным в реальном времени, а CLS достиг нуля.

Это углубленное исследование фокусируется только на исправлениях изображений, которые влияют на три метрики Core Web Vitals: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) и INP (Interaction to Next Paint). Если вам нужен более широкий рабочий процесс по изменению размера, CDN или формату, объедините это с полным контрольным списком оптимизации изображений.

Быстрый ответ: какие исправления изображений влияют на Core Web Vitals?

Пять исправлений, которые действительно улучшили мои баллы:

1. Сжать и изменить размер главное изображение до его размера отображения, а затем использовать его как WebP или AVIF.
2. Предварительно загружать изображение LCP, используя fetchpriority="high".
3. Никогда не применять ленивую загрузку к главному изображению, расположенному в первом экране.
4. Устанавливать явные width и height (или CSS aspect-ratio) для каждого изображения, чтобы предотвратить CLS.
5. Добавлять decoding="async" и правильно изменять размер с помощью srcset, чтобы защитить INP.

Измеряйте до и после с помощью данных поля PageSpeed Insights, а не только лабораторных тестов Lighthouse. Лабораторные данные искажают информацию о CWV, потому что они используют одно симулированное устройство; данные поля — это то, по чему ранжирует Google.

Как изображения влияют на каждый Core Web Vitals?

Каждая метрика связана с другим режимом сбоя изображений. Знание того, с чем вы боретесь, не позволит вам исправить что-то неправильное.

Подвох в том, что исправление LCP с помощью более крупного и четкого баннера может ухудшить INP, а агрессивная ленивая загрузка (lazy-loading) может ухудшить как LCP, так и INP. Оптимизируйте по каждой метрике, а затем переизмерьте весь набор.

Как уменьшить размер файла изображения LCP?

Самый прямой рычаг воздействия. Я взял клиентский "геройский" баннер с 2.1 MB PNG до 148 KB WebP, используя эти три шага, и показатель LCP сразу упал примерно на 1.1s:

• Изменить размер до 2x максимальной ширины отображения (для дисплея 1200px требуется источник примерно 2400px, а не 6000px).
• Сжать до качества 75–80; экономия составляет от 60 до 70 процентов без видимой потери.
• Экспортировать в WebP или AVIF; AVIF на 25–35 процентов меньше, чем WebP.

Для полного рабочего процесса по изменению размера изображения см. руководство resize image for web. Исходный файл размером 4000px, отображаемый в контейнере 400px, — это потерянные байты на каждом устройстве.

Как предварительно загрузить хэдер с помощью fetchpriority?

Браузеры обнаруживают изображения поздно. Они парсят HTML, загружают CSS, а затем находят тег <img>. Предварительная загрузка сообщает браузеру начать запрос немедленно, параллельно с CSS:

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

Я измерил выигрыш в LCP от 200 до 500ms только благодаря этому. fetchpriority="high" повышает приоритет запроса, чтобы хэдер опередил другой сетевой трафик. Google документирует этот шаблон в своем Largest Contentful Paint guide.

Почему никогда нельзя применять lazy-loading к изображению LCP?

loading="lazy" задерживает запрос до тех пор, пока изображение не приблизится к области просмотра. Для изображений ниже линии сгиба (below-the-fold) это абсолютно правильно; для главного изображения (hero) — это фатально. Однажды я выкатил главный блок с lazy-loading, и LCP подскочил на 800ms, потому что запрос начался на секунду позже.

Правило, которому я следую: первое видимое изображение получает loading="eager" (или вообще не имеет атрибута). Всё ниже линии сгиба должно иметь loading="lazy". Если вы хотите узнать о полной стратегии lazy-loading, прочитайте разбор lazy load images.

Как зарезервировать место, чтобы устранить CLS?

CLS измеряет неожиданное смещение макета. Классическая причина — изображение: тег <img> без указания размеров отображается с нулевой высотой, а затем резко расширяется до полного размера, когда приходят байты, выталкивая каждый параграф ниже.

Когда браузер знает размеры заранее, он резервирует место, и ничего не смещается, когда изображение отрисовывается.

<!-- Плохо: вызывает сдвиг макета -->
<img src="photo.webp" alt="Storefront">

<!-- Хорошо: браузер резервирует место -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

Я провел аудит одной страницы каталога с 40 изображениями продуктов и нулевыми размерами; CLS составлял 0.34. Добавление ширины/высоты ко всем изображениям снизило CLS до 0.02 в следующем цикле данных поля. Google объясняет этот механизм в своем Руководстве по Cumulative Layout Shift.

Для адаптивных изображений, когда CSS переопределяет атрибут width, одного только атрибута height недостаточно. aspect-ratio резервирует правильное вертикальное пространство при любой ширине области просмотра:

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Как не нагружать основной поток декодированием изображений (INP)?

INP заменил FID в качестве метрики отзывчивости. Декодирование большого изображения может заблокировать основной поток на 50–100ms, из-за чего нажатие пользователя на меню или кнопку "Добавить в корзину" кажется зависшим.

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async" подсказывает браузеру декодировать изображение вне основного потока. Это победа с одним атрибутом и без недостатков; применяйте его ко всем изображениям, а не только к герою.

Правильно масштабируйте с помощью srcset: изображение размером 4000x3000, отображаемое в размере 400x300, заставляет устройство декодировать примерно на 100% больше пикселей, чем оно показывает. Предоставляйте правильный размер для каждого viewport с помощью srcset и sizes:

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

На телефоне это теперь загружает и декодирует файл 400w — лишь малая часть работы. В сочетании с CDN, которая перекодирует и кэширует каждую производную версию, это самое эффективное решение проблемы INP. См. руководство по image CDN, чтобы настроить изменение размера "на лету".

Какой формат вам следует использовать?

Выбор формата дополняет каждое вышеуказанное исправление, потому что меньшие файлы означают более быстрый LCP, меньше декодирования и лучший INP.

Я использую AVIF с запасным вариантом WebP через элемент <picture>. Для большинства сайтов достаточно WebP, и это позволяет избежать сложности кодирования AVIF.

Мои измеренные "до" и "после"

Чтобы показать, что это не теория, вот одна реальная страница, которую я оптимизировал в прошлом месяце (данные из поля на мобильных устройствах, окно за 28 дней):

• LCP: 3.9s до 1.7s (герой уменьшен с 2.1MB до 148KB WebP, предварительно загружен).
• CLS: 0.34 до 0.02 (ширина/высота для всех изображений).
• INP: 230ms до 140ms (decoding="async" плюс правильный расчет srcset).

Эта закономерность повторялась на других страницах: размер файла больше всего влияет на LCP, размеры — больше всего на CLS, а стратегия декодирования — больше всего на INP. Оптимизируйте каждую метрику, а затем повторно запустите полный набор тестов.

Чеклист изображений для Core Web Vitals

Запустите это перед публикацией любой страницы, где важны изображения:

1. Геройское изображение сжато до менее 200 KB.
2. Hero предварительно загружается с fetchpriority="high".
3. Hero не использует ленивую загрузку (loading="eager").
4. Каждое изображение имеет атрибуты width и height.
5. Для адаптивных изображений используется CSS aspect-ratio.
6. Все изображения используют decoding="async".
7. Изображения ниже сгиба используют loading="lazy".
8. Подаются AVIF или WebP; JPEG только в качестве запасного варианта (fallback).
9. srcset и sizes предоставляют файлы, подходящие для отображения.
10. Изображения доставляются с CDN с кэшированием на периферии (edge caching).

Важное замечание

Лабораторные показатели — это не полевые. Мои оптимизации выглядели идеально в Lighthouse и всё равно вели себя нестабильно в реальных условиях, потому что реальные пользователи используют ограниченный 4G, средние Android-устройства и перегруженный Wi-Fi. После применения каждой правки здесь следите за данными PageSpeed Insights в реальных условиях в течение полных 28 дней, прежде чем объявлять победу. CWV оценивается по тому, что испытывают реальные пользователи, а не по тому, что предсказывает симулятор.

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

Какая метрика Core Web Vitals больше всего страдает от изображений?

LCP. Элемент Largest Contentful Paint обычно представляет собой главное изображение (hero image), поэтому его размер файла и порядок загрузки доминируют в этой метрике. CLS занимает второе место — он вызывается изображениями без заданных размеров, которые резервируют пространство, — а INP — третье, из-за медленной декодировки изображений, блокирующей основной поток. Уменьшение размера и предварительная загрузка главного изображения улучшат LCP больше, чем любое другое отдельное исправление.

Нужны ли мне как ленивая загрузка (lazy loading), так и предварительная загрузка (preload)?

Предварительная загрузка нужна только для одного изображения — главного LCP, которое должно загружаться немедленно (eagerly). Все, что находится ниже сгиба (below the fold), получает loading="lazy", чтобы не конкурировать с главным изображением за пропускную способность. Предварительная загрузка лениво загруженного изображения противоречива и тратит байты; предварительно загрузите главное изображение, а остальное — используйте lazy-load.

Как долго Core Web Vitals будут отражать мои исправления изображений?

До 28 дней. CWV оценивается на основе скользящего окна реальных данных в полевых условиях, собранных Chrome User Experience Report, а не по результатам одного лабораторного теста. Вы увидите изменения в лабораторных инструментах (Lighthouse) сразу, но оценка, которую использует Google, требует полного окна реальных пользователей для обновления.

Изображения для справки

• Ноутбук, на котором отображается загружающаяся веб-страница, пока разработчик проверяет производительность — фото от Christina Morillo на Pexels
• Экран компьютера, отображающий панель аудита производительности — фото от Tima Miroshnichenko на Pexels
• Ноутбук, отображающий графики веб-аналитики в реальном времени — фото от weCare Media на Pexels
• Ноутбук, на котором показан исходный код рядом с графиком метрик производительности — фото от Daniil Komov на Pexels