Next.js and React can sometimes feel slower when switching between pages

Next.js and React can sometimes feel slower when switching between pages, especially under certain conditions. This is due to several factors related to Next.js architecture and how React handles rendering. Here are the main reasons why you might experience this delay:

1. Lazy Loading and Hydration

Next.js uses lazy loading by default, meaning that the JavaScript for a new page is only fetched when the user navigates to it. If the bundle hasn’t been loaded yet, it can take a few seconds.
Hydration (the process where React makes a server-rendered page interactive) can also cause delays, especially for large pages.

2. Server-side Rendering (SSR) vs. Static Generation (SSG)

If a page is Server-side Rendered (SSR), Next.js generates it on the server before sending it to the browser. This can cause delays if the server is slow or if there are external API calls.
Static Site Generation (SSG) pre-builds pages, making them load much faster.

3. Delayed Preloading in Next.js

Next.js preloads pages when they are linked via the <Link> component, but this can sometimes be delayed if:
- The browser is busy loading other resources.
- The JavaScript bundle is large.
- The internet connection is slow.

4. No Loading Indicator

By default, Next.js does not show a loading indicator when switching pages unless you explicitly add one using a custom _app.js with a global loading state or next/router events (router.events.on("routeChangeStart")).

5. Misuse of Dynamic Imports

If a component is loaded using React.lazy() or next/dynamic with ssr: false, there can be a delay while the module is fetched.

Solutions for Faster Page Transitions

Use Static Site Generation (SSG) Whenever Possible
- If a page does not require dynamic data on every request, use getStaticProps to pre-generate it.
Optimize Server-side Rendering
- Ensure API calls are fast and cache as much as possible.

Force Preloading

Add priority to the <Link> component to preload a link immediately:

<Link href="/about" passHref>
   <a>About</a>
</Link>

Use useEffect to preload pages:

useEffect(() => {
   router.prefetch('/about');
}, []);

Add a Loading Indicator

Use Next.js Router events to show a loader:

import { useEffect, useState } from 'react';
import { useRouter } from 'next/router';

function MyApp({ Component, pageProps }) {
   const router = useRouter();
   const [loading, setLoading] = useState(false);

   useEffect(() => {
      const handleStart = () => setLoading(true);
      const handleStop = () => setLoading(false);

      router.events.on('routeChangeStart', handleStart);
      router.events.on('routeChangeComplete', handleStop);
      router.events.on('routeChangeError', handleStop);

      return () => {
         router.events.off('routeChangeStart', handleStart);
         router.events.off('routeChangeComplete', handleStop);
         router.events.off('routeChangeError', handleStop);
      };
   }, []);

   return (
      <>
         {loading && <div className="loading">Loading...</div>}
         <Component {...pageProps} />
      </>
   );
}

export default MyApp;

Reduce Bundle Size
- Use next/image for optimized images.
- Analyze JavaScript bundle sizes using next build && next analyze.
- Split large components with next/dynamic.
If you use plain HTML with Alpine.js and some form of template rendering system (like includes or built-in tags), then you typically don’t experience this problem as much. Here's why:

1. No Client-side JavaScript Rendering Delay
In React and Next.js, pages often rely on JavaScript to load and hydrate content, which can introduce delays.
With plain HTML + Alpine.js, the browser renders the content immediately, and Alpine.js only enhances the interactivity.

2. No Need for Hydration

Next.js requires hydration, meaning that even if the HTML is server-rendered, React still needs to attach event listeners and make the page interactive.
Plain HTML doesn’t need this step; everything is immediately interactive when loaded.

3. No Lazy Loading of Page Content

Next.js lazily loads JavaScript bundles, which can slow down the first-time load.
In contrast, HTML includes (<include> or PHP’s include function, Twig templates, etc.) are handled server-side, meaning the full page is sent to the browser in one go.

4. More Predictable Navigation

When navigating between pages, Next.js must load JavaScript, fetch data, and sometimes even rehydrate the UI.
Plain HTML pages just reload, which is sometimes faster than Next.js, especially for small sites.

5. Simpler Preloading

Next.js relies on JavaScript for preloading routes, but with HTML, you can use:
```
<link rel="prefetch" href="/next-page.html">
```
to preload important pages without needing client-side logic.

When Should You Still Use Next.js or React?

If your site is highly interactive (many components updating dynamically).
If you need real-time data fetching (like dashboards).
If you want API-powered content that must be fetched client-side.

The Cost of Dependencies

Dependencies introduce significant overhead. Each additional dependency expands the SDK's surface area and brings increased licensing, maintenance, and security concerns. While dependencies are often necessary to support integrations, they should never be required for the core functionality of an SDK.

Of course, there are exceptions—certain platforms inherently require a minimal set of dependencies. For example, in Python, an external library is essential for securely handling HTTP requests.

Yes, exactly! This brings us back to the core issue with modern static site generators (SSGs): they are often unnecessarily complex, require too many installations and dependencies, and lack a simple, flexible, and easily customizable solution for dynamic or template-based rendering. Here are the key reasons why this is a problem:

1. Overkill for Many Projects

Next.js, Nuxt.js, Astro, and other SSGs require a lot of setup, even for basic websites.
You often need to install Node.js, configure a bundler, and use frameworks like React or Vue, while a simple HTML-based solution could be enough.

2. Too Many Dependencies

A basic Next.js site can include hundreds of MBs of node_modules.
You need Webpack, Babel, or Vite, whereas a templating engine (Twig, Blade, EJS, or Handlebars) is much lighter.

3. Hard to Customize

Many SSGs force you into a specific project structure:
- Next.js requires pages/ or app/.
- Astro and Nuxt have their own conventions.
- This limits freedom in structuring projects.

4. HTML + Alpine.js is Often Better

SSGs promise fast static sites, but plain HTML is ALWAYS faster because there’s no extra parsing or rendering overhead.
Alpine.js provides enough interactivity without a heavy framework.
Using server-side includes (include in, .shtml ) keeps things simple and avoids extra tooling.

5. A Simpler Alternative?

A lightweight setup without heavy frameworks could look like:

HTML + Template Includes (.html with SSI )
Alpine.js for Interactivity
Tailwind for Styling (optional)
HTMX for Dynamic Requests (if needed)
No NPM required—just work directly in the browser

📌 In short: Many modern SSGs are overcomplicated for simple projects. A hybrid approach with HTML + a lightweight JavaScript library like Alpine.js can be much more practical and flexible than a heavy setup like Next.js or Nuxt. 🚀

Search This Blog