As developers, we know how important it is to reduce the amount of JavaScript we ship to the browser. And since Nuxt has been around, it has showed how powerful SSR can be for building performant applications.

Nuxt offers experimental features like Server Components to take our game to the next level but before using them, it’s important to take a look back at how hydration works and how Nuxt handles Server Side Rendering.

When you build a typical Nuxt application with SSR enabled, here's what happens:

On the Server:

• Vue renders your components to static HTML
• The server generates the complete DOM structure
• This HTML is sent to the browser immediately

On the Client (Hydration):

• The browser receives static HTML and displays it instantly
• JavaScript bundles download in the background
• Vue "hydrates" the static HTML by creating the virtual DOM, matching it to existing DOM nodes, and attaching event listeners
• The page becomes fully interactive

This hydration process is necessary but comes with overhead. Every component needs to be downloaded as JavaScript, executed on the client, and "woken up" to become interactive. The JavaScript for your entire application must be downloaded and parsed even if most of it renders static content.

How Sever Components can help

Server components (also called component islands in Nuxt) fundamentally change this equation. They allow you to mark specific components to only render on the server and never hydrate on the client. They have some key benefits:

• Reduced JavaScript Bundle Size: Server components and their dependencies are completely excluded from the client bundle. If you have a component that uses a heavy markdown parser or syntax highlighter, that entire library stays on the server.
• Zero Hydration Overhead: Since server components don't hydrate, there's no virtual DOM creation, no event listener attachment, and no reconciliation work on the client. The component is truly static HTML.
• Secure Server-Only Logic: You can safely include database queries, API keys, or other sensitive operations directly in server components without worrying about exposing them to the client.
• Works with Static Sites: Despite the name, server components work perfectly with static site generation (SSG). Nuxt prerenders them at build time, so you can use them even on static hosting platforms like GitHub Pages or Netlify.

When and where to use them

Server components shine in specific scenarios where you have expensive rendering logic but don't need client-side interactivity. For example:

• Syntax Highlighting and Code Blocks: Libraries like Shiki can add significant weight to your bundle. A syntax highlighter component is perfect as a server component since the highlighted code is just static HTML.
• Markdown Rendering: Parsing and rendering markdown with MDC syntax or other parsers can be done entirely on the server. The rendered HTML is sent to the client without shipping the parser.
• Static Footers and Headers: Navigation bars, footers, or any layout component that displays static content are excellent candidates. They add zero JavaScript but still render correctly.
• Content from APIs: If you're fetching data from a CMS or database to display read-only content, server components eliminate the need to ship that fetching logic to the client.

Implementing Server Components

In Nuxt 4, server components are still experimental but increasingly stable. Here's how to use them:

      // nuxt.config.ts
export default defineNuxtConfig({
  experimental: {
    componentIslands: true
  }
}

    

Simply add the .server.vue suffix to your component file:

      components/
  HighlightedCode.server.vue
  SiteFooter.server.vue
  MarkdownRenderer.server.vue

    

Use it like any component:

      <template>
  <div>
    <HighlightedCode :code="myCode" language="typescript" />
    <SiteFooter />
  </div>
</template>

    

That's it! No special syntax in your template. The component renders on the server, and Nuxt sends only the HTML to the client.

A final note

While reducing JavaScript bundle size is the most tangible benefit, server components offer something deeper: architectural clarity. They force you to think about data flow, component boundaries, and where state truly lives. This discipline makes your applications more maintainable. When you see a .server.vue component, you immediately know it has no client-side dependencies, no reactivity, no event handlers. It's self-documenting architecture.

The convergence of server and client rendering represents the maturation of the JavaScript ecosystem. We're moving past the "SSR vs CSR" debates toward hybrid approaches that acknowledge both have their place.