Error pages (+error.svelte) - Performance & Optimization

Performance: Error pages (+error.svelte)

MEDIUM IMPACT

This affects the page load speed and user experience when an error occurs, impacting how quickly the error content is shown and how stable the layout remains.

Displaying a custom error page when a route fails

Svelte

<script>
  export let error;
</script>

<section aria-live="assertive" role="alert">
  <h1>{error.status}</h1>
  <p>{error.message}</p>
</section>

Minimal markup and no extra components ensure the error page loads instantly and layout stays stable.

📈 Performance GainSingle reflow, fast LCP under 100 ms, and no extra bundle weight

Displaying a custom error page when a route fails

Svelte

<script>
  import HeavyComponent from '../components/HeavyComponent.svelte';
  export let error;
</script>

<HeavyComponent />
<h1>{error.status}</h1>
<p>{error.message}</p>

Loading a heavy component on the error page delays error content rendering and increases bundle size unnecessarily.

📉 Performance CostBlocks rendering for 200+ ms due to large bundle and triggers multiple reflows from complex layout

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Heavy component on error page	High (many nodes)	Multiple reflows	High paint cost	[X] Bad
Minimal markup with semantic HTML	Low (few nodes)	Single reflow	Low paint cost	[OK] Good

Rendering Pipeline

When an error occurs, the browser renders the +error.svelte component. Simple markup and styles allow quick style calculation and layout, minimizing paint time and avoiding layout shifts.

→Style Calculation

→Layout

→Paint

→Composite

⚠️ BottleneckLayout due to complex or large components on error page

Core Web Vital Affected

LCP, CLS

This affects the page load speed and user experience when an error occurs, impacting how quickly the error content is shown and how stable the layout remains.

Optimization Tips

1Keep error pages minimal with simple HTML and CSS.

2Avoid importing large or complex components in +error.svelte.

3Use semantic roles and ARIA attributes for accessibility without extra cost.

Performance Quiz - 3 Questions

What is the main performance benefit of keeping the +error.svelte page simple?

A More animations on the error page

B Larger bundle size for better visuals

C Faster error content display and less layout shift

D More DOM nodes for flexibility

DevTools: Performance

How to check: Open DevTools, go to Performance tab, reload the page with an error, and record the load. Look for long tasks or delayed paint events.

What to look for: Check the Largest Contentful Paint timing and layout shift events to confirm fast error page rendering and visual stability.

Practice

1. What is the main purpose of the +error.svelte file in a SvelteKit project?

easy

A. To handle user authentication

B. To display a custom error page when an error occurs in the app

C. To define global styles for the app

D. To manage routing between pages

Solution

1. Step 1: Understand the role of +error.svelte

   This file is specifically designed to show error messages when something goes wrong in the app.

2. Step 2: Compare with other options

   Authentication, styling, and routing are handled elsewhere, not in +error.svelte.

3. Final Answer:

   To display a custom error page when an error occurs in the app -> Option B

4. Quick Check:

   Error page = +error.svelte [OK]

Hint: Remember: +error.svelte shows errors, not routes or styles [OK]

Common Mistakes:

• Confusing error page with routing or styling files
• Thinking +error.svelte handles authentication
• Assuming it is for normal page content

2. Which of the following is the correct way to access the HTTP status code inside +error.svelte?

easy

A. {error.status}

B. {params.status}

C. {error.message}

D. {status}

Solution

1. Step 1: Recall SvelteKit error props

   In +error.svelte, the status is passed as a separate prop, not inside error.

2. Step 2: Check each option

   {error.status} is incorrect because error holds the error object, but status is separate. {status} is correct. {error.message} is for the message, not status. {params.status} is unrelated.

3. Final Answer:

   {status} -> Option D

4. Quick Check:

   Status code = {status} [OK]

Hint: Status is a separate prop, not inside error object [OK]

Common Mistakes:

• Using {error.status} instead of {status}
• Confusing error message with status code
• Trying to access status from params

3. Given this +error.svelte snippet:

<script>
  export let error;
  export let status;
</script>

<h1>Error {status}</h1>
<p>{error.message}</p>

What will be displayed if status is 404 and error.message is "Page not found"?

medium

A. Error 404Page not found

B. Error Page not found404

C. Error 0undefined

D. Error 404undefined

Solution

1. Step 1: Substitute values in template

   The {status} is 404, so <h1> shows "Error 404". The {error.message} is "Page not found", so <p> shows that text.

2. Step 2: Confirm output matches option

   Error 404
   Page not found matches exactly: "Error 404" and "Page not found". Others have wrong order or undefined values.

3. Final Answer:

   Error 404
   Page not found -> Option A

4. Quick Check:

   Display status and message correctly [OK]

Hint: Match variable names exactly to output text [OK]

Common Mistakes:

• Mixing status and message order
• Assuming undefined values
• Confusing error.message with status

4. You wrote this +error.svelte code:

<script>
  export let error;
</script>

<h1>Error {status}</h1>
<p>{error.message}</p>

But when an error occurs, the page shows Error undefined. What is the problem?

medium

A. You need to import status from another file

B. You should use {error.status} instead of {status}

C. You forgot to export the status prop

D. The error object does not have a message property

Solution

1. Step 1: Identify missing prop export

   The code uses {status} but does not export status from the script, so it is undefined.

2. Step 2: Check other options

   {error.status} is incorrect because status is a separate prop. Importing status is not needed. error.message exists, so that is not the issue.

3. Final Answer:

   You forgot to export the status prop -> Option C

4. Quick Check:

   Export all props used in template [OK]

Hint: Always export props you use in template [OK]

Common Mistakes:

• Using {status} without exporting it
• Trying to access status inside error object
• Assuming error.message is missing

5. You want to create a custom error page that shows a special message for 404 errors and a generic message for others. Which +error.svelte code correctly implements this?

hard

A. <script>
export let error;
export let status;
</script>

<h1>Error {status}</h1>
<p>{status === 404 ? 'Page not found' : error.message}</p>

B. <script>
export let error;
</script>

<h1>Error {error.status}</h1>
<p>{error.message === 404 ? 'Page not found' : error.message}</p>

C. <script>
export let error;
export let status;
</script>

<h1>Error {status}</h1>
<p>{error.message === 404 ? 'Page not found' : error.message}</p>

D. <script>
export let error;
export let status;
</script>

<h1>Error {status}</h1>
<p>{status === '404' ? 'Page not found' : error.message}</p>

Solution

1. Step 1: Check how status is used

   Status is a number, so comparing status === 404 is correct.

   <script>
     export let error;
     export let status;
   </script>
   
   <h1>Error {status}</h1>
   <p>{status === 404 ? 'Page not found' : error.message}</p>

   and D do this, but D compares to string '404' which is wrong.

2. Step 2: Check error.message usage

   <script>
     export let error;
     export let status;
   </script>
   
   <h1>Error {status}</h1>
   <p>{status === 404 ? 'Page not found' : error.message}</p>

   uses error.message as fallback, which is correct. Options B and C incorrectly compare error.message to 404, which makes no sense.

3. Step 3: Confirm correct syntax and logic

   <script>
     export let error;
     export let status;
   </script>
   
   <h1>Error {status}</h1>
   <p>{status === 404 ? 'Page not found' : error.message}</p>

   correctly exports both props and uses a ternary to show special message for 404, else shows error.message.

4. Final Answer:

   Option A code correctly handles 404 and other errors -> Option A

5. Quick Check:

   Compare status number, not error.message [OK]

Hint: Compare status number with 404, not error.message [OK]

Common Mistakes:

• Comparing error.message to 404 instead of status
• Comparing status to string '404' instead of number
• Not exporting both status and error props