Загрузка...
Загрузка...
Полное руководство по оптимизации Largest Contentful Paint. Причины медленного LCP, методы диагностики, практические решения для изображений, шрифтов и серверной инфраструктуры.
Практическое руководство по устранению Cumulative Layout Shift. Диагностика причин сдвигов макета, резервирование размеров, оптимизация шрифтов и динамического контента.
SEOПрактическое руководство по оптимизации INP — метрики отзывчивости интерфейса. Причины задержек, разбиение длинных задач, оптимизация JavaScript и обработчиков событий.
SEOСравнение WebP и AVIF: сжатие, поддержка браузерами, конвертация, fallback. Практические рекомендации для веб-разработки.
SEOПодробное руководство по оптимизации изображений для поисковых систем. WebP, сжатие, lazy loading, alt-теги и другие техники для улучшения SEO и производительности сайтов.
Поделитесь с коллегами или изучите другие материалы блога
Largest Contentful Paint (LCP) — ключевая метрика Core Web Vitals, измеряющая время отрисовки самого крупного видимого элемента на странице. Google использует LCP как фактор ранжирования с 2021 года, и в 2026 требования остаются строгими: хороший показатель — не более 2.5 секунды. В этом руководстве разберём практические методы оптимизации LCP от диагностики до внедрения.
LCP фиксирует момент, когда основной контент страницы становится видимым пользователю. Обычно это hero-изображение, крупный заголовок или блок текста. Метрика отражает воспринимаемую скорость загрузки — пользователь оценивает сайт как быстрый, если главный контент появляется быстро.
| Оценка | Время LCP | Влияние на SEO |
|---|---|---|
| Хорошо | ≤ 2.5 с | Положительный сигнал |
| Требует улучшения | 2.5 – 4 с | Нейтральный |
| Плохо | > 4 с | Негативный фактор ранжирования |
Проверить LCP вашего сайта можно с помощью инструмента Web Vitals на reChecker. Анализ покажет текущие значения и подскажет направления оптимизации.
Перед оптимизацией необходимо выявить узкие места. Основные причины медленного LCP:
Time to First Byte — время от запроса до первого байта ответа. Если сервер отвечает дольше 600 мс, LCP неизбежно страдает.
# Проверка TTFB через curl
curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s "https://example.com"
Ресурсы в head без атрибутов async/defer блокируют парсинг HTML и отрисовку. Критический CSS должен быть инлайновым или загружаться с высоким приоритетом.
Крупные файлы, отсутствие современных форматов (WebP, AVIF), загрузка без приоритета — типичные проблемы. Используйте инструмент проверки изображений reChecker для аудита.
Шрифты блокируют отрисовку текста (FOIT — Flash of Invisible Text). Если LCP-элемент — текст, задержка шрифтов напрямую ухудшает метрику.
Браузер ограничивает количество одновременных соединений к одному домену (обычно 6). Если критический ресурс стоит в очереди за десятками других, LCP затягивается.
Изображения — самый частый LCP-элемент. Оптимизация даёт наибольший эффект.
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Главное изображение" fetchpriority="high" width="1200" height="630">
</picture>
AVIF даёт сжатие на 20–50% лучше JPEG при том же качестве. WebP — универсальная альтернатива с поддержкой во всех современных браузерах.
Для LCP-изображения явно указывайте высокий приоритет:
<img src="hero.jpg" alt="Hero" fetchpriority="high" loading="eager">
По умолчанию браузер загружает изображения с низким приоритетом. fetchpriority="high" поднимает LCP-картинку в начало очереди.
Всегда указывайте размеры — это предотвращает layout shift (CLS) и позволяет браузеру резервировать место до загрузки:
<img src="hero.jpg" alt="Hero" width="1200" height="630" fetchpriority="high">
Если изображение критично и находится в начале документа:
<link rel="preload" as="image" href="/hero.avif" type="image/avif">
Preload заставляет браузер начать загрузку до обнаружения тега img в HTML.
Для изображений ниже первого экрана используйте lazy loading — они не должны конкурировать за bandwidth с LCP:
<img src="product.jpg" alt="Товар" loading="lazy" width="400" height="400">
LCP-элемент не должен иметь loading="lazy" — иначе метрика будет измерять задержку до скролла.
Размещение статики на CDN сокращает RTT. Кэширование HTML и критических ресурсов снижает TTFB при повторных визитах.
# Nginx: кэш статики
location ~* \.(jpg|jpeg|png|webp|avif|css|js)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
Мультиплексирование позволяет загружать множество ресурсов параллельно по одному соединению. Убедитесь, что сервер поддерживает HTTP/2.
HTTP 103 Early Hints позволяет серверу отправить подсказки о preload до основного ответа:
HTTP/1.1 103 Early Hints
Link: </critical.css>; rel=preload; as=style
Link: </hero.avif>; rel=preload; as=image
CSS, необходимый для отрисовки above-the-fold контента, должен быть встроен в HTML или загружен с высоким приоритетом:
<head>
<style>
/* Критический CSS для hero-блока */
.hero { min-height: 100vh; }
.hero img { width: 100%; height: auto; }
</style>
<link rel="stylesheet" href="main.css" media="print" onload="this.media='all'">
</head>
<script src="analytics.js" defer></script>
<script src="app.js" type="module"></script>
Модули (type="module") по умолчанию откладываются. Обычные скрипты — с defer.
Третьесторонние виджеты (чаты, аналитика) часто блокируют рендеринг. Загружайте их после LCP:
window.addEventListener('load', () => {
const script = document.createElement('script');
script.src = 'https://widget.example.com/chat.js';
document.body.appendChild(script);
});
Если LCP-элемент — текст, шрифты критичны.
@font-face {
font-family: 'CustomFont';
src: url('/fonts/custom.woff2') format('woff2');
font-display: swap;
}
font-display: swap показывает текст системным шрифтом сразу, затем подменяет кастомным. Избегайте font-display: block — он блокирует отрисовку до 3 секунд.
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>
Если используете только кириллицу и латиницу, генерируйте подмножество шрифта — файл станет в 2–3 раза меньше.
| Действие | Приоритет | Сложность |
|---|---|---|
| Оптимизировать LCP-изображение (формат, размер) | Высокий | Низкая |
| Добавить fetchpriority="high" для LCP-элемента | Высокий | Низкая |
| Указать width/height для изображений | Высокий | Низкая |
| Настроить preload для критических ресурсов | Высокий | Средняя |
| Включить CDN и кэширование | Высокий | Средняя |
| Инлайнить критический CSS | Средний | Средняя |
| Отложить нефоновый JavaScript | Средний | Средняя |
| Оптимизировать шрифты (swap, preload) | Средний | Низкая |
| Сократить TTFB (сервер, БД) | Высокий | Высокая |
После внедрения изменений проверьте результат:
Полевые данные (CrUX) обновляются с задержкой 28 дней. Лабораторные тесты показывают эффект сразу, но могут отличаться от реальных условий пользователей.
LCP-элемент — обычно изображение товара. Оптимизация: preload первого изображения, fetchpriority="high", современные форматы. Избегайте lazy loading для главного изображения.
LCP — hero-изображение или крупный заголовок. Для hero — те же приёмы, что для изображений. Для заголовков — критический CSS для шрифтов, preload шрифтов, минимизация блокирующего CSS.
Часто один экран, один крупный элемент. LCP критичен. Максимальная оптимизация: инлайновый критический CSS, preload всех критических ресурсов, минимум JS.
Performance → запись загрузки → метка LCP. Показывает элемент и время. Network позволяет проверить приоритет загрузки ресурсов.
Лабораторные и полевые данные. Полевые (CrUX) — реальные пользователи. Лабораторные — симулированная среда. Оба важны.
Расширение для Chrome от Google показывает LCP, INP, CLS в реальном времени при просмотре страниц.
Инструмент Web Vitals на reChecker — проверка без установки инструментов. Введите URL и получите отчёт по метрикам.
Добавление тяжёлых скриптов, новых изображений, блокирующего CSS. Проверьте Network waterfall — какой ресурс задерживает отрисовку.
Да. Разные устройства, скорость сети, размеры экрана. Оптимизируйте оба, но мобильный приоритетнее (mobile-first indexing).
Приоритет — страницы с трафиком и конверсиями. Главная, ключевые товары, популярные статьи. Остальные — по мере возможности.
Подробнее о всех метриках Core Web Vitals и их взаимосвязи читайте в полном руководстве по Core Web Vitals 2026. Для комплексной проверки производительности используйте инструмент Web Vitals и проверку изображений на reChecker.