Why Is My Next.js Site Slow? 7 Common Causes and Fixes

# Why Is My Next.js Site Slow? 7 Common Causes and Fixes Next.js is built to be fast by default — server-side rendering, automatic code splitting, built-in image optimization. So when a Next.js site is slow, it's almost always because something specific is undoing those defaults, not because the framework itself is the bottleneck. Here are the seven causes I see most often. ## 1. Images bypassing Next.js's built-in optimization **The problem:** using a plain `` tag instead of Next.js's `` component means you lose automatic resizing, format conversion (to WebP/AVIF), and lazy loading — all handled for free if you use the framework's own component. **The fix:** replace `` tags with the `next/image` component, and set explicit width and height so the browser can reserve space before the image loads (this also fixes layout shift — see [Core Web Vitals Explained](/blog/core-web-vitals-explained)). ## 2. Large, unoptimized JavaScript bundles **The problem:** importing entire libraries when only a small part is used, or importing heavy libraries into pages that don't strictly need them, bloats the JavaScript the browser has to download and run before the page becomes interactive. **The fix:** use dynamic imports (`next/dynamic`) for components that aren't needed immediately — modals, charts, anything below the fold — so their code loads only when actually needed. Run a bundle analyzer periodically to catch libraries that snuck in and are larger than expected. ## 3. Rendering everything on the client when it doesn't need to be **The problem:** marking pages or components as client-rendered by default, even when they don't need interactivity, forces the browser to download and execute JavaScript for content that could have been rendered on the server and sent as plain HTML. **The fix:** default to server components (or static/server-side rendering, depending on your Next.js version and setup) and only mark something as client-rendered when it genuinely needs browser-side interactivity — a form, a dropdown, anything responding to user input in real time. ## 4. Fetching data sequentially instead of in parallel **The problem:** a page that needs data from three different sources, fetched one after another instead of simultaneously, takes roughly the sum of all three request times instead of the time of the slowest single request. **The fix:** fire independent data requests in parallel wherever they don't depend on each other's results, so the page's total load time is bound by the slowest single request, not the sum of all of them. ## 5. Fonts loading in a way that blocks or shifts content **The problem:** custom fonts loaded without proper handling can either block text from appearing at all until the font downloads, or cause a visible layout shift once the custom font swaps in for a fallback. **The fix:** use `next/font`, which handles font loading, preloading, and fallback matching automatically, avoiding both the blocking and the layout shift. ## 6. No caching strategy for data that doesn't change often **The problem:** re-fetching the same rarely-changing data (a list of service categories, a set of settings) on every single page load wastes time on unnecessary network requests. **The fix:** use Next.js's built-in caching and revalidation options appropriately — static generation with periodic revalidation for content that changes infrequently, rather than fetching fresh on every request by default. ## 7. Third-party scripts loaded without regard for their impact **The problem:** analytics scripts, chat widgets, and marketing pixels are often added carelessly, loading synchronously and blocking the page's own rendering while a third-party server responds. **The fix:** use `next/script` with the appropriate loading strategy (`lazyOnload` or `afterInteractive` for most non-critical third-party scripts) so they load without holding up the actual content the visitor came for. ## How to diagnose which of these applies to your site Run your site through PageSpeed Insights or Lighthouse — see [A Non-Technical Guide to Reading Your Lighthouse / PageSpeed Report](/blog/how-to-read-lighthouse-report) for how to interpret the results. The specific warnings shown (large images, unused JavaScript, render-blocking resources) map fairly directly to the causes above, which makes prioritizing the fixes straightforward once you know what the report is actually telling you. If your site needs a full performance pass across all of these areas, see the [performance optimization services page](/services/performance-optimization).