Nuxt and Vue Server-Side Rendering Explained

Server-side rendering (SSR) means the server produces the full HTML of a page for each request, so the browser and search engines receive real content immediately. Nuxt is a framework built on Vue that does this by default: it renders Vue components to HTML on the server, sends that HTML, and then hydrates the page in the browser so it becomes interactive. Compared with a single-page application (SPA) that builds the page only in the browser, SSR usually gives a faster first view and content that search engines can read reliably.

SPA vs SSR vs static generation

	Single-page app (SPA)	Server-side rendering (SSR)	Static generation (SSG)
Initial HTML	Mostly empty shell	Full content	Full content, built ahead of time
First contentful view	After JavaScript runs	Fast	Fastest
SEO	Depends on search engines rendering JavaScript	Reliable	Reliable
Dynamic content	Easy (client-side)	Easy (per request)	Needs rebuilds or client-side fetching
Server needed at runtime	Static hosting is enough	A Node.js server (or serverless functions)	Static hosting is enough

Nuxt supports all three, and can mix them per route (for example, static marketing pages and server-rendered account pages).

How Nuxt SSR works

1. A request arrives at the Nuxt server.
2. Nuxt runs the page's components, including data fetching (for example with useFetch or useAsyncData), on the server.
3. It sends complete HTML, plus the data it used, to the browser.
4. The browser shows the content immediately, then downloads the JavaScript.
5. Vue hydrates the page: it attaches event handlers to the existing HTML, reusing the server's data instead of fetching it again.

Why it matters for business sites

• SEO: search engines receive the content, titles, meta tags and structured data in the HTML. See SEO-friendly web development.
• Speed perception: visitors see content sooner, which helps Largest Contentful Paint. See Core Web Vitals explained.
• Social sharing: link previews rely on meta tags present in the HTML.

Hydration pitfalls

• Hydration mismatches occur when the server and browser render different HTML, for example by using the current time, random values or browser-only APIs during rendering. Vue then warns and may re-render, which costs performance and can cause visual glitches.
• Large JavaScript bundles still need to download and run before the page is interactive, which affects Interaction to Next Paint. Keep components lean and load heavy parts lazily.
• Browser-only code (such as window or localStorage) must run only on the client, for example inside onMounted or a <ClientOnly> wrapper.

What a Nuxt app needs to run

• For SSR: a Node.js runtime (on a VPS, a platform supporting Node.js, or serverless functions), a process manager, and usually a reverse proxy such as Nginx in front.
• For static generation: any static hosting or CDN.
• An API for data, often a separate back end such as Laravel.
• Caching: route-level caching or a CDN can reduce server rendering work for pages that do not change per user.

See what is a VPS and Apache vs Nginx vs LiteSpeed.

Example: per-route rendering in Nuxt

Nuxt lets each part of a site use the rendering mode that suits it, with routeRules in nuxt.config.ts:

export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },              // marketing home page, built at deploy time
    '/blog/**': { swr: 3600 },             // server-rendered, cached and refreshed hourly
    '/account/**': { ssr: false },         // logged-in area rendered in the browser only
    '/old-pricing': { redirect: '/pricing' },
  },
})

The marketing pages get the speed of static files, the blog stays fresh without rendering on every request, and the private account area avoids server rendering it does not need. The exact options depend on your Nuxt version and hosting, so check the current documentation.

Data fetching that avoids double requests

A common mistake in SSR apps is fetching data in a way that runs once on the server and again in the browser. Nuxt's useFetch and useAsyncData transfer the server's result to the browser in the page payload, so hydration reuses it:

const { data: post } = await useFetch(`/api/posts/${route.params.slug}`)

Fetching in onMounted instead would leave the server-rendered HTML empty of that data and repeat the request in every browser, losing the SEO and speed benefits.

SEO details to get right

• Set titles, meta descriptions, canonical links and structured data with Nuxt's head utilities (useSeoMeta, useHead) so they are present in the server-rendered HTML.
• Return real HTTP status codes: a missing page should respond with 404, not a 200 page that says "not found".
• Generate a sitemap from your real routes and content.

See the SEO-friendly web development checklist.

When SSR may not be worth it

• Internal dashboards behind a login, where SEO does not matter and an SPA is simpler.
• Purely static content that changes rarely, where static generation is cheaper.

Frequently Asked Questions

Can Google index SPAs?

Google can render JavaScript, but rendering can be delayed and other search engines and social platforms may not run it. SSR or static generation removes that uncertainty.

Is Nuxt only for large projects?

No. Its file-based routing and conventions make small sites quick to build too, though a CMS may still be simpler for content-heavy sites.

Does SSR make the server slower?

Rendering on the server uses CPU per request. Caching rendered pages and using static generation where possible keeps it efficient.

Related reading

See how to choose a web development stack. For a custom Nuxt or Vue project, see ServerNeed custom web development.

Rendering choices are one part of planning a build; see how to plan a website project.

Sources

• Nuxt documentation: Rendering modes
• Vue.js guide: Server-Side Rendering