loke.dev
Header image for Fixing Slow Next.js Server Actions for Data Fetching
Next.js React 19 Web Development Performance

Fixing Slow Next.js Server Actions for Data Fetching

Stop using Server Actions for GET requests. Learn why they cause performance bottlenecks and how to architect data fetching correctly in Next.js 15+ apps.

Published 4 min read

I spent three hours last Tuesday staring at a loading spinner. The app felt sluggish, the Time to Interactive was abysmal, and my Core Web Vitals were nose-diving. I had treated Next.js Server Actions like a magic wand for fetching initial data. I thought it was elegant. It was actually a performance disaster.

Stop using Server Actions for GET requests

Here is the reality check. Server Actions are designed for mutations. They handle form submissions and data modifications. When you use them to fetch data on render, you trigger a POST request every single time.

You lose the ability to cache effectively at the browser level or via CDNs. More importantly, you create a sequential waterfall. The server has to parse the request, execute the function, and send the response back before the client can even begin to hydrate. Use standard React Server Components to fetch your data directly in the component tree. If you need dynamic data unknown until runtime, stick to standard API Routes or Route Handlers.

If you find yourself calling a Server Action inside a useEffect hook just to load a list of items, stop. You are fighting the framework.

Solving the hydration mismatch

Nothing kills user trust faster than the Red Screen of Death caused by a hydration mismatch. This usually happens because you reach for window or localStorage inside a component body.

React 19 is stricter than ever. If the server renders an empty array because it cannot read the user's settings, but the client renders their custom theme immediately upon mounting, React throws its hands up. The DOM tree diverges, and the app crashes.

The fix is simple. Never touch browser-only APIs in the render phase. Instead, use the useSyncExternalStore hook or a useEffect to trigger a re-render once the component is mounted.

// Don't do this
const theme = localStorage.getItem('theme') || 'light';

// Do this instead
const [isClient, setIsClient] = useState(false);
useEffect(() => setIsClient(true), []);

const theme = isClient ? localStorage.getItem('theme') : 'light';

When to use optimistic UI updates

The useOptimistic hook in React 19 is useful, but don't over-engineer it. Many developers treat it like a state management library. It isn't. It exists to reflect server state before the server has actually responded.

If your user clicks "Like," you update the UI count immediately. If the server action fails, you revert it. Don't use this for every single fetch operation. If you are moving data around, stay with React Query or SWR. They are built for synchronization, caching, and background revalidation. Use useOptimistic for high-frequency user interactions where latency is the primary enemy of "feel."

The React 19 migration trap

If you are currently mid-migration, you have likely seen the forwardRef warning. It is gone. React 19 treats ref as a normal prop. You don't need the boilerplate anymore.

// Old way
const MyInput = forwardRef((props, ref) => <input {...props} ref={ref} />);

// React 19 way
const MyInput = ({ ref, ...props }) => <input {...props} ref={ref} />;

The silent failure here is in custom components that rely on implicit refs. If you have a legacy codebase, run the codemods provided by the React team. Don't try to refactor these by hand. You will miss a component buried in your dependency tree, and it will fail silently in production.

Architecting for 2026

We need to stop treating Next.js as a "do everything" black box.

1. Fetch in components using Server Components.
2. Mutate with Server Actions.
3. Handle client state with standard hooks.

When you misuse Server Actions for data fetching, you aren't just slowing down the app. You are bypassing the entire caching architecture that makes Next.js fast in the first place. Revalidate your data, use your cache tags, and keep your business logic on the server where it belongs. Stop trying to force the framework to do things it wasn't built to do. Your performance bottlenecks will vanish.

Resources

- Why not use server actions to fetch data (Reddit)
- React 19 migration traps (DEV)
- Fixing React hydration errors (Medium)

Resources