# Next.js Server vs Client Components: 2026 Developer Tips In 2026 the Next.js App Router still defaults layouts and pages to **Server Components**. That is not a slogan. It means you fetch close to the database, keep keys off the client, and ship less JavaScript. The teams that struggle are the ones who paste `'use client'` at the top of every file “just in case.” I am Vishvajeet Shukla. I ship production Next.js sites. These are the habits I wish juniors learned before they “optimise” a brochure site into a 400 kb client tree. If you are choosing a CMS rather than writing components, start with [Next.js vs WordPress](https://www.vishvajeetshukla.in/blog/nextjs-vs-wordpress-local-business). *Related:* [Core Web Vitals](https://www.vishvajeetshukla.in/blog/core-web-vitals-guide-for-small-business-websites) · [mobile-first checklist](https://www.vishvajeetshukla.in/blog/mobile-first-website-checklist-india-sme-2026). ## The 2026 default, in one sentence Official Next.js docs (updated August 2026) still say: use Client Components when you need interactivity or browser APIs; use Server Components to fetch, to hide secrets, to cut JS, and to improve First Contentful Paint with streaming. That split is the golden rule this year. Vercel-facing write-ups keep repeating 30–40% smaller bundles when people actually follow it. ## Tip 1: Server is the default. Mark client last If a file only maps props to JSX, it is a Server Component. You do not need hooks to render a card. You need `'use client'` for `useState`, `useEffect`, click handlers, and `window`. Push that leaf down. Keep the page and the data fetch above it. A whole tree marked client throws away the App Router. I still open codebases where `layout.tsx` is client because someone put a theme toggle in it. Extract the toggle. Leave the layout on the server. ## Tip 2: Fetch in the Server Component, not in useEffect The old pattern — mount, spinner, fetch — is how you leak waterfalls and empty first paint. In the App Router an async Server Component can await the database and stream HTML. Secrets stay on the server. The official getting-started page is explicit: fetch near the source, do not expose tokens. If a child needs interactivity, pass serialisable props down. Do not fetch the same list again in the client “for freshness” unless you have a real live requirement. ## Tip 3: Know which cache you are fighting Next.js has more than one cache: request memoisation, the data cache, the full route cache, the router cache. When a page “won’t update,” read which layer you set. `unstable_cache` plus ISR is how this site’s blog used to look stale until we busted a tag. Same class of bug as “I published and nothing changed.” In local dev, Server Component edits re-fetch. For large apps the experimental `serverComponentsHmrCache` can cache those fetches across HMR so you do not burn a paid API on every save. That is a 2026 local-dev tip from the official local-development guide, not a Twitter myth. ## Tip 4: Stream the slow part Wrap the product grid in `Suspense` with a `loading.js` sibling. The hero can paint while the catalogue waits. Users on Jio 4G feel that more than they feel your folder structure. Pair it with real image work from the [slow website guide](https://www.vishvajeetshukla.in/blog/how-to-fix-slow-website-speed-guide-2026). ## Tip 5: Do not fetch in a Client Component just to use a hook Need a like button? Server Component fetches the count. Client Component is a 20-line button that posts to a Route Handler. That is composition, not a rewrite. ## A review checklist before you merge * How many files have `'use client'`? If it is most of `app/`, stop. * Are env secrets only imported from server files? * Does the first HTML include the main heading without waiting for JS? * Did you add a loading UI for the slow query? > If the page works with JavaScript disabled for the main content, you probably used Server Components correctly. ## How I split a real marketing page Hero with a heading and a primary button: server. The button that opens a drawer: a tiny client child. The blog list: server fetch from Firestore. The search box: client. The footer: server. That is an entire SME homepage with two client files. I have seen the same homepage as one 800-line client component importing framer-motion, a map, and a form library “for later.” Later never comes. The JS always does. When you add a third-party chat or analytics snippet, load it after idle. Do not wrap the whole layout in a provider that is a client component unless you must. Providers are how a single theme hook infects the tree. Read the import graph once a month. If `page.tsx` imports a file that imports a file that says `'use client'`, you just bought that graph for the route. For data that changes per request (a draft preview, a personalised dashboard), opt out of caching on purpose and write it down in the PR. Silent `no-store` everywhere is how you pay for a serverless function on every asset request. Silent force-cache is how clients call you because yesterday’s price is still on the page. Choose, then document. ## What this is not This is not “never use client.” Forms, maps, drawers, and three.js scenes belong on the client. It is “do not pay the client tax for a paragraph.” For SME marketing sites that tax shows up as a bad LCP and a bounce. For dashboards it shows up as a 3G laptop fanspin. ## A migration note if you are stuck on Pages Router Do not port a file a day without a map. List routes that need SEO HTML first — home, services, blog — and move those to `app/`. Leave a messy dashboard on Pages Router for a sprint if you must. Mixing forever is how two data-fetch styles live in one head. Official stance in 2026 is still: new work belongs in App Router. When you move a page, delete the client fetch that duplicated the server query. I have migrated sites that called the same API twice, once in getServerSideProps and once in useEffect, “because it flickered.” It flickered because the client refetch raced. One server await fixes it. ## FAQ ### Should every new Next.js app use the App Router in 2026? Yes for new work. Pages Router is maintenance. Official examples and docs assume `app/`. ### Can I mix App Router and Pages Router? You can. You will confuse yourself. Don’t, unless you are migrating. ### Do Server Components replace an API route? They replace a lot of “GET for this page” routes. You still want Route Handlers for webhooks, webhooks, and browser mutations. ### Why is my client bundle still huge? A client parent pulls every import with it. Move the heavy chart into its own client file. Keep the page server. ### Does this help SEO? Yes, when the HTML arrives with the words Google should index. A client-only render can still work, but you are fighting the default. See [ranking on Google](https://www.vishvajeetshukla.in/blog/how-to-rank-website-on-google-india-2026). ## Next step If a Next.js site feels heavy, send the repo or the live URL. I will tell you which files should lose `'use client'` before we talk about a new host. [Contact](https://www.vishvajeetshukla.in/contact) · [vishvajeet4711@gmail.com](mailto:vishvajeet4711@gmail.com) · [hello@vishvajeetshukla.in](mailto:hello@vishvajeetshukla.in) · [More guides](https://www.vishvajeetshukla.in/blog) --- Originally published at [vishvajeetshukla.in](https://www.vishvajeetshukla.in/blog/nextjs-server-components-vs-client-components-2026)