Why your Next.js site feels slow (and how to fix it)

Performance work has a reputation for being invisible: weeks of effort, no visible design change. The numbers still move, and they correlate directly with conversion, bounce rate, and what a paid campaign costs per click. Most of the damage comes from a short list of fixable causes.

A Next.js build is not automatically fast. Most slow sites we audit share the same three problems: unoptimized images, blocking third-party scripts, and layouts that shift as content loads. Fixing those three usually cuts load times by more than half.

In nearly every audit, the largest contentful paint is an image, the biggest layout shift is a late-loading banner or font, and the longest blocking task comes from an analytics or chat widget. The framework is rarely the bottleneck.

Rather than chasing a perfect score, we work through a prioritized checklist against real device data:

Results from a recent marketing site rebuild, measured on mobile field data over 30 days:

Start with the assets: images, fonts, and video are usually the heaviest and easiest wins. Fixing them rarely requires touching application logic.

Then treat third-party scripts like dependencies. If a tool cannot justify its weight against a business goal, remove it or load it lazily.

A faster site is a set of constraints you keep in place: a performance budget, a script review process, and field monitoring that catches regressions before customers do.