Server vs Client Components in Next.js: Where Interactive Effects Belong

Animation does not make a component a Client Component.

In the Next.js App Router, layouts and pages are Server Components by default. Keep page composition, server-side data work and markup on the server where appropriate. Use a Client Component when an interaction needs React state, event handlers, Effects or browser APIs. CSS-only animation does not require client-side React, and "use client" does not automatically disable server prerendering. Next.js documents the Server and Client Component model here.

That distinction becomes important as soon as a site moves beyond counters and form fields. A hover transition, scroll reveal, custom cursor and WebGL hero may all move on screen, but they ask very different things from React and the browser. Treating them all as “animation” and putting "use client" at the top of the page widens the client boundary before you have established a reason to do it.

The useful question is “What has to execute in the browser?”

An animation does not automatically need a Client Component

A Server Component can render markup that the browser later animates with CSS. There is no contradiction there.

Consider a CTA whose arrow shifts on hover. React does not need to track the hover state, calculate a timeline or subscribe to an input source. The server renders the anchor. CSS handles the visual response in the browser.

1// components/cta.tsx2// No "use client"3 4import styles from "./cta.module.css";5 6export function CTA() {7  return (8    <a className={styles.cta} href="/work">9      View the work10      <span aria-hidden="true">→</span>11    </a>12  );13}

1/* components/cta.module.css */2 3.cta span {4  display: inline-block;5  transition: transform 180ms ease;6}7 8.cta:hover span,9.cta:focus-visible span {10  transform: translateX(0.25rem);11}12 13@media (prefers-reduced-motion: reduce) {14  .cta span {15    transition: none;16  }17}

The browser animates server-rendered markup. No client-side React runtime is needed for that transition.

The boundary changes when the implementation actually needs browser-side JavaScript. A cursor effect needs pointer input. A scroll reveal may need IntersectionObserver. A draggable object needs state and events. A timeline may need to initialize an animation engine after mount. A canvas or WebGL scene has browser rendering resources to create and dispose of.

Next.js describes Client Components in those terms: state, event handlers, lifecycle logic, browser-only APIs and custom hooks. Visual movement itself is not the criterion. See the official Server and Client Components guide.

The word usually matters. A text reveal, GSAP timeline and WebGL scene should not inherit the same architecture simply because all three animate. Inspect what the implementation actually imports, measures, subscribes to and renders.

For the separate question of which rendering layer an effect should use, see DOM vs Canvas vs WebGL. This article has a narrower job: once you know what you are building, where should its runtime live in Next.js?

What "use client" actually changes

Think boundary, not “make this page client-rendered.”

The "use client" directive establishes an entry point into the client module graph. Modules imported beneath that entry point become part of the client-side graph, which is why placing the directive high in the tree can bring unrelated code along for the ride. Next.js recommends applying it to specific interactive components rather than broad portions of the UI. The framework documentation covers that boundary explicitly.

1page.tsx                    Server2├─ HeroCopy                 Server3├─ ProductDetails           Server4├─ CTA                      Server5└─ CursorEffect             Client6   ├─ pointer listener7   ├─ animation runtime8   └─ cleanup

If only CursorEffect needs pointer coordinates, making page.tsx a Client Component unnecessarily widens the client boundary.

There is an important composition nuance here. A Client Component can import other client-side modules, but that does not mean every piece of UI visually nested inside it must originate in the client graph. Next.js supports rendering Server Components and passing their rendered result into a Client Component through children or another prop. Props crossing the Server-to-Client boundary must be serializable.

That gives you useful structures such as:

1ProductPage                 Server2└─ InteractiveShell         Client3   ├─ ProductCopy           Server output passed as children4   └─ browser-side controls

The distinction matters on creative pages because decorative behavior and meaningful content do not need to share an execution model. Your canvas may need the browser. Your product heading does not suddenly need requestAnimationFrame.

Client Component does not mean client-only rendering

Adding "use client" does not normally mean “skip the server and render this exclusively in the browser.”

On an initial load, Next.js can prerender HTML for both Server and Client Components. The browser receives the initial interface, then React uses the RSC payload and client JavaScript to reconcile and hydrate the Client Components. On subsequent client-side navigations, the framework can use prefetched and cached RSC payloads rather than repeating the exact initial-load sequence. Next.js documents both rendering paths.

Conceptually, for the initial load:

1Server render2    ↓3HTML + RSC payload4    ↓5Browser displays initial UI6    ↓7Client JavaScript loads8    ↓9Hydration10    ↓11Listeners / observers / animation runtime start

That distinction explains why this can still fail inside a Client Component:

1"use client";2 3export function Hero() {4  const width = window.innerWidth;5 6  return <div>{width}</div>;7}

The directive permits client capabilities. It does not create a window object while server prerendering is happening, and rendering different initial content between server and browser can create a hydration mismatch.

Browser-dependent setup often belongs in an Effect instead:

1"use client";2 3import { useEffect } from "react";4 5export function PointerTracker() {6  useEffect(() => {7    function handlePointerMove(event: PointerEvent) {8      console.debug(event.clientX, event.clientY);9    }10 11    window.addEventListener("pointermove", handlePointerMove);12 13    return () => {14      window.removeEventListener("pointermove", handlePointerMove);15    };16  }, []);17 18  return null;19}

React Effects run on the client rather than during server rendering. In development, Strict Mode can also perform an additional setup-and-cleanup cycle to expose incomplete cleanup logic. That is particularly useful for animation timelines, observers, subscriptions and render loops: if setup cannot survive setup → cleanup → setup, its lifecycle probably is not owned cleanly enough yet. See React’s useEffect reference.

For visual work that genuinely has to measure or change layout before React paints an updated client render, useLayoutEffect can occasionally be appropriate. It blocks paint and can trigger extra synchronous work, so it should be reserved for timing-sensitive cases rather than becoming the default animation hook.

A scroll reveal makes the boundary easy to see

Suppose a marketing page contains an editorial section that should reveal as it enters the viewport. The heading and copy are meaningful page content. They do not need client-side data fetching or state. Only visibility observation belongs in the browser.

The production constraint is progressive enhancement: the content must remain visible if JavaScript never runs, hydration fails, reduced motion is enabled or IntersectionObserver is unavailable.

Keep the page on the server:

1// app/page.tsx2 3import { Reveal } from "@/components/reveal";4 5export default function Page() {6  return (7    <main>8      <section className="intro">9        <p>Interaction should clarify the page, not compete with it.</p>10      </section>11 12      <Reveal>13        <section className="feature">14          <p className="eyebrow">Interaction architecture</p>15          <h2>Keep the content. Isolate the runtime.</h2>16          <p>17            This copy is server-rendered. The client component only owns the18            enhancement that observes when it enters the viewport.19          </p>20        </section>21      </Reveal>22    </main>23  );24}

The Client Component starts from a readable state. It only conceals content after confirming three things: reduced motion is not requested, IntersectionObserver exists, and the element is currently below the viewport.

1// components/reveal.tsx2 3"use client";4 5import {6  type ReactNode,7  useLayoutEffect,8  useRef,9} from "react";10 11import styles from "./reveal.module.css";12 13type RevealProps = {14  children: ReactNode;15};16 17export function Reveal({ children }: RevealProps) {18  const rootRef = useRef<HTMLDivElement>(null);19 20  useLayoutEffect(() => {21    const root = rootRef.current;22 23    if (!root) return;24 25    const reducedMotion = window.matchMedia(26      "(prefers-reduced-motion: reduce)"27    );28 29    if (30      reducedMotion.matches ||31      !("IntersectionObserver" in window)32    ) {33      return;34    }35 36    const rect = root.getBoundingClientRect();37 38    // If the content is already visible when hydration reaches it,39    // leave it visible. Do not make it disappear just to replay a reveal.40    if (rect.top < window.innerHeight) {41      return;42    }43 44    // A viable reveal path exists and the element is still below fold.45    root.dataset.enhanced = "true";46    root.dataset.visible = "false";47 48    const observer = new IntersectionObserver(49      ([entry]) => {50        if (!entry.isIntersecting) return;51 52        root.dataset.visible = "true";53        observer.disconnect();54      },55      {56        threshold: 0,57      }58    );59 60    observer.observe(root);61 62    return () => {63      observer.disconnect();64    };65  }, []);66 67  return (68    <div ref={rootRef} className={styles.reveal}>69      {children}70    </div>71  );72}

The stylesheet sits beside the component and is imported as a CSS Module:

1/* components/reveal.module.css */2 3/* Progressive-enhancement default: readable without JavaScript. */4.reveal {5  opacity: 1;6  transform: none;7}8 9/* Conceal only after the client has established a viable reveal path. */10.reveal[data-enhanced="true"][data-visible="false"] {11  opacity: 0;12  transform: translateY(1.5rem);13}14 15.reveal[data-enhanced="true"] {16  transition:17    opacity 500ms ease,18    transform 500ms ease;19}20 21.reveal[data-enhanced="true"][data-visible="true"] {22  opacity: 1;23  transform: translateY(0);24}25 26@media (prefers-reduced-motion: reduce) {27  .reveal,28  .reveal[data-enhanced="true"],29  .reveal[data-enhanced="true"][data-visible="false"] {30    opacity: 1;31    transform: none;32    transition: none;33  }34}

There are a few deliberate choices here.

First, the server-rendered state is visible. If JavaScript never arrives, there is nothing to rescue.

Second, an element already inside the viewport remains visible when hydration reaches it. Delayed hydration should not make meaningful content disappear so the site can perform an entrance animation after the reader has already seen it.

Third, the observer uses threshold: 0. A tall section does not need to squeeze 20% of itself into a short viewport before it can reveal. Any genuine intersection is enough for this effect.

Fourth, the component does not synchronously call React state setters inside useLayoutEffect. The reveal state is purely an imperative enhancement on the wrapper’s data attributes, which avoids an unnecessary React render cycle for presentation state that no other component consumes.

useLayoutEffect still has a cost. Its role here is narrowly defined: for below-the-fold content where enhancement is available, establish the pre-reveal presentation before React paints that updated client commit. It does not guarantee that server HTML was never painted earlier, and it should not become a default hook for animation. The unenhanced state remains readable when the client runtime is unavailable.

Where common interactive effects should cross the boundary

Once the pattern is clear, other effect classes become easier to place.

CSS and static SVG

Keep the React component on the server when CSS or static SVG can express the full behavior without React state or browser-side lifecycle logic.

Good candidates include hover feedback, focus transitions, basic keyframes and small decorative movement. If the visual task is simple, a JavaScript animation runtime can be more architecture than the interaction deserves.

For the related tool-choice question, see When CSS Animation Is Enough.

Scroll and layout-measured effects

Move the portion that observes scroll, intersection, resize or geometry into a Client Component.

That could mean IntersectionObserver, ResizeObserver, getBoundingClientRect(), a scrolling library or an animation engine. Keep surrounding article copy, product data and semantic structure on the server when those pieces have no reason to enter the client module graph.

Pointer and cursor systems

Pointer-following effects naturally require a client boundary. They also need an input strategy.

A custom cursor should not be the only way a control communicates state, and a mouse-centric interaction may deserve to disappear entirely on coarse-pointer devices rather than receiving a forced mobile imitation.

1.cursorEffect {2  display: none;3}4 5@media (hover: hover) and (pointer: fine) {6  .cursorEffect {7    display: block;8  }9}

If the implementation subscribes to pointer events, apply the capability check to the JavaScript setup too. Hiding an effect with CSS while its listener continues processing pointer work is decorative theatre for the profiler.

Canvas and WebGL scenes

Canvas and WebGL effects commonly need browser-side execution because their meaningful rendering work depends on browser graphics APIs. Three.js and React Three Fiber scenes may also bring textures, shaders, continuous render loops and GPU resources that deserve a clearer loading strategy than a small hover transition.

The exact answer remains dependency-specific. A scene that can prerender a stable shell and initialize graphics later is different from a dependency that touches window, Canvas or WebGL during module evaluation.

Keep meaningful content outside decorative graphics where practical. A headline should remain a headline, not become a texture because the hero needed drama.

"use client" vs dynamic() vs { ssr: false }

These are three separate decisions.

"use client" establishes a Client Component boundary.

next/dynamic can defer Client Components or imported libraries.

dynamic(..., { ssr: false }) disables prerendering for that Client Component.

The current Next.js lazy-loading guide states that ssr: false works for Client Components and is not supported when configured from a Server Component.

It also documents a caveat worth keeping in view: when a Server Component dynamically imports a Client Component, automatic code splitting for that Client Component is currently not supported. In other words, the presence of dynamic() alone is not evidence that the resulting bundle boundary behaves exactly as you intended. Verify the actual loading path.

A browser-only wrapper can live in client code:

1// components/visual-client.tsx2 3"use client";4 5import dynamic from "next/dynamic";6 7const HeavyVisual = dynamic(8  () => import("./heavy-visual"),9  {10    ssr: false,11    loading: () => (12      <div13        className="visual-placeholder"14        aria-hidden="true"15      />16    ),17  }18);19 20export function VisualClient() {21  return <HeavyVisual />;22}

The server page can remain a Server Component:

1// app/page.tsx2 3import { VisualClient } from "@/components/visual-client";4 5export default function Page() {6  return (7    <main>8      <section className="hero">9        <div>10          <h1>Server-rendered headline</h1>11          <p>12            Meaningful content stays outside the browser-only visual runtime.13          </p>14        </div>15 16        <VisualClient />17      </section>18    </main>19  );20}

If the visual occupies real space, reserve that space in the fallback. Otherwise the delayed runtime may arrive with a side order of layout shift.

Dynamic loading defers the JavaScript bill. It does not cancel it.

A WebGL scene still has code to download and execute, assets to load and rendering work to perform once it appears. Lazy loading changes when that cost arrives; it does not remove it.

Use browser-only loading because the implementation genuinely cannot or should not prerender-not because adding { ssr: false } happens to make a hydration warning disappear.

How interactive effects create hydration problems

Hydration failures are broader than animation. Invalid HTML nesting, time-dependent output and other differences between server and client rendering can cause them too. Creative frontend code simply has a recognizable subset of failure modes: browser globals during render, geometry-dependent JSX, random initial values and third-party modules that assume a browser before hydration. Next.js maintains a hydration-error reference covering the broader class of causes.

A common mistake looks like this:

1"use client";2 3export function HeroLabel() {4  return (5    <span>6      {window.innerWidth < 768 ? "Tap" : "Hover"} to explore7    </span>8  );9}

There are two problems. window is unavailable during server rendering, and viewport state is being allowed to determine the initial JSX.

A safer implementation keeps the first render stable and adds browser capability afterward:

1"use client";2 3import { useEffect, useState } from "react";4 5export function HeroLabel() {6  const [instruction, setInstruction] = useState("Explore");7 8  useEffect(() => {9    const isCoarsePointer = window.matchMedia(10      "(pointer: coarse)"11    ).matches;12 13    setInstruction(14      isCoarsePointer15        ? "Tap to explore"16        : "Hover to explore"17    );18  }, []);19 20  return <span>{instruction}</span>;21}

Whether that post-hydration copy change is desirable is another question. Often, neutral text such as “Explore” is better because it avoids layout movement and does not make input method part of the message at all.

The larger point is architectural: browser capability should not casually redefine server output.

suppressHydrationWarning is an escape hatch for understood, unavoidable mismatches. It is not an animation architecture.

Production rules for client-side effects

The client boundary is only the first decision. Once an effect owns browser resources, the component needs to own their lifecycle too.

If it registers a listener, observer, timeline or render loop, it should also know how to tear that resource down.

Verify cleanup, not just setup

In development, React Strict Mode can expose incomplete Effect cleanup by running an additional setup-and-cleanup cycle. Do not “fix” duplicate animation initialization with a global guard before checking whether teardown is symmetrical. See React’s useEffect documentation.

For an observer:

1useEffect(() => {2  const node = rootRef.current;3 4  if (!node) return;5 6  const observer = new ResizeObserver(() => {7    // Recalculate effect geometry.8  });9 10  observer.observe(node);11 12  return () => {13    observer.disconnect();14  };15}, []);

For a requestAnimationFrame loop, retain the frame ID and cancel it. For GSAP, Motion, Three.js or another runtime, use that library’s actual cleanup and disposal model rather than inventing a generic destroy() method that may not exist.

Treat mobile as a different interaction environment

A custom cursor may have no useful mobile equivalent. Hover choreography may need to disappear. A pinned scroll sequence may require different spacing or a simpler composition on a small screen.

Viewport width alone is not input capability. Use pointer and hover media features when they describe the actual design decision.

Reduced motion is a behavior path

prefers-reduced-motion is not the whole accessibility story, but substantial movement should have a deliberate response to it.

That may mean removing travel while keeping an opacity change, displaying the final state immediately, disabling a decorative cursor trail, stopping an ambient loop or replacing a camera move with a static composition.

The fallback should preserve meaning. It does not need to preserve the trick.

Keep semantic UI outside decorative runtimes

• If the canvas fails, the headline should still be a headline.
• If WebGL never initializes, navigation should still navigate.
• If reduced motion removes a reveal, the content should remain readable.

Creative effects are strongest when they enrich the interface without becoming a ransom note for the interface underneath.

Test the production path

Before shipping:

1. Run a production build and resolve server/client errors.
2. Load the route directly and check for hydration warnings.
3. Test the reveal with short and tall elements, short viewports and content initially below the fold.
4. Navigate away and back; confirm listeners, observers, timelines and loops are not accumulating.
5. Test fine-pointer and touch/coarse-pointer behavior.
6. Enable reduced motion and confirm the intended fallback.
7. Disable JavaScript for progressively enhanced content and confirm meaningful content remains available.
8. Test an environment without the optional observer path if that fallback matters to your browser support policy.
9. Watch layout stability while dynamically loaded visuals arrive.
10. Profile before making performance claims: inspect client JavaScript, repeated renders, long tasks, continuous rendering, assets and effect-specific GPU work.

A narrow client boundary is good architecture. It is not a benchmark.

Quick decision checklist

Before adding "use client" to an animated section, answer seven questions:

1. Can HTML and CSS do the job?
   If yes, React may not need a client boundary at all.
   
2. What browser capability is required?
   State, events, Effects, pointer input, observers, measurement, Canvas or WebGL should be explicit-not assumed.
   
3. How narrow can the useful boundary be?
   Keep unrelated content, data work and server-only dependencies outside it.
   
4. Can the Client Component prerender safely?
   "use client" is not the same as ssr: false.
   
5. If prerendering fails, why?
   Fix an architecture mistake before choosing browser-only loading; use { ssr: false } when the implementation genuinely requires it.
   
6. What changes for touch, no-JS and reduced motion?
   Define the fallback before the effect reaches QA.
   
7. What gets cleaned up?
   List the listeners, observers, timelines, frames and rendering resources the component owns.

The architecture usually stops looking mysterious once those answers are concrete.

Render what belongs on the server. Cross the boundary where interaction begins. Keep the runtime coherent enough to own its setup and teardown. Disable server rendering only when the implementation actually requires it. Then make the motion earn the JavaScript.

Explore React and Next.js effects you can inspect and adapt.