Forem: Alessandro Grosselle

How to Return HTTP 410 (Gone) Status in Next.js App Router: Two Workarounds

Alessandro Grosselle — Sat, 24 Jan 2026 22:08:33 +0000

Context

In marketplace applications, the HTTP 410 (Gone) status code is crucial for indicating that an item is no longer available.
For second-hand marketplace platforms like Vinted or similar e-commerce sites, returning a 410 status is essential for SEO; it signals to search engines that the content has been permanently removed and should be deindexed.

The Challenge

Let's say you need to implement a Next.js page using App Router that returns a 410 status. The typical flow would be:

Fetch data from your backend service
Backend returns 410 (Gone)
Frontend displays a 410 page (perhaps suggesting other listings)
Browser and search engines see the 410 status code

Sounds simple, right? Wrong!

Currently, Next.js App Router does not support forcing a 410 status code. While it provides:

redirect()
notFound()
unauthorized() (experimental)
forbidden() (experimental)

There's no built-in way to return a 410 status.

A PR proposing a gone() function has been submitted, but there's no ETA on when it will be merged.

Purpose of This Article

Intrigued by this limitation, I explored alternatives rather than waiting for the PR. I've identified two possible workarounds (I hesitate to call them "solutions" - they're definitely workarounds).

All code examples are available in this GitHub repository.

Solution 1: Custom Express.js Server

If your application uses a custom server like Express.js, this is the best workaround I've found.

The Strategy

In your Next.js page, when your backend returns 410, call Next.js's notFound() (which generates a 404)
At the Express.js level, intercept the 404 and override it to 410

Implementation

Next.js Page Implementation

Here's a simple page that uses notFound() when the backend returns 410:

// app/page-with-error-using-express/page.tsx
import { notFound } from 'next/navigation';
import { getContentById } from '@/app/api/content/utils';

type SearchParams = Promise<{ [key: string]: string | string[] | undefined }>;

export default async function Page({
  searchParams,
}: {
  searchParams: SearchParams;
}) {
  const params = await searchParams;
  const contentId = params.id as string;

  const contentDetailsResponse = await getContentById(contentId);
  const body = await contentDetailsResponse.json();

  // Handle 410 Gone status using Next.js notFound function
  if (contentDetailsResponse.status === 410) {
    notFound();
  }

  return (
    <>
      <h1>Ad details</h1>
      {JSON.stringify(body, null, 2)}
    </>
  );
}

View on GitHub

Express.js Server with Status Code Interception

Now here's the magic: we intercept the statusCode:

// server.ts
  server.get('/page-with-error-using-express', async (req, res) => {
    // Intercept statusCode property to change 404 to 410
    let currentStatusCode = res.statusCode;
    Object.defineProperty(res, 'statusCode', {
      get() {
        return currentStatusCode;
      },
      set(value) {
        if (value === 404) {
          console.log('Intercepted 404 in statusCode setter, changing to 410');
          currentStatusCode = 410;
        } else {
          currentStatusCode = value;
        }
      },
      configurable: true,
    });

    // Render the Next.js page
    await app.render(
      req,
      res,
      '/page-with-error-using-express',
      req.query as ParsedUrlQuery,
    );
  });

View on GitHub

How It Works

The key is intercepting the response before it's sent:

Before calling app.render(), we override the statusCode property setter using Object.defineProperty()
When Next.js tries to set res.statusCode = 404 (from notFound()), our interceptor catches it
We change it to 410 before the headers are sent to the browser
The browser receives a 410 status code

Important Note: You must intercept before app.render() is called. Here's why:

app.render() internally does:
1. Process the route
2. Call res.writeHead(404, headers)  ← Sends status to browser
3. Call res.write(htmlContent)        ← Sends body
4. Call res.end()                     ← Closes connection
5. Return to your code (too late!)

If you check res.statusCode after app.render(), the response has already been sent with 404 headers.

Solution 2: Using Next.js Middleware (proxy.ts)

If you don't have a custom server or prefer not to add that logic to your server, here's an alternative approach using Next.js middleware.

The Strategy

The proxy/middleware is called before the React Server Component logic executes. The idea:

Check the content status in the middleware
If it returns 410, rewrite to an error page with 410 status

Implementation

Middleware with 410 Handling

// proxy.ts
export async function proxy(request: NextRequest) {
  if (request.url.includes('/page-with-error-using-proxy')) {
    const url = new URL(request.url);
    const contentId = url.searchParams.get('id');

    if (contentId) {
      const contentDetailsResponse = await getContentById(contentId);

      if (contentDetailsResponse.status === 410) {
        return NextResponse.rewrite(
          new URL(`/page-with-error-using-proxy/410`, request.url),
          {
            status: 410,
          },
        );
      }
    }
  }

  return NextResponse.next();
}

View on GitHub

The Caveat

Everything works well, BUT there's a significant drawback: you need to make the same API call twice:

First in the middleware/proxy to check the status
Again in the page component to fetch the actual data

You might think "let's use React's cache function to optimize!" Great idea, but unfortunately it won't work because the middleware and page run in different contexts, so the cache isn't shared.

This solution is viable if:

You don't mind the duplicate API call
OR you don't need to fetch data at all (status check only)
OR your API is fast enough that the duplicate call isn't a concern

Conclusion

The goal of this article was to share my two workaround approaches and, more importantly, to understand if others have faced the same problem and how they've solved it.

Questions for the community:

Have you encountered this limitation in Next.js App Router?
Do you have alternative solutions?
What's your preferred workaround?

To the Vercel/Next.js team: Are there better approaches we should consider? Any updates on the gone() function PR?

Until Next.js provides native support for custom status codes, these workarounds can help you properly handle 410 responses in your marketplace or e-commerce applications.

Comparing Page Transition Strategies in Next.js: A Performance Study

Alessandro Grosselle — Sun, 26 Oct 2025 14:31:08 +0000

In the era of modern web development, we often ask ourselves: what's the best way to navigate between pages?
By "best," I mean providing a user experience that's as smooth and continuous as native apps have trained us to expect.

If you're a developer working with Next.js, you've probably noticed several features that support navigation.
You're likely using the next/link component for client-side navigation, similar to a single-page application.
And if you're staying current, you might have heard about exciting new web platform features like Speculation Rules and CSS View Transitions.

With all these options available, I wanted to answer a simple question:
What's the optimal way to navigate between pages in a Next.js application?

The Experiment

To answer this question, I built a comparison project testing different navigation strategies:

Standard HTML navigation: Traditional anchor tags. Experiment link
Next.js SPA navigation: Client-side routing. Experiment link
Speculation Rules + CSS View Transitions: Experiment link
Speculation Rules + Next.js Loading UI: Experiment link
Quicklink + CSS View Transitions: Experiment link
Quicklink + Next.js Loading UI: Experiment link

Source Code: https://github.com/ale-grosselle/view-transition-comparison
Demo homepage: https://view-transition-comparison.vercel.app/

Test Case Setup

The experiment simulates a real-world e-commerce scenario:

A listing page displaying multiple products
Product detail pages that load when clicking an item
Products stored locally with a simulated 500ms loading delay to make differences visible. You can find the data layer implementation here: src/lib/api.ts

How I Measured Performance

Beyond "my personal" visual observation, I used three key metrics to evaluate user experience:

1. TTFB (Time To First Byte)

The standard web metric measuring how long it takes to receive the first byte of data after requesting a page.

2. Transition Time (Custom Metric)

This measures the actual perceived loading time from the user's perspective:

On beforeunload, we store the current timestamp in a cookie (src/app/layout.tsx)
On the new page load, we calculate: Date.now() - unloadTime
Implementation: src/components/TransitionTracker.tsx

3. Skeleton Load Time (Custom Metric)

For tests using Next.js loading states, this measures navigation continuity:

We record when the skeleton/loading component appears (app/layout.tsx)
We calculate: skeletonRenderTime - unloadTime
This shows how quickly users get visual feedback that navigation is happening

All metrics are displayed in the top-right corner of detail pages during testing

Test Conditions
All measurements were performed with:

Network: Fast 4G throttling in Chrome DevTools
CPU: 4x slowdown
Browser Cache: Enabled
5 runs per strategy for statistical validity

Results & Analysis

Strategy 1: Standard HTML Navigation

📺 Demo | 💻 Code

Results:

Average Transition Time: 1,555ms
Average TTFB: 37.6ms

This is our baseline: traditional full-page reloads.
Nothing fancy, but it's the most reliable approach when dealing with complex external scripts, analytics, and third-party widgets.

Strategy 2: Next.js SPA Navigation

📺 Demo | 💻 Code

Results:

No page reload - instant content updates

The smoothest experience by far. Navigation feels instant because we never reload the page.

Important Considerations:

Memory Leaks: In a true SPA, memory leaks accumulate over time. In multi-page apps, each navigation "resets" memory.
Third-Party Scripts: Many external scripts (analytics, widgets, GTM) rely on page load events. These won't fire in a SPA, potentially breaking functionality.
SEO Metrics: Tools like Google PageSpeed Insights measure full page loads. SPA navigation bypasses these measurements after the initial load.

Strategy 3: Speculation Rules + CSS View Transitions

📺 Demo | 💻 Code

Implementation:

Speculation Rules: components/SpeculationRulesScript.tsx
View Transitions: view-transition.css

Results (When Prefetched):

Average Transition Time: 970ms
Average TTFB: 3.2ms

This is where it gets exciting! Speculation Rules allow the browser to prefetch or prerender pages before users click.
Combined with CSS View Transitions, you get smooth, animated page changes.

I used prefetch with "moderate" eagerness rather than prerender. While prerender is more aggressive and faster, it loads entire pages in the background, which can be resource-intensive.

You can see the full implementation in components/SpeculationRulesScript.tsx.

User Experience:

When prefetched: Near-instant with beautiful transitions
When not prefetched: Still smooth with nice animations

Browser Support: Chrome 121+ and Edge (limited)

You can verify prefetching in Chrome DevTools:

Strategy 4: Speculation Rules + Next.js Loading UI

📺 Demo | 💻 Code

Results (When Prefetched):

Average Transition Time: 989ms
Average Skeleton Load: 127ms
Average TTFB: 3.4ms

This combines Speculation Rules with Next.js Loading UI, showing skeleton screens while content loads.

The Skeleton Load metric is crucial here, it shows navigation happens within ~127ms, giving users immediate feedback.

User Experience:

When prefetched: Extremely smooth with instant skeleton feedback
When not prefetched: Still responsive, skeleton appears quickly (<300ms)

My personal favorite for real-world applications.

Strategy 5 & 6: Quicklink Library

📺 View Transitions Demo | 📺 Loading UI Demo | 💻 Code

Quicklink is a library that prefetches links when they enter the viewport. I tested it as a cross-browser alternative to Speculation Rules.

Results (Quicklink + View Transitions):

Average Transition Time: 1,627ms
Average TTFB: 33.4ms

Results (Quicklink + Loading UI):

Average Transition Time: 811ms
Average Skeleton Load: 320ms
Average TTFB: 37.4ms

Verdict: While Quicklink has better browser support, it didn't match Speculation Rules' performance in my tests.
The loading UI variant performed better than view transitions, but still showed higher skeleton load times.

Possible reasons:

Configuration may need optimization
Viewport-based prefetching vs. browser-native speculation
Additional JavaScript bundle overhead

🎬 Conclusion & Recommendations

After extensive testing with real-world metrics, here's what I learned about page navigation in Next.js:

My Recommendation Hierarchy

🥇 Speculation Rules + Loading UI - For Chrome/Edge users with Next.js, this is the winner. You get dramatic performance improvements with native browser support and clear user feedback through skeleton screens. This is my personal favorite for production applications.
🥈 Next.js SPA Navigation - Perfect for simple, controlled flows like thank you pages, wizards, or internal tools. Provides instant transitions and the smoothest experience, but watch out for memory leaks in complex apps and avoid if you're using external scripts or tracking pixels.
🥉 Speculation Rules + View Transitions - Deliver a smooth, polished, app-like experience with elegant animations. If you’re not using Next.js, this is probably the best option.
Standard HTML Navigation - Your fallback for maximum compatibility and when dealing with complex third-party integrations. Sometimes the traditional approach is the most reliable.

The web platform is evolving rapidly, and if your analytics show significant Chrome/Edge usage, these modern navigation strategies can transform your user experience with surprisingly little code.

🔗 Try It Yourself

Live Demo: https://view-transition-comparison.vercel.app/
Source Code: https://github.com/ale-grosselle/view-transition-comparison

I encourage you to test each strategy with your own use cases. Use Chrome DevTools' network throttling (Fast 4G) and CPU slowdown (4x) to see the differences clearly.

What's your preferred navigation strategy? Have you experimented with Speculation Rules or View Transitions? Share your experiences in the comments!

📚 Further Reading

Testing environment: Fast 4G network, 4x CPU throttling, Chrome DevTools, cache enabled. All measurements represent averages of 5 runs per strategy.

Step-by-Step Guide to Capture Heap Snapshots in Node.js on Kubernetes

Alessandro Grosselle — Tue, 21 Oct 2025 19:59:16 +0000

Memory leaks are a common issue in Node.js applications, especially when running inside containerized environments like Kubernetes.

A memory leak occurs when an application keeps allocating memory without releasing it, leading to increased memory usage and eventually to container restarts or crashes.

Here’s a typical graph of what a memory leak looks like: memory usage constantly increasing over time until the pod is restarted.

Common causes of memory leaks in Node.js

Unclosed Redis or database connections
Global variables accumulating data
Event listeners that are never removed

In short: memory leaks happen more often than you think, especially in complex services.

And the tricky part? You won’t always see them in your local environment, since production traffic and timeouts behave differently.

In our case, for example, the leak was caused by too many requests to an external API with a very long default timeout, resulting in pending requests piling up in memory.

Pro tip: Always define your own timeout! Never rely on external providers’ default timeouts.

Step-by-Step Guide to Access Heap Snapshots in Node.js on Kubernetes

Let’s go through a practical process to capture and inspect memory data from a Node.js application running inside a Kubernetes pod.

Connect to the Kubernetes Pod

First, find the pod you want to debug:

kubectl get pods | grep <your-app-name>

Then check which process ID is running Node.js (our case, it’s 1):

kubectl exec <your-app-name-64dcf6b84d-nx5cl> -- ps aux

Now, send the SIGUSR1 signal to that process:

kubectl exec <your-app-name-64dcf6b84d-nx5cl> -- kill -SIGUSR1 1

In Node.js, the SIGUSR1 signal has an official purpose: it enables the Node.js inspector for debugging a running process.
Next, forward the debugging port from the pod to your local machine:

kubectl port-forward <your-app-name-64dcf6b84d-nx5cl> 9229:9229

Connect the Chrome DevTools Debugger

Open Chrome and navigate to:

chrome://inspect

Then click “Open dedicated DevTools for Node”.

In the Connections panel, click Add connection and enter:

localhost:9229

Now you’re connected to your Node.js process running inside the Kubernetes pod. You should even see your application logs appearing in the DevTools console.

Take and Compare Heap Snapshots

Go to the “Memory” tab in DevTools and click “Take Heap Snapshot”.

Wait for the snapshot to generate; this shows all memory allocations in your app. If a leak exists, you’ll notice that memory usage keeps growing between snapshots.
To confirm, take a second snapshot after some time (say 10 minutes) and switch to the “Comparison” view. Select the first snapshot as the baseline.

This will show which objects were allocated between the two snapshots, and whether any aren’t being released.

Sometimes, your pod might restart before the debugger finishes sending data over the WebSocket, preventing you from downloading the snapshot.
That’s exactly what happened to me when I clicked "Take snapshot":

Here’s a simple trick: expose a custom endpoint in your app to create and save a heap snapshot programmatically.
This example shows an Express.js endpoint:

// Heap snapshot endpoint for memory profiling
  server.get('/heap-snapshot', async (req: Request, res: Response) => {
    try {
      const timestamp = new Date().toISOString().replace(/[:.]/g, '-');
      const filename = `/tmp/heap-snapshot-${timestamp}.heapsnapshot`;
      const session = new Session();

      const fd = fs.openSync(filename, 'w');

      session.connect();

      session.on('HeapProfiler.addHeapSnapshotChunk', (m) => {
        fs.writeSync(fd, m.params.chunk);
      });

      const result = await session.post('HeapProfiler.takeHeapSnapshot');

      session.disconnect();
      fs.closeSync(fd);

      logger.logInfo(
        `Heap snapshot created: ${filename}`,
        req.headers[LABEL_REQUESTID.toLowerCase()] as string
      );

      res.json({
        success: true,
        filename,
        message: 'Heap snapshot created successfully',
        result,
      });
    } catch (error) {
      const errorMessage = getErrorMessage(error) ?? 'Unknown error occurred';
      logger.logError(
        `Failed to create heap snapshot: ${errorMessage}`,
        req.headers[LABEL_REQUESTID.toLowerCase()] as string
      );

      res.status(HTTPStatusCode.InternalServerError).json({
        success: false,
        error: 'Failed to create heap snapshot',
        message: errorMessage,
      });
    }
  });

Generate the snapshot, calling the endpoint:

kubectl exec -it <your-app-name-64dcf6b84d-nx5cl> wget http://localhost:<your-app-port>/heap-snapshot

Then, copy the snapshot from the pod to your local machine:

kubectl cp <your-app-name-64dcf6b84d-nx5cl>:/tmp/heap-snapshot-2025-10-19T15-19-34-391Z.heapsnapshot ./heap-snapshot.heapsnapshot

You can open this .heapsnapshot file in Chrome DevTools later and analyze it offline, clicking "Loading profile":

Conclusion

And that’s it! This workflow gives you a practical and reproducible method to detect memory leaks in Node.js applications running on Kubernetes.

It’s saved me a lot of time, hopefully, it’ll help you too.

Thanks for reading!

The CSS Ordering Quiz That Will Break Your Next.js Assumptions

Alessandro Grosselle — Tue, 30 Sep 2025 13:30:12 +0000

Can you predict how Next.js handles CSS import order? This interactive quiz reveals a hidden behavior that might surprise you.

🚀 For the Impatient

Want to see the magic immediately? Here are all the links:

📂 Repository: https://github.com/ale-grosselle/css-order-next.js

🧪 Live Test Cases:

Case A - Basic CSS ordering
Case B - Server component CSS
Case C - Client component follows rules
Case D - The mind-bender! 🤯

🕵️‍♂️ Pro Tip: Open your browser's DevTools (F12 or right-click → Inspect) and check the Elements panel to see the actual CSS order loaded for each case. This is crucial for understanding how Next.js handles CSS imports!

We all know the golden rule from the Next.js documentation: "CSS import order matters". It's a fundamental principle we've relied on for years. But how well do you really understand CSS ordering in Next.js?

Let's put your knowledge to the test with a hands-on quiz that reveals some surprising behavior you probably didn't know about.

The Setup: Our CSS Ordering Laboratory

I've created a simple Next.js project to test CSS import behavior. Here's what we're working with:

Base Configuration

Layout Component (layout.tsx)

import "./globals.css";

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return <div>{children}</div>;
}

Global Styles (globals.css)

div.foo {
    --layout-file: red;
    background-color: var(--layout-file);
}

This sets all .foo divs to red by default.

Our Test Stylesheets

We have several CSS files that all target the same element with different colors:

1.global.css - Makes divs yellow:

div.foo {
    --1-global-page-css: yellow;
    background-color: var(--1-global-page-css);
}

0.module.css - CSS Module for brown divs:

div.body-module {
    --0--page--css--module: brown;
    background-color: var(--0--page--css--module);
}

Server Component CSS (components/2.css):

div.foo {
    --2-rsc-component: orange;
    background-color: var(--2-rsc-component);
}

Client Component CSS (components/3.css):

div.foo {
    --3-client-component: black;
    background-color: var(--3-client-component);
}

Now, let's see how well you can predict CSS ordering behavior!

🧩 Quiz Time: Can You Guess the Color?

Case A: The Baseline Test

🌐 Try Case A Live

// case-a/page.tsx
import "../1.global.css";
import style from "../0.module.css";

export default function HomePage() {
  return (
    <div className={`${style["body-module"]} foo`}>HELLO</div>
  );
}

🤔 Your Prediction: What background color will the div have?

A) Red (from globals.css)
B) Yellow (from 1.global.css)
C) Brown (from 0.module.css)

✅ Correct Answer: C) Brown

Why: Layout CSS (globals.css) is loaded first in a separate bundle. Within the page bundle, 0.module.css is imported LAST, so at equal specificity it wins over both globals.css and 1.global.css.

Case B: Adding a Server Component

🌐 Try Case B Live

// case-b/page.tsx
import "../1.global.css";
import style from "../0.module.css";
import { Example } from "@/components/Example"; // Server component with CSS

export default function HomePage() {
  return (
    <>
      <div className={`${style["body-module"]} foo`}>HELLO</div>
      <Example />
    </>
  );
}

The Example component imports ./2.css which makes .foo divs orange.

🤔 Your Prediction: What color will the div be now?

A) Red (from globals.css)
B) Brown (from 0.module.css)
C) Orange (from server component 2.css)

✅ Correct Answer: C) Orange

Why: Server component CSS follows import order. The Example component is imported LAST, so its CSS comes after everything else and wins.

Case C: Still Following the Rules

🌐 Try Case C Live

// case-c/page.tsx
import { Example } from "@/components/Example";
import "../1.global.css";
import style from "../0.module.css";
import { ExampleClientComponent } from "@/components/Example-client-component"; // Client component!

export default function HomePage() {
  return (
    <>
      <div className={`${style["body-module"]} foo`}>HELLO</div>
      <ExampleClientComponent />
      <Example />
    </>
  );
}

Now we have:

Example (server component with orange CSS) imported FIRST
1.global.css (yellow) imported SECOND
0.module.css (brown) imported THIRD
ExampleClientComponent (client component with black CSS) imported LAST

🤔 Your Prediction: Based on import order, what color should win?

A) Orange (server component imported first)
B) Brown (from 0.module.css imported third)
C) Black (client component imported last)

✅ Expected Answer: C) Black

Why: Following the "last import wins" rule, since ExampleClientComponent is imported last, its CSS should come last and win.

📊 Expected CSS Loading Order:

Layout Bundle: globals.css (red)
Page Bundle: components/2.css (orange) → 1.global.css (yellow) → 0.module.css (brown) → components/3.css (black) ← Should win

And indeed, the div IS black! The rule still holds...

Case D: The Mind-Bender That Breaks Everything

🌐 Try Case D Live

Let's try one more test to confirm our suspicions:

// case-d/page.tsx
import { ExampleClientComponent } from "@/components/Example-client-component"; // FIRST
import { Example } from "@/components/Example";
import "../1.global.css"; // THIRD
import style from "../0.module.css"; // LAST CSS import

export default function HomePage() {
  return (
    <>
      <div className={`${style["body-module"]} foo`}>HELLO</div>
      <ExampleClientComponent />
      <Example />
    </>
  );
}

Now the client component is imported FIRST, and 0.module.css is imported LAST.

🤔 Final Prediction: Based on the "last import wins" rule, what color should the div be?

A) Black (client component imported first)
B) Brown (from 0.module.css imported last)
C) Orange (from server component)

🤯 Answer: Still Black!

The Hidden Truth Revealed: Even though 0.module.css is imported LAST and should win according to the fundamental CSS ordering rule, the client component's CSS still wins!

📊 Expected CSS Loading Order:

Layout Bundle: globals.css (red)
Page Bundle: components/3.css (black - imported first) → components/2.css (orange) → 1.global.css (yellow) → 0.module.css (brown) ← Should win!

📊 Actual CSS Loading Order:

Layout Bundle: globals.css (red)
Page Bundle: components/2.css (orange) → 1.global.css (yellow) → 0.module.css (brown)
Client Bundle: components/3.css (black) ← Always wins!

This completely breaks the "last import wins" rule! Client component CSS gets moved to the end regardless of where you import it.

🔍 The Discovery: Next.js Has a unclear CSS Rule

What I learned:

✅ Layout CSS is always loaded first (separate bundle)
✅ Server component CSS follows import order within the page
❌ Client component CSS always loads after server component CSS, regardless of import order.
✅ Among client components, import order between multiple client components is still respected

🚨 MUST-Follow Rules to Avoid CSS Chaos

After discovering this hidden behavior, the Next.js CSS recommendations become absolute requirements, not just suggestions:

1. Use CSS Modules for ALL Component-Specific Styles

// ✅ DO: Always use CSS Modules for components
import styles from "./MyComponent.module.css";

// ❌ DON'T: Never use global CSS in components
import "./MyComponent.css"; // This creates ordering conflicts!

Why this is critical: CSS Modules provide scoping that prevents the CSS ordering conflicts we discovered. Your styles won't accidentally override or be overridden by other components.

2. Import CSS Only Once Per Component

// ✅ DO: One CSS import per component
import styles from "./Button.module.css";

export const Button = () => <button className={styles.button}>Click me</button>;

// ❌ DON'T: Multiple CSS imports in one component
import "./theme.css";
import "./button.css";
import "./overrides.css"; // Unpredictable ordering!

Why this matters: Multiple CSS imports create dependency chains that behave differently for server vs client components.

3. Define Global CSS ONLY in Layout

// ✅ DO: Only in layout.tsx
import "./globals.css";
import "./tailwind.css"; // If using Tailwind

// ❌ DON'T: Global CSS anywhere else
// pages/home.tsx - NEVER do this!
import "../globals.css"; // This breaks predictability

Why this is essential: Global CSS should be loaded once and consistently. Importing it multiple places creates the exact ordering conflicts we discovered.

Did this quiz surprise you? Have you encountered similar CSS ordering mysteries in your Next.js projects? Share your experiences in the comments!