What's Actually New in Next.js: A Practical Guide to the Latest App Router

Next.js keeps shipping fast, and it's easy to lose track of which changes are cosmetic and which ones actually change how you should structure an app. This is a practical rundown of what's worth adopting in current projects—not a changelog dump.

Turbopack is the default, and it matters more than it sounds

Turbopack moving from opt-in to the default dev (and increasingly build) bundler isn't just a speed bump. Cold starts on large App Router projects that used to take 10-15 seconds now start in a couple. Hot reload on a deeply nested component tree stays fast even as the project grows, instead of degrading linearly with file count.

The practical impact: teams that avoided splitting code into more, smaller files because "the dev server gets slow" no longer have that excuse. Smaller, single-purpose components and hooks are cheap again.

next dev   # Turbopack by default, no flag needed
next build # Turbopack build is stable for most App Router projects

Partial Prerendering is production-ready, and it changes how you think about pages

Partial Prerendering (PPR) lets a single route ship a static shell instantly while dynamic, per-request parts stream in around it. Before PPR, a page was effectively all-static or all-dynamic—one cookies() or headers() call anywhere in the tree forced the whole route dynamic.

Now, wrap the dynamic slice in <Suspense> and everything outside it prerenders at build time:

import { Suspense } from "react";
import { StaticHeader } from "@/components/static-header";
import { UserGreeting } from "@/components/user-greeting";

export default function DashboardPage() {
  return (
    <main>
      {/* Prerendered once, served instantly from the edge */}
      <StaticHeader />

      {/* Streamed per-request, has access to cookies/headers */}
      <Suspense fallback={<GreetingSkeleton />}>
        <UserGreeting />
      </Suspense>
    </main>
  );
}

The mental shift: stop asking "is this page static or dynamic?" and start asking "which parts of this page actually need per-request data?" Most dashboards are 90% shell and 10% personalized content—PPR lets the shell behave like a static site while the personalized slice behaves like an API response.

Caching got more explicit, which is a good thing

Earlier versions of the App Router cached fetches aggressively by default, which was fast but confusing—people got burned by stale data they didn't expect to be cached. The current model favors explicit opt-in:

// Uncached by default: always fresh
export async function getOrders(userId: string) {
  const res = await fetch(`https://api.example.com/orders?user=${userId}`);
  return res.json();
}

// Explicit caching with tags for targeted invalidation
export async function getProductCatalog() {
  const res = await fetch("https://api.example.com/products", {
    next: { tags: ["catalog"], revalidate: 3600 },
  });
  return res.json();
}

"use server";
import { revalidateTag } from "next/cache";

export async function updateProduct(id: string, data: ProductInput) {
  await db.products.update(id, data);
  revalidateTag("catalog"); // Only invalidates what's actually stale
}

If you inherited a project from the earlier caching model, it's worth an afternoon to audit fetch calls and make caching intent explicit rather than relying on defaults you can't see at a glance.

Server and Client Components: the rule of thumb that finally sticks

After a few years of the App Router, the guidance that survives contact with real projects is simple:

The pattern that works best in practice: push "use client" as far down the tree as possible. A page can be a Server Component that renders a Server Component list, with only the individual interactive row—say, a "favorite" button—marked as a Client Component. Don't mark a whole page client just because one button needs onClick.

// Server Component: fetches and renders, ships zero JS for this part
export async function ProductCard({ id }: { id: string }) {
  const product = await getProduct(id);
  return (
    <div className="rounded-lg border p-4">
      <h3>{product.name}</h3>
      <p>{product.price}</p>
      <FavoriteButton productId={id} /> {/* only this hydrates */}
    </div>
  );
}

Server Actions are boring now, in the best way

Server Actions stopped feeling experimental. Combined with useActionState and useFormStatus, they cover the vast majority of form and mutation use cases without a client-side data-fetching library:

"use server";

export async function submitContact(prevState: unknown, formData: FormData) {
  const email = formData.get("email");
  if (typeof email !== "string" || !email.includes("@")) {
    return { error: "Enter a valid email address." };
  }
  await sendContactEmail(formData);
  return { success: true };
}

"use client";
import { useActionState } from "react";
import { submitContact } from "./actions";

export function ContactForm() {
  const [state, formAction, pending] = useActionState(submitContact, null);
  return (
    <form action={formAction}>
      <input name="email" type="email" required />
      <button disabled={pending}>{pending ? "Sending…" : "Send"}</button>
      {state?.error && <p role="alert">{state.error}</p>}
    </form>
  );
}

No client-side fetch, no manual loading state, no separate API route for a simple mutation.

What to actually do with this

If you're maintaining an existing App Router project: audit your fetch calls for caching intent, look for pages that are marked dynamic unnecessarily, and see where PPR could turn a slow dashboard into an instant-shell one.

If you're starting fresh: default to Server Components, reach for Server Actions before a separate API route, and only add a client-side data library when you have a genuine case for it—optimistic UI beyond what useOptimistic covers, or client-side caching across many independent components.

The theme across all of these changes is the same: less implicit magic, more explicit control, and a framework that gets out of the way once you understand the few rules that actually matter.