Server load functions (+page.server.js) in Svelte - Deep Dive

Overview - Server load functions (+page.server.js)

What is it?

Server load functions in SvelteKit are special functions placed in a file named +page.server.js. They run on the server before a page loads and prepare data that the page needs. This means the page can start with all the data ready, improving performance and security. These functions help separate server-side logic from client-side code.

Why it matters

Without server load functions, pages would have to fetch data after loading on the client, causing delays and exposing sensitive logic or data to the browser. Server load functions let you fetch data securely and efficiently on the server, so users see content faster and your app stays safe. This improves user experience and protects your backend.

Where it fits

Before learning server load functions, you should understand basic SvelteKit routing and how pages work. After mastering server load functions, you can explore client-side load functions, actions for handling form submissions, and advanced data fetching strategies.

Mental Model

Core Idea

Server load functions run on the server before a page loads to fetch and prepare data securely and efficiently for that page.

Think of it like...

It's like a chef preparing all ingredients in the kitchen before the waiter brings the dish to the customer, so the meal arrives ready to eat without waiting.

┌───────────────────────────┐
│ User requests a page      │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│ +page.server.js load()    │
│ fetches data on server    │
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│ Page receives data        │
│ and renders fully ready   │
└───────────────────────────┘

Build-Up - 6 Steps

1

Foundation

What is +page.server.js file

Concept: Introducing the special file where server load functions live.

In SvelteKit, files named +page.server.js are special. They run only on the server and can export a function called load. This load function runs before the page loads and can fetch data or do other server tasks. The data returned from load is sent to the page component as props.

Result

You have a dedicated place to write server-only code that prepares data for your page.

Understanding the special role of +page.server.js helps you separate server logic from client code, improving security and clarity.

2

Foundation

Basic server load function structure

Concept: How to write a simple load function in +page.server.js.

A server load function is an async function named load exported from +page.server.js. It receives a parameter with useful info like request details. Inside, you can fetch data from a database or API. You return an object with data properties that the page can use. Example: export async function load() { const data = await fetchSomeData(); return { data }; }

Result

The page receives the data object as props and can display it immediately.

Knowing the load function shape and return format is key to passing server-fetched data to your page.

3

Intermediate

Accessing request info in load function

🤔Before reading on: do you think the load function can see user cookies or headers? Commit to yes or no.

Concept: Using the load function's parameter to access request details like cookies and headers.

The load function receives an event object with request info. You can read cookies, headers, or URL params to customize data fetching. Example: export async function load({ cookies, url }) { const token = cookies.get('session'); const page = url.searchParams.get('page') || '1'; const data = await fetchDataWithToken(token, page); return { data }; }

Result

You can fetch data tailored to the user's session or query parameters securely on the server.

Understanding event parameters lets you build personalized and secure server-side data fetching.

4

Intermediate

Difference from client load functions

🤔Before reading on: do you think server load functions run in the browser or only on the server? Commit to your answer.

Concept: Clarifying that +page.server.js load functions run only on the server, unlike client load functions in +page.js.

SvelteKit supports load functions in +page.js and +page.server.js. The server load function runs only on the server and can access secrets and databases. The client load function runs in the browser and cannot access server-only data. If both exist, server load runs first, then client load can run for client-side navigation.

Result

You know when to use server load functions for secure data and client load functions for client-only logic.

Distinguishing server vs client load functions prevents security leaks and improves app architecture.

5

Advanced

Handling errors and redirects in load

🤔Before reading on: do you think throwing an error in load shows a blank page or a custom error page? Commit to your guess.

Concept: Using special SvelteKit helpers to handle errors and redirects inside server load functions.

Inside load, you can throw errors with status codes to show error pages, or throw redirect responses to send users elsewhere. Example: import { error, redirect } from '@sveltejs/kit'; export async function load() { const data = await fetchData(); if (!data) throw error(404, 'Not found'); if (data.needsRedirect) throw redirect(302, '/login'); return { data }; }

Result

Your app gracefully handles missing data or redirects users before the page loads.

Knowing how to control flow with errors and redirects in load improves user experience and app robustness.

6

Expert

Server load function caching and performance

🤔Before reading on: do you think server load functions run on every request or can be cached? Commit to your answer.

Concept: Understanding how server load functions interact with caching and how to optimize performance.

By default, server load functions run on every request to provide fresh data. However, you can use HTTP cache headers or SvelteKit's built-in caching strategies to reduce load. Also, avoid heavy computations inside load; instead, use background jobs or cache results. Knowing when to cache or revalidate data is key for scalable apps.

Result

Your pages load faster and your server handles more users efficiently.

Understanding caching tradeoffs in server load functions helps build fast, scalable SvelteKit apps.

Under the Hood

When a user requests a page, SvelteKit checks for a +page.server.js file. If it exists, it runs the exported load function on the server. This function can access server-only resources like databases or environment variables. The returned data is serialized and sent to the client along with the page HTML. This happens before the page renders, so the client starts with all data ready. The server isolates this code from the browser, preventing exposure of secrets.

Why designed this way?

SvelteKit separates server and client code to improve security and performance. Running load on the server first means data fetching can use sensitive resources safely. It also reduces client-side delays and avoids exposing backend logic. This design balances developer experience with real-world app needs like SEO and fast loading.

User Request
   │
   ▼
+page.server.js load() runs on server
   │
   ▼
Fetch data, access secrets
   │
   ▼
Return data object
   │
   ▼
Server sends HTML + data to client
   │
   ▼
Page renders with data ready

Myth Busters - 4 Common Misconceptions

Quick: Do server load functions run in the browser? Commit to yes or no.

Common Belief: Server load functions run in the browser just like client code.

Reality: Server load functions run only on the server and never in the browser.

Why it matters: Thinking they run in the browser can lead to exposing secrets or writing code that breaks because browser APIs are missing.

Quick: Can you use browser-only APIs like localStorage inside server load functions? Commit to yes or no.

Common Belief: You can use any JavaScript API inside server load functions, including browser APIs.

Reality: Server load functions run on the server where browser APIs like localStorage do not exist.

Why it matters: Using browser APIs in server load causes runtime errors and breaks your app.

Quick: Does returning data from server load automatically cache it? Commit to yes or no.

Common Belief: Data returned from server load functions is cached automatically for performance.

Reality: By default, server load functions run on every request unless you explicitly add caching strategies.

Why it matters: Assuming automatic caching can cause unnecessary server load and slow responses.

Quick: If you throw an error in load, does the page crash silently? Commit to yes or no.

Common Belief: Throwing an error in load causes the page to crash with no feedback.

Reality: SvelteKit catches errors thrown in load and shows a friendly error page with the status code.

Why it matters: Knowing this lets you handle errors gracefully and improve user experience.

Expert Zone

1

Server load functions can run multiple times during client-side navigation, not just on the first page load, affecting caching strategies.

2

You can combine server load functions with hooks to share authentication logic across pages efficiently.

3

Returned data from server load is serialized and sent to the client, so avoid returning complex objects like class instances or functions.

When NOT to use

Avoid using server load functions for data that changes very frequently and can be fetched client-side without security concerns. In such cases, client load functions or direct client fetches are better. Also, for static sites, prefer prerendering or static data fetching to reduce server load.

Production Patterns

In production, server load functions often fetch data from databases or APIs, check user sessions via cookies, and handle redirects for authentication. They are combined with endpoint APIs for mutations and use caching headers to optimize performance.

Connections

API endpoints

Server load functions often fetch data from API endpoints or databases.

Understanding API endpoints helps you design server load functions that efficiently retrieve data for pages.

Authentication and sessions

Server load functions can read cookies to check user authentication status before rendering pages.

Knowing how sessions work helps you secure pages and personalize content in server load functions.

Pre-rendering (Static Site Generation)

Server load functions can run at build time for pre-rendered pages or at request time for dynamic pages.

Understanding pre-rendering helps you decide when to use server load functions for dynamic data versus static content.

Common Pitfalls

#1 Trying to use browser APIs like localStorage inside server load functions.

Wrong approach:

export async function load() {
const token = localStorage.getItem('token');
return { token };
}

Correct approach:

export async function load({ cookies }) {
const token = cookies.get('token');
return { token };
}

Root cause:

Confusing server environment with browser environment leads to using unavailable APIs.

#2 Returning complex objects like class instances from load function.

Wrong approach:

export async function load() {
return { user: new User('Alice') };
}

Correct approach:

export async function load() {
return { user: { name: 'Alice' } };
}

Root cause:

Not realizing returned data is serialized and must be plain JSON-compatible objects.

#3 Not handling errors in load, causing unclear failures.

Wrong approach:

export async function load() {
const data = await fetchData();
if (!data) return null;
return { data };
}

Correct approach:

import { error } from '@sveltejs/kit';
export async function load() {
const data = await fetchData();
if (!data) throw error(404, 'Data not found');
return { data };
}

Root cause:

Ignoring error handling leads to silent failures or broken pages.

Key Takeaways

Server load functions in +page.server.js run only on the server before a page loads to fetch and prepare data securely.

They receive an event object with request info like cookies and URL parameters, enabling personalized data fetching.

Errors and redirects thrown inside load are handled gracefully by SvelteKit to improve user experience.

Returned data must be serializable plain objects because it is sent from server to client.

Understanding the difference between server and client load functions is crucial for security and app design.

Practice

1. What is the main purpose of a server load function in a +page.server.js file in SvelteKit?

easy

A. To fetch or prepare data on the server before the page loads

B. To handle client-side user interactions

C. To style the page components

D. To manage browser cookies on the client

Solution

1. Step 1: Understand server load function role

   Server load functions run on the server to get data before the page renders.

2. Step 2: Compare options to this role

   Only To fetch or prepare data on the server before the page loads describes fetching or preparing data on the server side before page load.

3. Final Answer:

   To fetch or prepare data on the server before the page loads -> Option A

4. Quick Check:

   Server load function = fetch data before page load [OK]

Hint: Server load functions run on server, not client [OK]

Common Mistakes:

• Confusing server load with client-side event handlers
• Thinking server load manages styles or cookies
• Assuming server load runs in the browser

2. Which of the following is the correct way to export a server load function in +page.server.js?

easy

A. export function load() { return { data: 'hello' }; }

B. export const load = () => { return { data: 'hello' }; }

C. export default function load() { return { data: 'hello' }; }

D. function load() { return { data: 'hello' }; }

Solution

1. Step 1: Recall SvelteKit server load export syntax

   Server load functions are exported as named exports, usually as a const arrow function.

2. Step 2: Check each option

   export const load = () => { return { data: 'hello' }; } uses export const load = () => { ... }, which is correct. export function load() { return { data: 'hello' }; } exports a function declaration but not as const, which is allowed but less common. export default function load() { return { data: 'hello' }; } uses default export which is incorrect. function load() { return { data: 'hello' }; } does not export at all.

3. Final Answer:

   export const load = () => { return { data: 'hello' }; } -> Option B

4. Quick Check:

   Named export const load = arrow function [OK]

Hint: Use named export const load = () => {} [OK]

Common Mistakes:

• Using default export instead of named export
• Not exporting the load function at all
• Using function declaration without export

3. Given this +page.server.js code, what will be the value of data.message in the page?

export const load = () => {
  return { message: 'Hello from server' };
};

medium

A. 'Hello from client'

B. undefined

C. An error occurs

D. 'Hello from server'

Solution

1. Step 1: Understand the load function return

   The load function returns an object with a property message set to 'Hello from server'.

2. Step 2: Recognize data passed to page

   The returned object properties become available as data in the page, so data.message equals 'Hello from server'.

3. Final Answer:

   'Hello from server' -> Option D

4. Quick Check:

   Returned object property = data property [OK]

Hint: Returned object keys become data properties [OK]

Common Mistakes:

• Expecting undefined if not wrapped in another object
• Confusing server message with client message
• Thinking load function causes error without async

4. What is wrong with this +page.server.js code?

export const load = async () => {
  const res = await fetch('/api/data');
  const data = await res.json();
  return data;
};

medium

A. The load function must not be async

B. Returning data directly instead of an object causes error

C. Fetching from '/api/data' on server causes an infinite loop

D. Missing export keyword

Solution

1. Step 1: Analyze fetch call in server load

   The load function fetches from '/api/data', which is likely a route handled by the same app.

2. Step 2: Understand server fetch behavior

   Fetching from an internal API route in server load can cause the server to call itself repeatedly, causing an infinite loop.

3. Final Answer:

   Fetching from '/api/data' on server causes an infinite loop -> Option C

4. Quick Check:

   Internal fetch in server load risks infinite loop [OK]

Hint: Avoid fetching internal routes directly in server load [OK]

Common Mistakes:

• Thinking async is not allowed in load
• Returning data directly is valid
• Forgetting to export load function

5. You want to load user data securely on the server and pass it to the page. Which approach correctly uses +page.server.js to fetch user info from a database and expose only the username?

hard

A. export const load = async () => {
const user = await db.getUser();
return { username: user.username };
};

B. export const load = async () => {
const user = await db.getUser();
return user;
};

C. export const load = () => {
fetch('/api/user').then(res => res.json());
return {};
};

D. export const load = async () => {
const user = await fetch('/api/user');
return { user };
};

Solution

1. Step 1: Identify secure data fetching on server

   export const load = async () => { const user = await db.getUser(); return { username: user.username }; }; fetches user data directly from the database on the server, which is secure.

2. Step 2: Check data exposure

   export const load = async () => { const user = await db.getUser(); return { username: user.username }; }; returns only the username property, exposing minimal info to the page.

3. Step 3: Evaluate other options

   export const load = async () => { const user = await db.getUser(); return user; }; returns full user object, exposing sensitive data. export const load = () => { fetch('/api/user').then(res => res.json()); return {}; }; uses client fetch incorrectly in server load. export const load = async () => { const user = await fetch('/api/user'); return { user }; }; fetches from API route which may cause loops or expose more data.

4. Final Answer:

   export const load = async () => { const user = await db.getUser(); return { username: user.username }; }; -> Option A

5. Quick Check:

   Server fetch minimal data, return only needed props [OK]

Hint: Fetch securely on server, return only needed data [OK]

Common Mistakes:

• Returning full user object exposing sensitive info
• Fetching from API route inside server load
• Using client fetch inside server load