DEV Community: Codexomation

Next.js Performance Optimization: Get 95+ PageSpeed Scores in 2025

Codexomation — Thu, 27 Aug 2026 04:06:14 +0000

Why Performance Matters More Than Ever

Google's Core Web Vitals have been a ranking factor since 2021. But beyond rankings, performance is user experience — and user experience is revenue.

Amazon found that every 100ms of latency cost 1% in sales. Walmart reported a 2% conversion increase for every 1 second of improvement in page load time. These aren't ancient statistics — they're more relevant than ever as user expectations continue rising.

Next.js is built for performance. But Next.js can still be slow if you don't understand which optimizations are defaults, which require explicit configuration, and which common patterns actively harm performance.

Understanding Core Web Vitals

Google measures three Core Web Vitals:

Largest Contentful Paint (LCP): How long until the largest visible element is rendered. Target: under 2.5 seconds. This is usually your hero image, hero text, or main content block.

Cumulative Layout Shift (CLS): How much the page layout shifts during loading. Target: under 0.1. Caused by images without dimensions, dynamically injected content, and web fonts loading.

Interaction to Next Paint (INP): How quickly the page responds to user interactions. Target: under 200ms. This replaced FID (First Input Delay) in 2024.

All three need to pass in "Good" range (75th percentile) for your URLs to be considered "Good" by Google.

Next.js Performance Defaults (Free Wins)

Next.js includes several performance features out of the box. Make sure you're not accidentally disabling them.

Automatic Code Splitting

Next.js automatically splits your JavaScript bundle by route — each page only loads the JavaScript it needs. Don't work against this by importing large libraries at the root level when they're only needed in specific components.

Server Components (App Router)

With the App Router, components default to server components — they render on the server and send only HTML to the client. Zero JavaScript overhead for these components.

// This is a Server Component by default — no "use client" directive
// It renders on the server, sends HTML, zero JS bundle impact
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug); // Direct DB access, no API round-trip
  return <article>{post.content}</article>;
}

Only add "use client" when you actually need browser APIs, React hooks, or event listeners. Client components add to your JavaScript bundle.

Image Optimization

next/image automatically:

Converts to WebP/AVIF
Resizes for the device requesting it
Lazy loads by default
Prevents layout shift with required width and height

import Image from "next/image";

// Always specify width and height (or use fill + parent with position:relative)
<Image
  src="/hero.jpg"
  width={1200}
  height={630}
  alt="Hero image"
  priority // Add this to the above-the-fold image (disables lazy loading)
/>

Common mistake: Using <img> instead of next/image. This bypasses all optimization.

Font Optimization

Fonts are one of the most common sources of both CLS and LCP degradation.

Using next/font

import { Space_Grotesk } from "next/font/google";

const font = Space_Grotesk({
  subsets: ["latin"],
  display: "swap", // Prevents invisible text during font load
  variable: "--font-space-grotesk",
  preload: true, // default
});

next/font handles:

Self-hosting fonts (no Google Fonts round-trip)
Automatic font preloading
font-display: swap to prevent invisible text
Variable font slicing (only loads the weights you use)

Never do this in App Router:

<!-- Don't import Google Fonts via <link> in layout.tsx -->
<link href="https://fonts.googleapis.com/..." />

This causes an additional network round-trip and can't be preloaded optimally.

Eliminating Font-Related CLS

CLS from fonts happens when the font loads and causes text reflow. Fix it with:

font-display: swap (already in next/font)
size-adjust CSS property to match fallback font metrics
Or next/font's adjustFontFallback: true option (experimental, but effective)

Bundle Size Optimization

Analyze Your Bundle

npm install --save-dev @next/bundle-analyzer

// next.config.js
const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});
module.exports = withBundleAnalyzer({});

ANALYZE=true npm run build

This generates a visual map of your bundle. Look for:

Libraries that are much larger than expected
Duplicate packages (two versions of the same library)
Libraries that should be lazy-loaded (charts, rich text editors, date pickers)

Tree Shaking Anti-Patterns

Bad: Import entire library

import _ from "lodash"; // Imports 70kb of lodash
_.debounce(fn, 300);

Good: Import only what you need

import debounce from "lodash/debounce"; // Imports 1.5kb

Even better for simple utilities: Use browser APIs or small focused packages

// Debounce without lodash
function debounce<T extends (...args: unknown[]) => unknown>(fn: T, delay: number) {
  let timer: ReturnType<typeof setTimeout>;
  return (...args: Parameters<T>) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delay);
  };
}

Lazy Loading Heavy Components

Don't load components that aren't visible on first render:

import dynamic from "next/dynamic";

// This component's JavaScript only loads when it's needed
const HeavyChart = dynamic(() => import("./HeavyChart"), {
  loading: () => <div className="h-64 bg-gray-100 animate-pulse rounded" />,
  ssr: false, // For components that use browser APIs
});

// Lazy load with intersection observer trigger (for below-fold)
const VideoPlayer = dynamic(() => import("./VideoPlayer"), {
  ssr: false,
});

What to lazy load:

Chart libraries (Chart.js, Recharts — often 200–300kb)
Rich text editors (Tiptap, Quill — 200–400kb)
Date/time pickers
Video players
Map libraries (Leaflet, Google Maps)
Analytics and chat widgets

Caching Strategy

Static Generation (Best Performance)

Pages with static data should use Static Generation:

// generateStaticParams makes these routes static at build time
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map(p => ({ slug: p.slug }));
}

// No dynamic function = static page
export default function BlogPost({ params }) {
  const post = getPostBySlug(params.slug);
  return <article>{post.content}</article>;
}

Static pages are served from CDN edge nodes — effectively zero time to first byte.

Incremental Static Regeneration (ISR)

For pages that need to stay updated without a full redeploy:

// Regenerates every 60 seconds if requested
export const revalidate = 60;

export default async function ProductPage({ params }) {
  const product = await fetchProduct(params.id); // Fetches fresh data on revalidation
  return <div>{product.name}</div>;
}

Route Segment Config

// Force dynamic rendering (when you need fresh data on every request)
export const dynamic = "force-dynamic";

// Cache the route for 1 hour
export const revalidate = 3600;

Image Optimization Deep Dive

Preloading Critical Images

The hero image should load as fast as possible. Add priority to images above the fold:

<Image src="/hero.jpg" priority width={1920} height={1080} alt="..." />

This adds <link rel="preload"> to the document head, starting the image download earlier.

Responsive Images

<Image
  src="/hero.jpg"
  fill // Parent must have position: relative
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
  className="object-cover"
/>

The sizes attribute tells the browser what size the image will be at different viewport widths. This enables correct srcset generation, preventing the mobile browser from downloading a 1920px image for a 390px screen.

Modern Image Formats

In next.config.ts:

const config: NextConfig = {
  images: {
    formats: ["image/avif", "image/webp"],
  },
};

AVIF is 50% smaller than WebP and 80% smaller than JPEG at the same quality. Not all browsers support it yet, but Next.js serves the appropriate format per browser.

Third-Party Script Optimization

Third-party scripts (analytics, chat, ads) are the #1 cause of slow websites that look well-optimized in theory.

Using next/script

import Script from "next/script";

// strategy options:
// - "beforeInteractive": loads before page hydration (use sparingly)
// - "afterInteractive": loads after page hydration (default, most analytics)
// - "lazyOnload": loads during browser idle time (chat widgets, social embeds)
// - "worker": offloads to web worker (experimental, best performance)

<Script
  src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXXX"
  strategy="afterInteractive"
/>

Chat widgets like Intercom should use lazyOnload — they don't need to load until the user is engaged with the page.

Partytown for Analytics

Partytown offloads third-party scripts to a web worker, preventing them from blocking the main thread:

npm install @builder.io/partytown

This can improve INP scores by 30–60ms on analytics-heavy pages.

Database and API Query Optimization

Slow server responses hurt LCP even when the client-side is optimized.

React Cache for Deduplication

import { cache } from "react";

// Multiple components can call this — React deduplicates into one fetch
export const getPost = cache(async (slug: string) => {
  return db.post.findUnique({ where: { slug } });
});

Connection Pooling

Direct database connections don't scale in serverless environments. Use connection pooling:

PgBouncer (PostgreSQL)
Prisma Accelerate (built-in connection pooling + query cache)
Supabase Session Pooler (Supabase users)

Select Only What You Need

// Bad: fetches entire record including large content field
const post = await db.post.findMany();

// Good: only fetch what the listing page needs
const posts = await db.post.findMany({
  select: { slug: true, title: true, excerpt: true, date: true }
});

Measuring and Monitoring

Local Testing

npm run build
npm start
# Lighthouse in Chrome DevTools → Performance tab

Test in production mode. Development mode is intentionally slower.

Real-World Monitoring

Google PageSpeed only gives you a lab measurement. Real User Monitoring (RUM) shows how your actual visitors experience the site.

Tools:

Vercel Analytics — built-in Core Web Vitals per URL for Vercel-hosted sites
Google Search Console → Core Web Vitals report
Sentry Performance — detailed transaction tracing

Performance Budget

Set a performance budget and enforce it in CI:

{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.90}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}]
      }
    }
  }
}

Quick Wins Checklist

Before deep optimization, check these quick wins:

All above-fold images use priority prop
All images have explicit width and height or use fill
Using next/font instead of Google Fonts <link>
Heavy components (charts, editors) are lazy loaded with dynamic()
Third-party scripts use appropriate strategy
next.config.ts enables AVIF/WebP formats
Database queries use select to fetch only needed fields
Static pages use generateStaticParams
No "use client" on components that don't need it

If your Next.js site is underperforming and you need expert optimization, reach out to our team — we audit and optimize Next.js applications for both performance and SEO as a standalone service.

What Actually Breaks When You Put AI Agents In Front Of Real Customers

Codexomation — Wed, 26 Aug 2026 00:01:57 +0000

I have spent the last year building AI automation systems for small businesses. Chatbots, multi agent workflows, the kind of stuff that looks great in a demo and then meets an actual customer who types "idk just fix it" and breaks everything.

Most articles about AI agents talk about architecture. LangGraph vs CrewAI, which vector store to use, how to chain prompts. That stuff matters, but it is not what actually keeps these systems alive once real money and real users are involved. Here is what I wish someone had told me before I shipped the first one.

The demo lies to you

Every agent demo works because you, the builder, know how to talk to it. You phrase things clearly. You do not typo. You do not ask three questions at once. You do not go silent for ten minutes then come back and say "wait what were we talking about."

Real users do all of that constantly. The single biggest gap between a working prototype and a working product is handling the messy, half formed, contradictory way people actually type when they are in a hurry or annoyed. If you have not tested your agent with genuinely bad input, you have not tested it.

What helped: I started keeping a running file of every weird input a real user sent that confused the agent. Once you have fifty of these, patterns show up fast, and you can build handling for the actual failure modes instead of the ones you imagined.

Silent failures are worse than loud ones

Early on I built a workflow automation that pulled data from a CRM, ran it through a couple of AI steps, then pushed it into an email tool. When one step failed, the whole thing just quietly stopped. No error, no log anyone checked, nothing. The client found out three days later when they noticed no follow up emails had gone out.

Now every multi step agent pipeline I build has to answer one question before it ships: when this breaks, who finds out, and how fast? Not if it breaks. When. If the answer is "eventually, by accident," that is not done yet.

Give the agent a way to say "I don't know"

This sounds obvious but it is the thing teams skip because it is unglamorous. An agent that confidently makes something up is far more dangerous than one that says "I am not sure, let me get a human." I have seen support bots invent refund policies that did not exist because nobody explicitly told the model it was allowed to punt.

Building the punt path is not a fallback you bolt on later. It needs to be a first class part of the design, with its own testing, same as the happy path.

Cost creeps up on you fast

A single agent call is cheap. A multi agent system where three or four models talk to each other, sometimes in loops, adds up in ways that are easy to miss until the bill shows up. I had a workflow where an agent would occasionally get stuck re checking its own output in a loop because of a badly worded stop condition. Nobody noticed for two weeks because each individual call was pennies.

Now I put hard caps on every loop and log every model call with a request id, so if something runs away, I can see it in the dashboard instead of the invoice.

Clients do not want "AI." They want the annoying task gone

This one changed how I sell and build entirely. Nobody wakes up excited about a multi agent system. They wake up annoyed that someone on their team spends four hours a week manually copying leads between two tools. The AI part is the how, not the what. The moment I stopped leading with the tech and started leading with the specific task disappearing, projects got easier to scope and easier to keep alive after launch, because success was measured by "does this task still need a human" instead of "is the AI impressive."

The part nobody tells you: maintenance is the real job

Shipping the first version is maybe 30 percent of the actual work. APIs change. The model provider quietly updates behavior. Your client's CRM adds a new required field and your integration breaks at 2am. Agent based systems touch more moving parts than a normal app, so they break in more places, and the person who has to own that is usually whoever built it, not whoever bought it.

If you are freelancing or running a small shop building these systems, price the maintenance in from day one. It is not optional work you might get lucky and skip.

None of this is meant to talk anyone out of building with AI agents. They genuinely solve real problems when built with the failure modes in mind instead of bolted on after something breaks in production. I just wish more of what I read before starting was about the boring, unglamorous stuff instead of the architecture diagrams.

If you are building something similar, I would love to hear what broke for you first. It is almost never the thing you expected.