Next.js Core Web Vitals Optimization: Complete Guide to LCP/FCP/CLS

Last month, I took on a performance optimization project for an e-commerce site with a Lighthouse score stuck around 65. The biggest headache was the LCP (Largest Contentful Paint) hovering around 3.5 seconds. The boss was complaining about high bounce rates and poor conversion rates. Honestly, I was under a lot of pressure.

After two weeks of systematic Core Web Vitals optimization, I managed to boost the Lighthouse score to 95 and reduce LCP to 1.2 seconds. More importantly, the conversion rate jumped by 28%. This experience made me realize that performance optimization isn’t just about technical metrics—it’s about real business value.

According to 2025 data, only 47% of websites meet Google’s Core Web Vitals standards. Poor performance can lead to an 8-35% loss in revenue, rankings, and conversion rates. This isn’t fear-mongering—it’s the real cost of poor performance.

Vultr - High-performance NVMe VPS with 32 global locations, one-click Docker deploy

View Pricing →Ad

In this article, I’ll share the practical experience I’ve gained optimizing Next.js performance. You’ll learn:

• Specific optimization methods for 3 core metrics (LCP, INP, CLS)
• 10+ ready-to-use code examples
• 5 most common performance pitfalls

Core Web Vitals 2025 Updates

Before we start optimizing, we need to understand the current rules. Many articles still talk about FID (First Input Delay), but that metric was actually deprecated in March 2024.

The Three Current Core Metrics

Google now focuses on these three metrics:

1. LCP (Largest Contentful Paint)

   • Target: ≤ 2.5 seconds
   • Measures loading performance
   • Accounts for 25% of Lighthouse score

2. INP (Interaction to Next Paint)

   • Target: ≤ 200ms
   • Measures interaction responsiveness
   • Replaced FID in March 2024

3. CLS (Cumulative Layout Shift)

   • Target: < 0.1
   • Measures visual stability

FCP (First Contentful Paint) is no longer a core metric, but it’s still important as it affects users’ first impression.

Why Care About These Metrics?

Have you ever experienced this: you open a website, about to click a button, suddenly the page jumps, and you click the wrong thing? That’s poor CLS in action.

Or you visit a website, stare at a white screen for several seconds, thinking “did my internet die?” That’s slow LCP.

According to Chrome team data, top-performing sites average around 1,220ms for LCP. If your site’s LCP exceeds 2.5 seconds, you’re lagging behind most competitors.

LCP Optimization - Fast-Loading Main Content

LCP was the metric I spent the most time on, and it showed the most dramatic improvements. Let me walk you through the optimization process step by step.

Step 1: Identify Your LCP Element

Before optimizing, you need to know which element is your LCP. Typically, LCP elements are:

• Hero images above the fold
• Video poster images
• Large blocks of title text

Quick identification method:

1. Open Chrome DevTools (F12)
2. Press Ctrl+Shift+P (Mac: Cmd+Shift+P)
3. Type “Show Rendering”
4. Check “Core Web Vitals”
5. Refresh the page, the LCP element will be highlighted in the top-right corner

I discovered that the e-commerce project’s LCP element was the homepage hero image—a 2MB JPG. That was the problem.

Image Optimization: Using next/image Correctly

Many people think using Next.js’s Image component is enough, but it’s not. I thought the same initially, and LCP was still slow.

Priority Setting is Key

For LCP images, you must explicitly tell the browser “this image is important, load it first!” Next.js provides two approaches:

Next.js 13-15 (mainstream versions):

import Image from 'next/image';

export default function Hero() {
  return (
    <Image
      src="/hero-image.jpg"
      width={1200}
      height={630}
      priority  // Critical! Tells browser to prioritize loading
      fetchPriority="high"  // Double insurance
      alt="Product hero visual"
    />
  );
}

Next.js 16+ (latest version):

Next.js 16 deprecated the priority attribute, use this instead:

<Image
  src="/hero-image.jpg"
  width={1200}
  height={630}
  loading="eager"  // Load immediately, no lazy loading
  fetchPriority="high"  // High priority
  alt="Product hero visual"
/>

You might wonder why set two attributes? Because priority automatically adds preload tags, while fetchPriority tells the browser the resource importance. Using both works best.

Compare with incorrect approaches:

// ❌ Wrong: Will be lazy loaded, slow LCP
<Image
  src="/hero-image.jpg"
  width={1200}
  height={630}
  alt="Product hero visual"
/>

// ❌ Wrong: Missing dimensions
<Image
  src="/hero-image.jpg"
  priority
  alt="Product hero visual"
/>

The Importance of Dimension Declaration

Next.js’s Image component requires you to specify width and height. This isn’t to make your life difficult—it’s to prevent CLS (Cumulative Layout Shift).

For responsive layouts, write it like this:

// Use fill property for responsive behavior
<div style={{ position: 'relative', width: '100%', aspectRatio: '16/9' }}>
  <Image
    src="/hero-image.jpg"
    fill
    priority
    style={{ objectFit: 'cover' }}
    alt="Product hero visual"
  />
</div>

Note that the parent container must have explicit dimensions or aspect-ratio, otherwise the image won’t know what size to render.

Font Optimization: next/font Auto-Inlining

Slow font loading also drags down LCP, especially Chinese fonts which can be several MB. Next.js 13 introduced next/font to automatically optimize font loading.

Using Google Fonts:

// app/layout.jsx
import { Inter, Noto_Sans_SC } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',  // Avoid font flash
});

const notoSansSC = Noto_Sans_SC({
  subsets: ['chinese-simplified'],
  weight: ['400', '700'],
  display: 'swap',
});

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={`${inter.className} ${notoSansSC.className}`}>
      <body>{children}</body>
    </html>
  );
}

Using custom fonts:

import localFont from 'next/font/local';

const myFont = localFont({
  src: './my-font.woff2',
  display: 'swap',
});

export default function Layout({ children }) {
  return <div className={myFont.className}>{children}</div>;
}

next/font automatically provides these optimizations:

• Auto-inlines font CSS, reducing network requests
• Auto-subsets, loading only needed characters
• Auto-preloads font files
• Eliminates layout shift

After switching the project to next/font, LCP dropped another 0.3 seconds.

Reducing Server Response Time

Images optimized, fonts optimized, but LCP still slow? Might be server response time (TTFB) issues.

Static Generation First

Next.js offers multiple rendering methods, ranked by performance from best to worst:

1. SSG (Static Site Generation) - Generate HTML at build time, fastest
2. ISR (Incremental Static Regeneration) - Regenerate static pages on demand
3. SSR (Server-Side Rendering) - Generate HTML per request, slower
4. CSR (Client-Side Rendering) - Client rendering, slowest LCP

Use SSG when possible:

// app/blog/[slug]/page.jsx
export async function generateStaticParams() {
  const posts = await getPosts();
  return posts.map((post) => ({
    slug: post.slug,
  }));
}

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);
  return <article>{/* ... */}</article>;
}

If data needs real-time updates, use ISR:

// app/products/[id]/page.jsx
export const revalidate = 3600; // Regenerate every hour

export default async function ProductPage({ params }) {
  const product = await getProduct(params.id);
  return <div>{/* ... */}</div>;
}

Using CDN and Edge Network

If deployed on Vercel, it automatically distributes static assets to the global Edge Network, significantly reducing TTFB.

For other platforms, use CDNs like Cloudflare or AWS CloudFront.

Avoid Heavy Server-Side Computation

I’ve made this mistake too. Once I did complex data processing server-side that took 500ms per render, directly dragging down LCP.

Bad example:

// ❌ Wrong: Computes on every request
export default async function Page() {
  const data = await fetchData();
  const processed = heavyProcessing(data); // Takes 500ms
  return <div>{processed}</div>;
}

Correct approach:

Cache computation results or compute at build time:

// ✅ Correct: Compute at build time
export async function generateStaticParams() {
  const data = await fetchData();
  const processed = heavyProcessing(data);
  // Save results to database or file
  await saveProcessedData(processed);
}

export default async function Page() {
  const processed = await getProcessedData(); // Direct read
  return <div>{processed}</div>;
}

CLS Optimization - Eliminating Layout Shift

CLS (Cumulative Layout Shift) is the most frustrating metric. Sudden page jumps create a terrible user experience. Honestly, this issue troubled me for quite a while.

Reserving Space for Images and Media

The most common cause of CLS is images changing layout after loading. The solution is simple: tell the browser image dimensions upfront.

Next.js Image component handles this automatically:

// ✅ Correct: Specify dimensions, no CLS
<Image
  src="/product.jpg"
  width={400}
  height={300}
  alt="Product image"
/>

What about dynamically loaded images?

Alibaba Cloud - Top choice for developers, exclusive 15% off for Lighthouse servers

Get 15% Discount →Ad

Say you’re getting images from a CMS without knowing dimensions:

// ✅ Correct: Use aspect-ratio to reserve space
<div style={{ position: 'relative', width: '100%', aspectRatio: '4/3' }}>
  <Image
    src={dynamicImageUrl}
    fill
    style={{ objectFit: 'cover' }}
    alt="Dynamic image"
  />
</div>

Same for videos:

<video
  width="1280"
  height="720"
  poster="/video-poster.jpg"
  controls
>
  <source src="/video.mp4" type="video/mp4" />
</video>

Reserving Space for Dynamic Content

Ads, notification bars, embedded content (like Twitter cards) all cause CLS. You need to reserve space for them in advance.

Ad containers:

// ✅ Correct: Reserve ad height
<div
  style={{
    minHeight: '250px',  // Standard Google AdSense height
    backgroundColor: '#f0f0f0'  // Placeholder background
  }}
>
  {/* Ad script */}
  <ins className="adsbygoogle" />
</div>

Notification bars:

If your site has a top notification bar, don’t let it appear suddenly:

// ❌ Wrong: Appears suddenly, pushes page down
{showBanner && <NotificationBanner />}

// ✅ Correct: Reserve space upfront
<div style={{ minHeight: '60px' }}>
  {showBanner ? <NotificationBanner /> : <div style={{ height: '60px' }} />}
</div>

Skeleton screens:

For dynamically loaded content, use skeleton placeholders:

function ProductList() {
  const { data, isLoading } = useQuery('products', fetchProducts);

  if (isLoading) {
    return (
      <div className="grid grid-cols-3 gap-4">
        {Array.from({ length: 6 }).map((_, i) => (
          <div key={i} className="skeleton" style={{ height: '300px' }} />
        ))}
      </div>
    );
  }

  return (
    <div className="grid grid-cols-3 gap-4">
      {data.map(product => <ProductCard key={product.id} {...product} />)}
    </div>
  );
}

Font Loading Optimization

Font loading also causes CLS, manifesting as “text flash” or “font jump”.

next/font handles this automatically, but you can also optimize manually:

const inter = Inter({
  subsets: ['latin'],
  display: 'optional',  // If font doesn't load in time, use system font, don't wait
  adjustFontFallback: true,  // Auto-adjust fallback font size to reduce jump
});

display property options:

• swap: Show fallback first, switch when loaded (may cause CLS)
• optional: If font doesn’t load in time, use fallback (recommended)
• block: Briefly hide text, wait for font (not recommended)
• fallback: Between swap and optional

I recommend optional. Although you might not see custom fonts, user experience is better.

Avoiding JavaScript-Driven Responsive Layouts

This is the most common CLS trap in 2025! I’ve seen many Next.js projects making this mistake.

Typical wrong code:

// ❌ Wrong: Causes severe CLS
import { useMediaQuery } from '@/hooks/useMediaQuery';

export default function ResponsiveLayout() {
  const isMobile = useMediaQuery('(max-width: 768px)');

  return (
    <div>
      {isMobile ? (
        <MobileNav />
      ) : (
        <DesktopNav />
      )}
    </div>
  );
}

Why does this cause CLS? Because:

1. On first render, JavaScript hasn’t executed, isMobile is undefined or a default value
2. After JavaScript executes, useMediaQuery returns the real value
3. Component re-renders, layout suddenly changes

This problem is worse with server-side rendering (SSR) because the server doesn’t know the client’s screen width.

Correct approach: Use CSS media queries

// ✅ Correct: Use CSS to control show/hide, no CLS
export default function ResponsiveLayout() {
  return (
    <>
      <nav className="mobile-nav md:hidden">
        <MobileNav />
      </nav>
      <nav className="desktop-nav hidden md:block">
        <DesktopNav />
      </nav>
    </>
  );
}

Or use CSS-in-JS:

export default function ResponsiveLayout() {
  return (
    <div className="responsive-container">
      <MobileNav />
      <DesktopNav />
      <style jsx>{`
        .responsive-container > :global(.mobile-nav) {
          display: block;
        }
        .responsive-container > :global(.desktop-nav) {
          display: none;
        }
        @media (min-width: 768px) {
          .responsive-container > :global(.mobile-nav) {
            display: none;
          }
          .responsive-container > :global(.desktop-nav) {
            display: block;
          }
        }
      `}</style>
    </div>
  );
}

If you really need JavaScript detection (e.g., different data requests based on device), get User-Agent server-side:

// app/page.jsx
import { headers } from 'next/headers';

export default async function Page() {
  const headersList = headers();
  const userAgent = headersList.get('user-agent') || '';
  const isMobile = /mobile/i.test(userAgent);

  return (
    <div>
      {isMobile ? <MobileView /> : <DesktopView />}
    </div>
  );
}

This way server and client render consistently, no CLS.

FCP Optimization - Accelerating First Contentful Paint

FCP (First Contentful Paint) isn’t a core metric, but it affects users’ first impression. If users see a white screen too long, they might just close the page.

Critical Resource Optimization

Slow FCP is usually due to render-blocking resources. Open Chrome DevTools Coverage panel to see which CSS and JavaScript isn’t being used.

Inline critical CSS:

Next.js automatically handles CSS optimization, but you can also manually inline critical styles:

// app/layout.jsx
export default function RootLayout({ children }) {
  return (
    <html>
      <head>
        <style
          dangerouslySetInnerHTML={{
            __html: `
              /* Critical CSS: Styles needed for above-the-fold */
              body { margin: 0; font-family: system-ui; }
              .hero { height: 100vh; }
            `,
          }}
        />
      </head>
      <body>{children}</body>
    </html>
  );
}

Defer non-critical CSS:

For styles not needed above-the-fold (like modals, collapsible sections), defer loading:

// Dynamically import CSS in component
import dynamic from 'next/dynamic';

const Modal = dynamic(() => import('./Modal'), {
  loading: () => <p>Loading...</p>,
});

Third-Party Script Management

Third-party scripts (like Google Analytics, ads, social media widgets) are performance killers. Many sites have slow FCP because of this.

Using next/script:

Next.js provides a Script component to control script loading timing:

import Script from 'next/script';

export default function Layout({ children }) {
  return (
    <>
      {children}

      {/* Google Analytics: Load after page is interactive */}
      <Script
        src="https://www.googletagmanager.com/gtag/js?id=GA_MEASUREMENT_ID"
        strategy="lazyOnload"
      />
      <Script id="ga-init" strategy="lazyOnload">
        {`
          window.dataLayer = window.dataLayer || [];
          function gtag(){dataLayer.push(arguments);}
          gtag('js', new Date());
          gtag('config', 'GA_MEASUREMENT_ID');
        `}
      </Script>

      {/* Facebook Pixel: Lazy load */}
      <Script
        src="https://connect.facebook.net/en_US/fbevents.js"
        strategy="lazyOnload"
      />
    </>
  );
}

strategy attribute options:

Railway - Modern deployment platform, zero-config, go live in minutes

Start Now →Ad

• beforeInteractive: Load before page is interactive (for critical scripts)
• afterInteractive: Load after page is interactive (default)
• lazyOnload: Load during idle time (recommended for analytics and ads)
• worker: Run in Web Worker (experimental)

After changing all non-essential third-party scripts to lazyOnload, my FCP improved by 0.8 seconds.

Code Splitting and Lazy Loading

Next.js automatically does code splitting, but sometimes you need manual optimization.

Lazy load components:

For components not needed above-the-fold, use dynamic imports:

import dynamic from 'next/dynamic';

// Lazy load comments component
const Comments = dynamic(() => import('./Comments'), {
  loading: () => <div>Loading comments...</div>,
  ssr: false,  // No server-side rendering
});

export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
      {/* Load comments when scrolled here */}
      <Comments postId={post.id} />
    </article>
  );
}

Lazy load third-party libraries:

Some libraries are huge (like charting libraries, rich text editors) and should be loaded on demand.

Case: Lazy loading chart library saved 800KB

I once encountered a project importing Chart.js on every page, but only the dashboard used it. Every page was loading 800KB of code.

Before optimization:

// ❌ Wrong: Global import, loaded on all pages
import { Chart } from 'chart.js';

export default function Dashboard() {
  return <canvas ref={chartRef} />;
}

After optimization:

// ✅ Correct: Load only when needed
import dynamic from 'next/dynamic';

const ChartComponent = dynamic(() => import('./ChartComponent'), {
  loading: () => <div>Loading chart...</div>,
  ssr: false,
});

export default function Dashboard() {
  return <ChartComponent />;
}

// ChartComponent.jsx
import { Chart } from 'chart.js';

export default function ChartComponent() {
  return <canvas ref={chartRef} />;
}

Now only dashboard visitors download Chart.js, other pages aren’t affected.

Lazy load images:

Except for LCP images, other images should be lazy loaded:

<Image
  src="/feature-image.jpg"
  width={600}
  height={400}
  loading="lazy"  // Default value, can be omitted
  alt="Feature description"
/>

Monitoring and Continuous Optimization

Optimization isn’t the end. Performance is a continuous process requiring regular checks and adjustments.

Using Lighthouse CI for Automated Testing

Running Lighthouse manually is time-consuming and easy to forget. Better to integrate it into your CI/CD pipeline.

Install Lighthouse CI:

npm install -D @lhci/cli

Configuration file lighthouserc.js:

module.exports = {
  ci: {
    collect: {
      url: ['http://localhost:3000/', 'http://localhost:3000/products'],
      numberOfRuns: 3,  // Run 3 times, take average
    },
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.9 }],  // Performance ≥ 90
        'first-contentful-paint': ['error', { maxNumericValue: 2000 }],  // FCP ≤ 2s
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],  // LCP ≤ 2.5s
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],  // CLS < 0.1
      },
    },
    upload: {
      target: 'temporary-public-storage',
    },
  },
};

GitHub Actions configuration:

# .github/workflows/lighthouse.yml
name: Lighthouse CI
on: [push]
jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: npm install
      - run: npm run build
      - run: npm run start &
      - run: npx @lhci/cli autorun

Now every code push automatically runs Lighthouse tests. If performance regresses, CI fails and reminds you to fix it.

Real User Monitoring (RUM)

Lighthouse tests lab environment, real user experience might differ. You need to collect real user Core Web Vitals data.

Using Vercel Analytics:

If deployed on Vercel, you can enable Analytics with one click:

// app/layout.jsx
import { Analytics } from '@vercel/analytics/react';

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}
        <Analytics />
      </body>
    </html>
  );
}

Using web-vitals library:

If not using Vercel, use Google’s web-vitals library:

Vultr - High-performance NVMe VPS with 32 global locations, one-click Docker deploy

View Pricing →Ad

npm install web-vitals

// app/layout.jsx
'use client';

import { useEffect } from 'react';
import { onLCP, onFID, onCLS, onINP } from 'web-vitals';

function sendToAnalytics(metric) {
  // Send to your analytics service
  fetch('/api/analytics', {
    method: 'POST',
    body: JSON.stringify(metric),
  });
}

export default function Analytics() {
  useEffect(() => {
    onLCP(sendToAnalytics);
    onINP(sendToAnalytics);
    onCLS(sendToAnalytics);
  }, []);

  return null;
}

Google Search Console:

Google Search Console’s “Core Web Vitals” report shows your site’s performance with real users and highlights pages needing improvement.

Common Pitfalls and Solutions

Finally, I’ve summarized 5 most common pitfalls:

Pitfall 1: Overusing Client-Side JavaScript

Many developers habitually do everything in React, resulting in entire pages depending on JavaScript. If JS fails to load or is too slow, users see a white screen.

Solution:

• Prioritize Server Components (Next.js 13+ default)
• Only use ‘use client’ when necessary
• Use Progressive Enhancement: ensure basic functionality works first, then enhance interactivity

Pitfall 2: Ignoring Mobile Performance

Fast desktop doesn’t mean fast mobile. Mobile devices have weaker CPUs and slower networks, making performance issues more obvious.

Solution:

• Test with Lighthouse’s “Mobile device” mode
• Throttle network speed (Chrome DevTools → Network → Throttling)
• Throttle CPU (Chrome DevTools → Performance → CPU)

Pitfall 3: Unoptimized Third-Party Scripts

Google Analytics, Facebook Pixel, Intercom, Hotjar… each script drags down performance.

Solution:

• Wrap everything with next/script, set strategy="lazyOnload"
• Regularly audit: which scripts are essential? Can we reduce them?
• Consider server-side tracking instead of client-side

Pitfall 4: Wrong Image Format Choices

Still using PNG and JPG? You’re behind. WebP and AVIF can save 30-50% in file size.

Solution:

Next.js Image component automatically converts formats, but ensure your server supports it:

// next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],  // Prioritize modern formats
  },
};

Pitfall 5: Ignoring Server-Side Performance

Frontend optimization doesn’t matter if server response is slow.

Solution:

• Optimize database queries (add indexes, reduce N+1 queries)
• Use caching (Redis, CDN)
• Monitor server performance (APM tools like New Relic, Datadog)

Summary

Let’s recap what we’ve covered:

LCP optimization key points:

• Set priority and fetchPriority="high" for LCP images
• Use next/font to optimize font loading
• Prioritize SSG and ISR, reduce server-side computation
• Use CDN to reduce TTFB

CLS optimization key points:

• All images and media elements must specify dimensions
• Reserve space for dynamic content (ads, notification bars)
• Avoid using JavaScript hooks for responsive layouts
• Use next/font to reduce font jumps

FCP optimization key points:

• Defer loading non-critical resources
• Wrap third-party scripts with next/script, set lazyOnload
• Lazy load large libraries and below-the-fold components

Continuous optimization:

• Use Lighthouse CI for automated testing
• Collect real user data (RUM)
• Regularly audit and clean unnecessary code

Performance optimization is a “measure → optimize → re-measure” cycle. Don’t expect a one-time fix, but continuous attention and improvement.

When I saw the Lighthouse score finally break 90, that sense of achievement was genuinely satisfying. More importantly, the conversion rate increase proved these efforts were worthwhile.

Action Checklist

Now it’s your turn. I suggest starting in this order:

1. Immediate action:

   • Test your Next.js project with Lighthouse
   • Identify LCP element, check if priority is set
   • Check for useMediaQuery or other code causing CLS

2. Complete this week:

   • Optimize LCP images (priority + fetchPriority)
   • Switch fonts to next/font
   • Add placeholders for dynamic content

3. Complete next week:

   • Change third-party scripts to lazyOnload
   • Lazy load large libraries and below-the-fold components
   • Set up Lighthouse CI automated testing

4. Ongoing:

   • Check Lighthouse score monthly
   • Monitor Google Search Console’s Core Web Vitals report
   • Fix performance regressions promptly

Remember: performance optimization isn’t a one-time task, but a continuous process. Good luck with your optimization!

11 min read · Published on: Dec 19, 2025 · Modified on: Jan 22, 2026

Easton

Technology