Improving Next.js Lighthouse Without Killing the Design

Key takeaways

• Attack above-the-fold work and LCP before you polish far below the scroll.
• Defer or idle-load decoration so the first paint still feels expensive.
• Treat `sizes`, `priority`, and third parties like a budget, not a free buffet.

What should I fix first when Lighthouse hurts but I still want a designed hero?

Start with whatever actually paints above the fold (your real LCP element), then cut main-thread JavaScript before you strip visual personality.

The score is a mirror. The user is the customer. I open DevTools like a grumpy editor and ask what a stranger sees before they scroll, before they click, before they care about my footer.

Source

On marketing sites that usually means the hero image or headline block, plus whatever script thinks it is the main character. Lighthouse will happily let you micro-optimize a chart that nobody sees while the hero still loads like molasses.

So I map LCP, first paint, and long tasks in that order. If you only do one thing, make the first screen honest. Everything else can wait.

Can I keep gradients and motion without failing Web Vitals?

Yes, if the heavy work runs after first paint, on idle, or when the user scrolls, not in the initial bundle for the hero.

• Paint the core layout and hero copy without waiting on optional JS.
• Hydrate interactive extras after `requestIdleCallback`, a short timeout, or a scroll threshold.
• Keep typography and spacing premium so the page still feels finished before extras arrive.

What does my personal Lighthouse checklist look like?

Hero first, then real images (`sizes` + `priority`), then third parties, then fonts, then CLS risks. Repeat on every deploy.

import Image from 'next/image';

const HERO_IMAGE = {
  src: '/images/placeholder-hero.jpg',
  alt: 'Placeholder hero image',
};

export function HeroImage() {
  return (
    <Image
      src={HERO_IMAGE.src}
      alt={HERO_IMAGE.alt}
      width={640}
      height={360}
      priority
      sizes="(max-width: 768px) 100vw, 640px"
      quality={75}
      className="w-full max-w-[640px] rounded-2xl object-cover"
    />
  );
}

• Hero: keep first-paint JS boring; CSS carries most of the drama.
• Images: one `priority` candidate, honest `sizes`, compression you can explain.
• Third parties: load on interaction or idle, never as an uncapped parallel grab.
• Fonts: fewer families and weights beat a trophy case of faces.
• Layouts: reserve space for media and widgets so CLS stays boring.

When do analytics and chat widgets earn a slot on my page?

Only when I can name the decision they inform, and I load them after the first meaningful paint or on a deliberate user action.

What happened when a pretty hero blew my LCP?

A full-width animated WebP hero kept LCP above 3.5s until I prioritized decode for that node and deferred motion there; after that, LCP sat near 1.1s with the same pixels on screen.

Where do people waste next/image and the priority flag?

They omit `sizes`, mark half the page as `priority`, or hydrate decorative motion before the LCP node finishes.

• Spraying `priority` so nothing is actually prioritized.
• Skipping `sizes` so mobile pulls a desktop-sized asset.
• Hydrating heavy motion for content that could stay CSS-only.
• Letting Tag Manager or chat load before the first contentful paint.