5 Performance Mistakes Quietly Slowing Down Your Next.js Site (and How to Fix Each One)

nxfold — Sat, 20 Jun 2026 17:53:10 +0000

Next.js gives you a fast site almost for free. The framework does a lot of heavy lifting out of the box, which is exactly why most performance problems aren't dramatic. There's no error, nothing crashes. Your Lighthouse score just sits at 72 and you're not sure why.

Below are five mistakes I see constantly in real client codebases, ordered roughly by how often they show up. Each one is small on its own. Stacked together, they're the difference between a site that feels instant and one that feels sluggish. All examples use the App Router.

1. Turning whole pages into Client Components

In the App Router, every component is a Server Component by default. The moment you add "use client" at the top of a file, that component and everything it imports gets bundled and shipped to the browser. The common mistake is slapping "use client" on an entire page just because one small piece needs interactivity.

// ❌ The whole page ships to the client just for one button
"use client";

export default function ProductPage({ product }) {
  return (

      {product.name}
      {product.description}


  );
}

The fix is to push "use client" down to the leaves. Keep the page on the server and isolate only the interactive part.

// ✅ Page stays server-rendered; only the button is a Client Component
export default function ProductPage({ product }) {
  return (

      {product.name}
      {product.description}


  );
}

// AddToCartButton.tsx
"use client";

export function AddToCartButton({ id }: { id: string }) {
  return <button onClick={() => addToCart(id)}>Add to cart;
}

The page's content renders on the server and arrives as HTML. Only the tiny button carries JavaScript. Multiply this across a whole app and your bundle shrinks dramatically.

2. Using `<img>` instead of `next/image`

This one is everywhere. A plain <img> tag ships the full-size file, blocks rendering, and does nothing clever about format or screen size. On image-heavy pages it's usually the single biggest drag on load time.

// ❌ Full-size file, no lazy loading, no modern format

next/image handles resizing, lazy loading, and modern formats like WebP automatically. It also reserves space for the image so your layout doesn't jump while it loads, which directly helps your Cumulative Layout Shift score.

// ✅ Resized, lazy-loaded, modern format, no layout shift
import Image from "next/image";

<Image
  src="/hero.jpg"
  alt="Hero"
  width={1200}
  height={600}
  priority // use only for above-the-fold images like a hero
/>

One note: priority tells Next.js to load the image immediately instead of lazily. Use it for the hero or anything visible on first paint, and leave it off everything else.

3. Importing entire libraries for one function

It's easy to write import _ from "lodash" and reach for one helper. The problem is that depending on your setup, you can pull a big chunk of the library into your bundle to use a single function.

// ❌ Risks bundling far more than you use
import _ from "lodash";
_.debounce(fn, 300);

Import the specific function instead. Your bundler only includes what you actually reference.

// ✅ Only the function you need
import debounce from "lodash/debounce";
debounce(fn, 300);

Run @next/bundle-analyzer once and you'll usually find one or two libraries quietly eating most of your bundle. It takes ten minutes to set up and it's the fastest way to find easy wins.

4. Building data-fetching waterfalls

Async/await reads cleanly, which is exactly why this mistake hides so well. Each await pauses until the previous one finishes, so three independent fetches run one after another instead of together.

// ❌ Sequential — each request waits for the one before it
const user = await getUser(id);
const orders = await getOrders(id);
const reviews = await getReviews(id);

If none of these depend on each other, fire them all at once with Promise.all. The total time drops from the sum of all three to roughly the slowest single one.

// ✅ Parallel — all three start immediately
const [user, orders, reviews] = await Promise.all([
  getUser(id),
  getOrders(id),
  getReviews(id),
]);

Only keep things sequential when a later request genuinely needs data from an earlier one. Otherwise, parallelize.

5. Not lazy-loading heavy components

Some components are expensive: charts, rich text editors, maps, video players, big modals. If they sit at the top of your import list, they load with the rest of the page even when the user can't see them yet.

// ❌ Heavy chart loads with the initial page
import HeavyChart from "@/components/HeavyChart";

next/dynamic lets you load a component only when it's actually needed, keeping it off the critical path.

// ✅ Loads on demand, with a fallback while it arrives
import dynamic from "next/dynamic";

const HeavyChart = dynamic(() => import("@/components/HeavyChart"), {
  loading: () => Loading chart…,
});

This is especially worth it for anything below the fold or behind an interaction, like a modal that only opens on click. There's no reason to pay for that JavaScript on first load.

Putting it together

None of these require a rewrite. Most are a few lines changed in files you already have. A realistic order to tackle them:

Run the bundle analyzer to see what's actually heavy.
Swap every <img> for next/image.
Fix any obvious data-fetching waterfalls with Promise.all.
Pull "use client" down to the smallest components that need it.
Lazy-load the expensive stuff with next/dynamic.

Do those five and re-run Lighthouse. A 70-something score usually jumps well into the 90s, and more importantly the site just feels quicker.

Written by the team at NxFold, a Dubai-based studio building fast, custom websites and web apps on Next.js and React. We're always happy to talk shop — find us at nxfold.com.

How Much Does a Website Cost in Dubai? (2026 Guide)

nxfold — Sat, 20 Jun 2026 17:50:11 +0000

"How much does a website cost in Dubai?" is the first question almost every business owner asks us — and the honest answer is: it depends on what you actually need. But "it depends" isn't helpful when you're trying to budget, so here are real ranges and the factors that move them.

The short answer

For a custom-built website in Dubai in 2026, most projects fall into three bands:

Brochure / marketing site (5–8 pages): a professional, conversion-focused site for a service business. Fast to ship, the most common starting point.
E-commerce store: product catalog, checkout, payments and inventory. More moving parts, more cost.
Web app or platform: custom dashboards, bookings, user accounts, internal tools. Priced by complexity, not page count.

Anyone quoting you a fixed number before understanding your goals is guessing. A good studio scopes the price to what you're trying to achieve.

What actually drives the cost

Custom design vs. template. A templated theme is cheap up front but looks like everyone else and is harder to optimise for conversions. Custom design costs more because someone is actually designing around your brand and customers.
Page count and content. More pages, more design and build. Having your copy and images ready speeds things up and lowers cost.
Functionality. A contact form is simple. Online payments, booking systems, multi-language, user logins and integrations each add real engineering.
Performance and SEO. Sites built to load fast and rank — clean code, Core Web Vitals, structured data — take more care than a quick build. It pays back in traffic.
Who builds it. A freelancer, an offshore shop and a local studio price very differently — and so does the result, the communication, and what happens when something breaks.

Cheap isn't cheap

The lowest quote often costs the most over time: slow load speeds, no SEO foundation, a template every competitor also uses, and a rebuild within a year. We've replaced plenty of "bargain" sites that never brought in a single enquiry. The right question isn't "what's the cheapest site," it's "what's the site that pays for itself."

How to budget sensibly

Start with the goal, not the page count. More bookings? More qualified leads? Online sales? The goal decides what you actually need to build.
Separate must-haves from nice-to-haves. Launch with what drives revenue; add the rest in phase two.
Ask what's included. Hosting, SEO setup, revisions, training, post-launch support — these belong in the quote, not as surprise add-ons.
Get it in writing. A clear scope, timeline and fixed price upfront protects both sides.

The NxFold approach

We scope every project to what you actually need and send an itemized, fixed quote within 24 hours — no obligation. Custom design, custom code, and a site built to convert and rank, not just to exist. If you'd rather talk it through first, tell us about your project and we'll give you a straight answer.

DEV Community: nxfold