LCP на SEO-лендинге Next.js 15: next/image, preload и AVIF

Пользователь открывает лендинг из поиска. До появления заголовка и hero-картинки проходит 4 секунды на 4G — он уходит, не дочитав оффер. Google фиксирует Largest Contentful Paint (LCP) выше 2,5 секунд и помечает URL в Search Console как «Needs improvement». Позиции не падают мгновенно, но Page Experience и конверсия страдают: по данным Google, каждые 100 мс задержки LCP снижают вероятность конверсии на л landing page на 1–2%.

На коммерческих лендингах LCP-элементом в 70–80% случаев становится hero-image или крупный заголовок с web-шрифтом. Остальное — вторично. Partial Prerendering, JSON-LD и Open Graph не спасут, если главная картинка грузится через <img src="hero.jpg"> без width/height, а шрифт Inter блокирует отрисовку текста.

В этой статье — production-подход для Next.js 15 App Router: next/image с priority, корректный атрибут sizes, AVIF через Vercel Image Optimization, preload критических ресурсов и проверка в Search Console. Цель — LCP ≤ 2,5 с на мобильных в полевых данных CrUX.

Почему LCP — главная метрика первого экрана

LCP измеряет момент, когда самый крупный видимый элемент viewport полностью отрисован. Для SEO-лендинга это не абстрактный «Performance score», а прямой сигнал качества страницы в рамках Core Web Vitals.

Типичные LCP-элементы на лендинге услуг:

1. <img> hero — фото команды, mockup продукта, фоновая иллюстрация.
2. <h1> с custom font — если картинки нет или она мала относительно текста.
3. <video poster> — реже, но poster считается LCP-элементом.

Google использует 75-й перцентиль полевых данных (CrUX) по URL или группе URL. Lab-замеры Lighthouse полезны для отладки, но релиз оценивают по Search Console → Core Web Vitals → LCP.

Связь с SEO: LCP входит в Page Experience. Страница с «Good» по всем трём CWV (LCP, INP, CLS) стабильнее удерживает позиции на конкурентных запросах. Плюс быстрый LCP снижает bounce rate — косвенный поведенческий сигнал.

Hero-image: next/image с priority и sizes

Главная ошибка — обычный <img> или CSS background-image для hero above-the-fold. Браузер не знает приоритет, не резервирует место, не получает responsive srcset.

Базовый паттерн для Next.js 15

// app/components/hero-image.tsx — Server Component
import Image from 'next/image';

export function HeroImage() {
  return (
    <div className="relative aspect-[16/9] w-full max-h-[480px] overflow-hidden">
      <Image
        src="/hero-developer.webp"
        alt="Разработка SEO-лендингов на Next.js 15"
        fill
        priority
        sizes="(max-width: 768px) 100vw, (max-width: 1200px) 80vw, 960px"
        className="object-cover object-center"
        placeholder="blur"
        blurDataURL="data:image/jpeg;base64,/9j/4AAQSkZJRg..."
      />
    </div>
  );
}

Ключевые параметры:

• priority — отключает lazy loading и добавляет <link rel="preload"> для LCP-изображения. Используйте только для одного элемента above-the-fold; иначе preload-конкуренция ухудшит LCP.
• fill + aspect-ratio на контейнере — резервирует место до загрузки, CLS остаётся в зелёной зоне.
• sizes — говорит браузеру, какой ширины будет картинка на каждом breakpoint. Без sizes Next.js отдаст слишком большой файл на мобильных.

Выбор формата: AVIF → WebP → fallback

На Vercel next/image автоматически конвертирует в AVIF/WebP через Image Optimization API. Для hero загружайте исходник в WebP или PNG с разрешением не выше 2× от max display width. Исходник 4000×3000 px на контейнер 960 px — лишние байты и CPU на edge.

Рекомендуемые размеры для лендинга 1440 px контейнер:

fetchPriority и decoding

Next.js 15 пробрасывает fetchPriority="high" при priority. Для декоративных картинок ниже fold — без priority, с lazy loading по умолчанию.

// ❌ Несколько priority на странице
<Image src="/hero.webp" priority ... />
<Image src="/logo.svg" priority ... />  // SVG не нужен в priority
<Image src="/badge.webp" priority ... />

// ✅ Один priority — hero; logo через обычный import или inline SVG

Если hero — CSS background (градиент + паттерн), LCP смещается на <h1>. Тогда оптимизируйте шрифт, а не картинку.

Если нужна подобная разработка — напишите в Telegram.

Шрифты и текст: когда LCP — это h1, а не картинка

На минималистичных лендингах с shadcn/ui hero часто текстовый: крупный <h1>, подзаголовок, CTA. LCP-элемент — первая строка заголовка, и его блокирует загрузка web-шрифта.

next/font без layout shift

// app/layout.tsx
import { Inter } from 'next/font/google';

const inter = Inter({
  subsets: ['latin', 'cyrillic'],
  display: 'swap',
  variable: '--font-inter',
  preload: true,
  adjustFontFallback: true,
});

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="ru" className={inter.variable}>
      <body className="font-sans antialiased">{children}</body>
    </html>
  );
}

• display: 'swap' — текст виден сразу системным шрифтом, затем подменяется Inter. LCP фиксируется раньше, чем при block.
• adjustFontFallback — подгоняет метрики fallback, снижает CLS при подмене.
• Не подключайте шрифты через @import в CSS — они блокируют рендер и не попадают в preload pipeline Next.js.

Preload только критического начертания

Для hero достаточно Inter 700 (bold h1). Подключение всех 9 начертаний через один @font-face bundle раздувает LCP. В next/font указывайте weight: ['400', '700'], не 'variable' без необходимости.

Inline critical CSS

Блокирующий CSS в <head> задерживает LCP. Tailwind v4 с @tailwindcss/postcss генерирует один bundle — убедитесь, что hero-стили не тянут @layer components для всей UI-библиотеки на главной. Для лендинга допустим route-specific CSS или @source ограничение в Tailwind v4.

Vercel Edge, кэш и Image Optimization

Деплой на Vercel даёт три преимущества для LCP:

1. Edge Network — HTML статической оболочки (SSG/PPR) отдаётся из ближайшего PoP. TTFB < 200 ms снижает LCP даже при тяжёлом hero.
2. Image Optimization CDN — /_next/image?url=...&w=960&q=75 кешируется на edge после первого запроса. AVIF на 30–50% меньше WebP при том же качестве.
3. Immutable static assets — /_next/static/ с hash кешируется на год.

next.config.ts для production

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [390, 640, 768, 960, 1200],
    imageSizes: [16, 32, 48, 64, 96, 128, 256],
    minimumCacheTTL: 31536000,
  },
  experimental: {
    optimizePackageImports: ['lucide-react'],
  },
};

export default nextConfig;

deviceSizes подгоните под реальные breakpoints лендинга — лишние размеры создают варианты кеша без пользы.

Remote images из headless CMS

Sanity, Contentful, Strapi — hero часто с CDN URL. Добавьте домен в images.remotePatterns:

images: {
  remotePatterns: [
    {
      protocol: 'https',
      hostname: 'cdn.sanity.io',
      pathname: '/images/**',
    },
  ],
},

Без этого next/image не оптимизирует CMS-картинку, и LCP бьёт по full-resolution original.

Partial Prerendering и LCP

PPR (Next.js 15) отдаёт статический shell мгновенно — LCP-элемент в HTML виден роботу с первого байта. Динамические блоки (персонализация, A/B) стримятся позже, но не должны быть LCP-элементом. Hero и h1 держите в static shell.

Замеры: Lighthouse, CrUX и типичные регрессии

Без полевых данных оптимизация LCP — guesswork.

Search Console

Отчёт Core Web Vitals → фильтр по LCP → группы URL. Смотрите mobile отдельно: desktop LCP часто «Good», mobile — «Poor» при том же коде.

Lighthouse и WebPageTest

1. Lighthouse mobile, throttling Slow 4G — LCP в Insights ≤ 2,5 с.
2. WebPageTest → filmstrip: когда hero становится видимым относительно Start Render.
3. Chrome DevTools → Performance → маркер LCP на timeline; клик покажет элемент (img или text).

Чеклист перед релизом

• Один priority Image above-the-fold.
• sizes соответствует реальной ширине контейнера.
• Hero исходник ≤ 200 KB (WebP) до оптимизации.
• Шрифт h1 через next/font, не @import.
• Нет render-blocking third-party (Chat widget, analytics) в <head> до LCP.
• @vercel/speed-insights подключён для post-deploy мониторинга.

Типичные регрессии после «улучшений»

Нужна помощь? Telegram → или vic.kell@ya.ru

FAQ

Можно ли использовать CSS background-image для hero?

Можно для декора, но background не участвует в LCP так предсказуемо, как <img>. Браузер не preload background. Для SEO-лендинга hero above-the-fold — всегда next/image или <img width height fetchpriority="high">.

Сколько priority-изображений допустимо на странице?

Один, максимум два (hero + OG не считается — он не на странице). Каждый priority конкурирует за bandwidth на мобильном соединении.

AVIF безопасен для всех браузеров?

Next.js отдаёт AVIF с fallback на WebP/JPEG через Accept negotiation. Safari поддерживает AVIF с iOS 16+. Старые клиенты получат WebP автоматически.

LCP влияет на ранжирование сильнее INP?

Обе метрики входят в Core Web Vitals. LCP критичнее для первого впечатления и bounce; INP — для конверсии после загрузки. На лендинге оптимизируйте обе: LCP через hero/fonts, INP через минимальный client JS.

Нужен ли blur placeholder для LCP?

Blur placeholder улучшает воспринимаемую скорость, но не всегда улучшает метрику LCP (она ждёт полной отрисовки). Для UX — да; для зелёного CrUX — важнее priority и правильный sizes.

Как headless CMS влияет на LCP?

CMS добавляет latency только если hero рендерится динамически без кеша. Свяжите Sanity/Contentful с ISR или on-demand revalidation: HTML с оптимизированным next/image src кешируется на edge, LCP стабилен между обновлениями контента.

Заключение

LCP на SEO-лендинге — это не «подкрутить Lighthouse один раз», а дисциплина around the largest above-the-fold element. В большинстве проектов на Next.js 15 это hero-image: next/image с priority, точный sizes, AVIF через Vercel и один preload шрифта для h1.

Деплой на edge, PPR для static shell и мониторинг в Search Console превращают оптимизацию из разового спринта в устойчивый процесс. LCP ≤ 2,5 с на mobile CrUX — реалистичная цель для лендинга услуг в 2026 году, если hero не отдаётся «как есть» из Figma экспортом на 3 мегабайта.