Page optionsEdit this page on GitHub
By default, SvelteKit will render any component first on the server and send it to the client as HTML. It will then render the component again in the browser to make it interactive in a process called hydration. For this reason, you need to ensure that components can run in both places. SvelteKit will then initialise a router that takes over subsequent navigations.
If both are specified, per-page settings override per-app settings in case of conflicts.
SvelteKit includes a client-side router that intercepts navigations (from the user clicking on links, or interacting with the back/forward buttons) and updates the page contents, rather than letting the browser handle the navigation by reloading.
<script context="module"> export const router = false; </script>
Note that this will disable client-side routing for any navigation from this page, regardless of whether the router is already active.
browser.hydrate config option or the page-level
<script context="module"> export const hydrate = false; </script>
trueor no content will be rendered.
Prerendering happens automatically for any page with the
<script context="module"> export const prerender = true; </script>
Alternatively, you can set
true and prerender everything except pages that are explicitly marked as not prerenderable:
<script context="module"> export const prerender = false; </script>
If your entire app is suitable for prerendering, you can use
adapter-static, which will output files suitable for use with any static webserver.
The prerenderer will start at the root of your app and generate HTML for any prerenderable pages it finds. Each page is scanned for
<a> elements that point to other pages that are candidates for prerendering — because of this, you generally don't need to specify which pages should be accessed. If you do need to specify which pages should be accessed by the prerenderer, you can do so with the
entries option in the prerender configuration.
When not to prerenderpermalink
The basic rule is this: for a page to be prerenderable, any two users hitting it directly must get the same content from the server.
Not all pages are suitable for prerendering. Any content that is prerendered will be seen by all users. You can of course fetch personalized data in
onMountin a prerendered page, but this may result in a poorer user experience since it will involve blank initial content or loading indicators.
Note that you can still prerender pages that load data based on the page's parameters, like our
src/routes/blog/[slug].svelte example from earlier. The prerenderer will intercept requests made inside
load, so the data served from
src/routes/blog/[slug].json.js will also be captured.
url.searchParams during prerendering is forbidden. If you need to use it, ensure you are only doing so in the browser (for example in
Because prerendering writes to the filesystem, it isn't possible to have two endpoints that would cause a directory and a file to have the same name. For example,
src/routes/foo/bar.js would try to create
foo/bar, which is impossible.
For that reason among others, it's recommended that you always include a file extension —
src/routes/foo/bar.json.js would result in
foo/bar.json files living harmoniously side-by-side.
For pages, we skirt around this problem by writing
foo/index.html instead of