Measure the timings at the 75th percentile of real users where you can, because averages hide the people on the slowest connections.

How do you test a Next.js app like a user on a slow network?

1. Use Lighthouse in mobile mode. Its default mobile run simulates a slower network and a slower CPU than your laptop. Run it against a production build (next build then next start), never the dev server, which is unoptimized.
2. Throttle in Chrome DevTools. In the Network panel, pick a slow preset, and in the Performance panel, slow the CPU down. Click through the real flows: sign up, the main dashboard, the key action.
3. Test from far away. WebPageTest lets you pick test locations and real devices in different regions, which shows what distance to your server adds.
4. Collect real-user data. Vercel Speed Insights or the web-vitals library report what actual visitors experience, split by country and device.

How do you enforce the budget in CI?

Put the budget in the repo so it is reviewed like code. Lighthouse CI can fail a build when a page goes over its targets.

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      startServerCommand: "npm run start",
      url: ["http://localhost:3000/", "http://localhost:3000/pricing"],
      numberOfRuns: 3,
      settings: { preset: "mobile" },
    },
    assert: {
      assertions: {
        "largest-contentful-paint": ["error", { maxNumericValue: 2500 }],
        "cumulative-layout-shift": ["error", { maxNumericValue: 0.1 }],
        "total-blocking-time": ["warn", { maxNumericValue: 300 }],
        "resource-summary:script:size": ["error", { maxNumericValue: 200000 }],
        "resource-summary:third-party:count": ["warn", { maxNumericValue: 5 }],
      },
    },
  },
};

Lighthouse runs in a lab, so it uses Total Blocking Time as a stand-in for INP. Keep INP itself for real-user monitoring.

Then run it on every pull request:

# .github/workflows/perf-budget.yml
name: perf-budget
on: pull_request
jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run build
      - run: npx @lhci/cli autorun

To see what is inside each bundle, add @next/bundle-analyzer and run it whenever the JavaScript budget fails. It usually points to one large dependency imported on every page.

Which Next.js changes save the most on slow connections?

1. Keep components on the server by default. In the App Router, Server Components send HTML, not JavaScript. Add "use client" only to the small interactive pieces, not to whole pages.
2. Load heavy client code only when needed. Charts, editors, and maps can use next/dynamic so they download after the main content, or only when the user opens them.
3. Use next/image with real sizes. Set sizes so phones get small files, and mark only the LCP image with priority.
4. Use next/font. It self-hosts fonts and avoids layout shift. Load one family with the weights you actually use.
5. Delay third-party scripts. Load analytics and chat with next/script using strategy="lazyOnload", and question whether each one is needed at all.
6. Cache at the edge. Static and revalidated pages served from a CDN close to the user cut the round trips that hurt most on high-latency networks.
7. Show something useful quickly. Streaming with loading.tsx and Suspense lets the page shell appear while slower data loads.
8. Make responses small. Send only the fields the screen needs from your API, and paginate long lists.

A small example of the first two points:

// app/reports/page.tsx (Server Component by default)
import dynamic from "next/dynamic";
import { getReport } from "@/lib/reports";

const Chart = dynamic(() => import("./chart"), {
  loading: () => <p>Loading chart...</p>,
});

export default async function ReportsPage() {
  const report = await getReport(); // runs on the server, no client JS
  return (
    <main>
      <h1>{report.title}</h1>
      <p>{report.summary}</p>
      <Chart points={report.points} />
    </main>
  );
}

What usually blows the budget?

• A UI or icon library imported whole. Import single components or icons, not the full package.
• Date, chart, and editor libraries on every page. Move them behind next/dynamic or swap for lighter options.
• Marketing scripts added after launch. Each tag manager, pixel, and widget runs on the user's phone. Give every new script an owner and a budget check.
• Unoptimized images from a CMS. Route them through next/image or the CMS's own resizing.
• Client-side data fetching for the first screen. Fetching on the server avoids a blank page waiting for a second round trip.

How does Luminix Studio approach performance for global users?

Luminix Studio builds web and mobile apps, and the AI automations around them, for startups worldwide. We treat performance as a budget that is set during scoping and checked in CI, not a cleanup sprint after launch, because users on slow networks are often the ones a growing startup is trying to reach next. If you want a Next.js app that stays fast for users everywhere, or an audit of one you already have, see luminixstudio.com.