You picked Next.js because it's supposed to be fast. Server-side rendering, static generation, built-in image optimization - the marketing writes itself. So why does your Lighthouse score look like it was built in 2012?

‍

We've audited a lot of Next.js codebases over the years. The same mistakes show up every time. Here's what they are and how we fix them.

‍

The wrong rendering strategy

The most common mistake: using getServerSideProps everywhere because it feels safer. SSR re-renders on every single request. If your product page content doesn't change every few seconds - and it almost never does - you're hammering your server and making users wait for no reason.

‍

The fix: use getStaticProps with revalidate for anything that doesn't need to be truly real-time. Product pages, blog posts, landing pages - statically generate them and serve from the edge. Reserve SSR for pages that genuinely need live, user-specific data on every load.

‍

Images nobody optimised

Next.js ships with a built-in Image component that handles lazy loading, modern format conversion, and responsive sizing automatically. Most teams skip it and use plain img tags - then wonder why Core Web Vitals are red.

‍

The fix: replace every img tag with the Next.js Image component. Set explicit width and height. Use priority only on images visible above the fold. Everything else lazy loads. This single change consistently produces some of the biggest performance gains for the least effort.

‍

JavaScript bundles nobody audited

Install a few libraries. Import them loosely. Ship far more JavaScript than any user needed. This happens quietly over months, one npm install at a time.

‍

Run @next/bundle-analyzer and look at what you're actually shipping. There's almost always a date library replaceable with native JavaScript, a utility imported in full when one function was needed, and occasionally two versions of the same package coexisting.

‍

Use next/dynamic for heavy components - chart libraries, rich text editors, complex modals - so they load only when the user actually needs them.

‍

Database queries nobody profiled

The frontend feels fast. The API feels slow. The whole page feels slow. Developers blame the framework. The framework is usually not the problem.

‍

N+1 query issues are the most consistent culprit. The pattern: fetch a list of items, then make a separate database call for each item's related data. This is invisible with small datasets and painful with real ones.

‍

Use include in Prisma or select_related in Django to fetch related data in one query. Add database indexes on every column you filter or sort by. Log query times during development - if something is slower than it should be, fix it before it hits production.

‍

Next.js doesn't make apps fast. Engineers make apps fast - using Next.js correctly. The framework gives you every tool you need. Those tools have to be used deliberately, not by accident.

‍