LCP on Next.js 15 Landing Pages: Hero Image Done Right

A visitor lands from Google. Four seconds pass on 4G before the headline and hero image appear — they leave. Google records Largest Contentful Paint (LCP) above 2.5 seconds and flags the URL in Search Console. Rankings don’t collapse overnight, but Page Experience and conversion take a hit: roughly every 100 ms of LCP delay costs 1–2% conversion on typical landing pages.

On commercial landings, the LCP element is the hero image or a large H1 set in a web font about 70–80% of the time. Partial Prerendering, JSON-LD, and Open Graph won’t help if the hero loads via a plain <img> without dimensions, or if Inter blocks text paint.

This guide covers a production workflow for Next.js 15 App Router: next/image with priority, correct sizes, AVIF through Vercel Image Optimization, critical resource preload, and validation in Search Console. Target: LCP ≤ 2.5 s on mobile field data.

Why LCP Defines First Impressions

LCP marks when the largest visible element in the viewport is fully rendered. For SEO landings it’s not an abstract Lighthouse score — it’s a Core Web Vital that Google aggregates at the 75th percentile from CrUX.

Common LCP candidates:

1. Hero <img> — team photo, product mockup, illustration.
2. <h1> with a custom font — when no large image dominates.
3. <video poster> — poster counts as the LCP element.

Lab scores from Lighthouse help debug; releases are judged on Search Console → Core Web Vitals → LCP, especially mobile.

Hero Image: next/image with priority and sizes

The most expensive mistake: a raw <img> or CSS background-image for an above-the-fold hero. The browser can’t prioritize the request, reserve space, or pick an appropriate srcset width.

Baseline pattern

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 landing development with 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>
  );
}

What matters:

• priority — disables lazy loading and injects <link rel="preload">. Use for one above-the-fold image only.
• fill + aspect ratio on the wrapper — prevents CLS while the image loads.
• sizes — tells the browser the rendered width at each breakpoint. Without it, mobile users download desktop-sized files.

On Vercel, next/image serves AVIF/WebP automatically. Upload sources at 2× max display width, not 4000 px wide for a 960 px container.

If you need help building this — message on Telegram.

When LCP Is the H1, Not the Image

Minimal landings built with shadcn/ui often have a text hero: big headline, subcopy, CTA. The LCP element becomes the first line of the H1, blocked by font loading.

Use next/font with display: 'swap' and adjustFontFallback: true. Avoid @import in CSS — it blocks render and skips Next’s preload pipeline. Load only weights you need (e.g. 400 and 700), not the entire variable axis.

Keep hero styles lean: don’t pull the full component library CSS into the critical path on /.

Vercel Edge and Image Optimization

Edge delivery cuts TTFB for static shells (SSG/PPR). Image Optimization caches transformed URLs (/_next/image?url=...&w=960&q=75) at the PoP — AVIF is often 30–50% smaller than WebP at similar quality.

Configure images.formats, deviceSizes matched to your breakpoints, and remotePatterns for headless CMS URLs (Sanity, Contentful). Without remote patterns, CMS heroes ship at full resolution and LCP suffers.

With Partial Prerendering, keep hero and H1 in the static shell. Dynamic personalization must not become the LCP element.

Measurement and Regressions

Monitor Search Console (mobile LCP groups) and @vercel/speed-insights after deploy. Lab checklist:

• One priority image above the fold.
• sizes matches real container widths.
• Hero source ≤ ~200 KB WebP before optimization.
• H1 font via next/font.
• No synchronous third-party scripts in <head> before LCP.

Watch for regressions: lazy-loading the hero, framer-motion fades on the LCP element, or autoplay video replacing a static image often increases LCP by seconds.

Need help? Telegram → or vic.kell@ya.ru

FAQ

Should I use CSS background-image for the hero?

Fine for decoration, but backgrounds aren’t preloaded predictably. For SEO landings above the fold, prefer next/image.

How many priority images per page?

One — two at most. Each competes for bandwidth on mobile.

Is AVIF safe?

Next.js negotiates via Accept headers. Older browsers fall back to WebP/JPEG automatically.

LCP vs INP — which matters more?

Both are Core Web Vitals. LCP drives first impression and bounce; INP drives post-load conversion. Optimize both on landings.

Does blur placeholder improve LCP?

It helps perceived speed, not always the metric (LCP waits for full paint). priority and correct sizes matter more for CrUX.

Conclusion

LCP optimization is discipline around the largest above-the-fold element — usually the hero. On Next.js 15: next/image with priority, accurate sizes, AVIF on Vercel, one font preload for the headline, and edge-cached static shells.

LCP ≤ 2.5 s on mobile CrUX is achievable for service landings in 2026 — as long as the hero isn’t a 3 MB Figma export served unchanged.