SvelteKit Prerendering: Build-Time HTML for Faster Sites
SvelteKit prerendering creates static HTML files at build time for instant loads. It's ideal for content that doesn't change per user, like marketing pages or blog posts. The main footgun: unlinked pages won't be found unless you explicitly list them.
Why it exists
By default, SvelteKit uses server-side rendering (SSR), which runs code on a server for every page visit. For pages with static content, this is unnecessary overhead that adds latency. Prerendering solves this by doing the rendering work once, at build time, not on every request.
The mental model
Think of prerendering as baking a cake before a party instead of baking a new one for each guest. You trade the ability to customize each slice (dynamic, per-user data) for the speed of having it ready to serve instantly. The output is a simple, fast HTML file that browsers can display immediately.
How it works
You enable prerendering by exporting export const prerender = true; from a +page.js or +page.server.js file. During the build process, SvelteKit starts at your app's root, renders the page to HTML, and scans it for tags pointing to other internal pages. It follows these links, prerendering each eligible page it finds. Prerendered routes are then excluded from the server manifest, resulting in smaller serverless function bundles. For routes that are sometimes dynamic, prerender = 'auto' will prerender the page but keep it available for on-demand rendering if needed.
When to use it
Use prerendering for any page where the content is the same for every user. This is common for marketing pages, landing pages, documentation, and blog posts. For entire sites that are static, you can use adapter-static to output a folder of HTML files ready for any static host.
When not to use it
Do not prerender pages that require user-specific data or rely on information only available at request time, like checking cookies for authentication. A user dashboard, a settings page, or a shopping cart are classic examples of pages that should be dynamically rendered, not prerendered.
One canonical example
A common pattern is to enable prerendering for the entire site in the root +layout.server.js with export const prerender = true;. Then, for a dynamic page like /dashboard, you create a +page.server.js file and explicitly disable it with export const prerender = false;. This makes your site "static-first," optimizing for speed by default while allowing dynamic exceptions.
Interview question
For which SvelteKit page scenario would prerendering be the most effective optimization strategy?
- a.A static "About Us" page with company history and contact information.Correct
- b.A checkout page that processes payment and updates inventory in real-time.
- c.A product catalog page whose content changes based on user authentication status.
- d.A user's personalized profile page displaying their private data.
Why? this is the answer
Prerendering is ideal for pages with content that is the same for every user, such as static marketing or informational pages, as it generates HTML at build time for instant loading. Pages involving user-specific data, authentication, or real-time transactions are dynamic and should not be prerendered.
Just read this? Test yourself on what you have been reading.
Read the original → svelte.dev
- #sveltekit
- #prerendering
- #ssr
- #static site generation
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles