Performance & Deploy

Fast by default

Because Svelte is a compiler (the very first lesson), the performance baseline is already good: there’s no virtual DOM runtime to ship, and components compile to targeted update code. You spend far less time fighting bundle size than in runtime-framework apps — the framework overhead riding along with your code is small.

That doesn’t make performance automatic. Your own code, images, third-party libraries, and data-loading choices still matter. But the starting point is lean, and the tools below help you keep it that way.

Measuring what you ship

Before optimizing, measure. vite build reports the output sizes, and Vite’s ecosystem has bundle visualizers (e.g. rollup-plugin-visualizer) to show what’s taking space — usually a heavy third-party dependency, not Svelte itself.

npm run build      # vite build — prints chunk sizes

Watch for: a large date/utility library imported whole, an icon set pulled in entirely, or a component eagerly loaded that could be lazy. SvelteKit code-splits per route automatically, so a heavy page doesn’t weigh down the rest of the app.

Adapters: choosing a deploy target

A SvelteKit app is deployed through an adapter that transforms the build for a specific platform. You set it in svelte.config.js:

import adapter from '@sveltejs/adapter-auto';

export default {
  kit: {
    adapter: adapter(),
  },
};

Adapter	Deploys to
`adapter-auto`	Detects common platforms (Vercel, Netlify, Cloudflare…) automatically
`adapter-node`	A long-running Node server you host yourself
`adapter-cloudflare`	Cloudflare Pages / Workers (edge)
`adapter-static`	A fully static site — HTML/CSS/JS on any CDN

adapter-auto is the zero-config default; you switch to a specific adapter when you know your target (and need its options).

flowchart LR
  build["vite build (SvelteKit)"] --> adapter["adapter"]
  adapter --> node["Node server"]
  adapter --> edge["Cloudflare / edge"]
  adapter --> static["static CDN"]

One build, many deploy targets via adapters

Static vs server

The big deployment decision mirrors the rendering choice:

Static — with adapter-static (or export const prerender = true on prerenderable routes), pages are built to HTML at build time and served from any CDN. Perfect for content that’s the same for everyone; no server needed.
Server — with a runtime adapter (node/cloudflare/…), pages render on demand for request-time data (the logged-in user, live data). You can mix: prerender the marketing pages, render the dashboard on demand.

Set export const prerender = true on the routes that can be static and let the rest render on demand — the same hybrid approach that keeps most of the site cacheable while a few routes stay dynamic.