Skip to main content
Before a +page.svelte component (and its containing +layout.svelte components) can be rendered, we often need to get some data. This is done by defining load functions.

Page data

A +page.svelte file can have a sibling +page.js that exports a load function:
Thanks to the generated $types module, we get full type safety.

Universal vs server load functions

There are two types of load function:
Files: +page.js and +layout.js
  • Run both on the server and in the browser
  • Can return any values, including component constructors
  • Useful for fetching from external APIs

When does which load function run?

1

Server load functions

Always run on the server.
2

Universal load functions

By default, run on the server during SSR when the user first visits your page. They will then run again during hydration, reusing any responses from fetch requests.
3

Concurrent execution

If a route contains both universal and server load functions, the server load runs first.

Layout data

Your +layout.svelte files can also load data via +layout.js or +layout.server.js:
Data returned from layout load functions is available to child +layout.svelte components and the +page.svelte component.

Using URL data

The load function provides access to URL information:
An instance of URL, containing properties like origin, hostname, pathname and searchParams:
Contains the name of the current route directory:
Derived from url.pathname and route.id:

Making fetch requests

The provided fetch function has special features:

Credentialed requests

Inherits cookie and authorization headers on the server

Relative requests

Can make relative requests on the server

Direct routing

Internal requests go directly to handler function

Response inlining

Responses are captured and inlined into rendered HTML during SSR

Working with cookies

A server load function can get and set cookies:
Cookies will only be passed through the provided fetch function if the target host is the same as the SvelteKit application or a more specific subdomain of it.

Setting headers

Both server and universal load functions have access to a setHeaders function:
Setting the same header multiple times is an error. You can only set a given header once using the setHeaders function.

Using parent data

A load function can access data from a parent load function with await parent():
1

Root layout

2

Child layout

3

Page

Take care not to introduce waterfalls when using await parent(). Call independent data fetches first to avoid delayed renders.

Error handling

If an error is thrown during load, the nearest +error.svelte will be rendered:

Redirects

To redirect users, use the redirect helper:
In the browser, you can also navigate programmatically outside of a load function using goto from $app/navigation.

Streaming with promises

When using a server load, promises will be streamed to the browser as they resolve:
This enables skeleton loading states:
On platforms that do not support streaming (like AWS Lambda), responses will be buffered. The page will only render once all promises resolve.

Rerunning load functions

SvelteKit tracks dependencies to avoid rerunning load functions unnecessarily.

When do load functions rerun?

A load function will rerun when:
It references a property of params whose value has changed
It references a property of url (like url.pathname or url.search) whose value has changed
It calls url.searchParams.get(...) and the parameter in question changes
It calls await parent() and a parent load function reran
A URL it depends on was marked invalid with invalidate(url) or all functions were rerun with invalidateAll()

Manual invalidation

You can rerun load functions using:

Authentication implications

Important considerations for auth checks:
Layout load functions do not run on every request during client-side navigation between child routes.
Recommended strategies:
1

Use hooks

Protect multiple routes before any load functions run using server hooks
2

Page-level guards

Use auth guards directly in +page.server.js for route-specific protection
3

Avoid layout guards

Putting auth guards in +layout.server.js requires all child pages to call await parent() before protected code

Next steps

Form actions

Learn how to handle form submissions

Page options

Configure rendering behavior for your pages