Error handling with error.tsx in NextJS - Performance & Optimization

Performance: Error handling with error.tsx

MEDIUM IMPACT

This affects page load speed and interaction responsiveness by controlling how errors are caught and displayed without full page reloads.

Handling runtime errors in a Next.js app to avoid full page reloads

NextJS

export default function Error({ error, reset }) {
  return (
    <div role="alert">
      <p>Something went wrong: {error.message}</p>
      <button onClick={() => reset()}>Try again</button>
    </div>
  );
}

// error.tsx catches errors and allows recovery without reload

Error boundary catches errors and renders fallback UI instantly, avoiding full reload and layout shifts.

📈 Performance GainImproves INP by enabling quick recovery, reduces CLS by stable error UI, avoids blocking rendering

Handling runtime errors in a Next.js app to avoid full page reloads

NextJS

export default function Page() {
  if (someError) {
    throw new Error('Oops!');
  }
  return <div>Content</div>;
}

// No error boundary or error.tsx used

Without error.tsx, errors cause full page reloads or unstyled error screens, blocking interaction and causing layout shifts.

📉 Performance CostBlocks rendering until reload, causes CLS due to layout shifts, increases INP by delaying error recovery

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
No error.tsx, error causes full reload	High (full page reload creates many DOM nodes)	Multiple (full re-layout triggered)	High (browser repaints entire page)	[X] Bad
Using error.tsx with fallback UI	Low (only error UI nodes rendered)	Single (only error UI layout)	Low (small repaint area)	[OK] Good

Rendering Pipeline

When an error occurs, error.tsx intercepts it before the browser triggers a full reload. The fallback UI is rendered during the Paint stage, avoiding re-layout of the entire page.

→JavaScript Execution

→Style Calculation

→Paint

→Composite

⚠️ BottleneckJavaScript Execution due to error handling logic

Core Web Vital Affected

INP

This affects page load speed and interaction responsiveness by controlling how errors are caught and displayed without full page reloads.

Optimization Tips

1Use error.tsx to catch errors and show fallback UI without full page reloads.

2Keep error UI simple to minimize JavaScript execution and paint time.

3Avoid heavy layout changes in error UI to reduce layout shifts (CLS).

Performance Quiz - 3 Questions

What is the main performance benefit of using error.tsx in Next.js?

A It eliminates all JavaScript execution during errors.

B It reduces the initial page load size by lazy loading error components.

C It prevents full page reloads on errors, improving interaction responsiveness.

D It automatically caches error pages for faster reloads.

DevTools: Performance

How to check: Record a session where an error occurs. Look for long tasks or full page reloads in the flame chart.

What to look for: Check if error handling triggers full reload (bad) or quick fallback UI paint (good). Also watch for layout shifts in the Experience section.

Practice

1. What is the main purpose of the error.tsx file in a Next.js route?

easy

A. To catch and display errors that happen in that route

B. To define the page layout and styles

C. To fetch data from an API

D. To handle user authentication

Solution

1. Step 1: Understand the role of error.tsx

   This file is designed to catch errors that occur in its route and show a friendly message to users.

2. Step 2: Compare with other options

   Options A, C, and D describe unrelated tasks like layout, data fetching, or authentication, which are not the purpose of error.tsx.

3. Final Answer:

   To catch and display errors that happen in that route -> Option A

4. Quick Check:

   Error handling = To catch and display errors that happen in that route [OK]

Hint: Remember: error.tsx shows errors in its route [OK]

Common Mistakes:

• Confusing error.tsx with layout.tsx
• Thinking error.tsx fetches data
• Assuming error.tsx manages authentication

2. Which of the following is the correct way to export an error component in error.tsx for Next.js?

easy

A. const Error = () => { Error occurred }; export default Error;

B. function Error() { return Error occurred; }

C. export default function Error() { return Error occurred; }

D. export function Error() { return Error occurred; }

Solution

1. Step 1: Check correct export syntax

   Next.js expects a default export for the error component in error.tsx. export default function Error() { return

   Error occurred

   ; } uses export default function, which is correct.

2. Step 2: Identify syntax errors in other options

   function Error() { return

   Error occurred

   ; } lacks export, so it won't be recognized. export function Error() { return

   Error occurred

   ; } exports a named function, not default. const Error = () => {

   Error occurred

   }; export default Error; misses a return statement inside the arrow function, causing no output.

3. Final Answer:

   export default function Error() { return <p>Error occurred</p>; } -> Option C

4. Quick Check:

   Default export function = export default function Error() { return

   Error occurred

   ; } [OK]

Hint: Use default export function for error component [OK]

Common Mistakes:

• Forgetting to export default
• Using named exports instead of default
• Missing return statement in arrow function

3. Given this error.tsx component, what will be rendered when an error occurs?

export default function Error() {
  return (
    <section role="alert">
      <h1>Oops! Something went wrong.</h1>
      <button onClick={() => window.location.reload()}>Try again</button>
    </section>
  );
}

medium

A. An error message but no button

B. A blank page with no content

C. A console error but no UI change

D. A section with a heading and a button that reloads the page

Solution

1. Step 1: Analyze the JSX structure

   The component returns a <section> with role="alert", containing a heading and a button with an onClick that reloads the page.

2. Step 2: Understand the rendered output

   When an error happens, this UI shows a message and a clickable button that refreshes the page, matching A section with a heading and a button that reloads the page.

3. Final Answer:

   A section with a heading and a button that reloads the page -> Option D

4. Quick Check:

   JSX returns alert section with reload button = A section with a heading and a button that reloads the page [OK]

Hint: Look for JSX elements and event handlers to predict output [OK]

Common Mistakes:

• Ignoring the button's onClick behavior
• Assuming no UI renders on error
• Confusing role attribute with content

4. You wrote this error.tsx but it does not show the error UI when an error happens:

function Error() {
  return <p>Error!</p>;
}
export default Error;

What is the likely problem?

medium

A. The component name must be lowercase

B. The file must be named error.tsx and placed in the route folder

C. The component is not exported as default

D. The component must return a div, not a p

Solution

1. Step 1: Check export and component name

   The component is exported as default and named with uppercase, which is correct.

2. Step 2: Verify file placement and naming

   Next.js requires the error.tsx file to be in the route folder to catch errors there. If misplaced or misnamed, it won't work.

3. Final Answer:

   The file must be named <code>error.tsx</code> and placed in the route folder -> Option B

4. Quick Check:

   Correct file name and location = The file must be named error.tsx and placed in the route folder [OK]

Hint: Check file name and folder location for error.tsx [OK]

Common Mistakes:

• Using lowercase component name
• Returning wrong HTML tags
• Not placing error.tsx in the route folder

5. You want to improve accessibility in your error.tsx component. Which change best helps screen reader users?

hard

A. Add role="alert" to the container element

B. Use only <div> elements without roles

C. Remove all buttons to avoid confusion

D. Use inline styles to highlight the error text

Solution

1. Step 1: Understand accessibility roles

   Adding role="alert" tells screen readers to announce the error immediately, improving accessibility.

2. Step 2: Evaluate other options

   Use only <div> elements without roles lacks roles, reducing accessibility. Remove all buttons to avoid confusion removes helpful retry buttons. Use inline styles to highlight the error text styles visually but doesn't help screen readers.

3. Final Answer:

   Add <code>role="alert"</code> to the container element -> Option A

4. Quick Check:

   Use ARIA roles for accessibility = Add role="alert" to the container element [OK]

Hint: Use ARIA roles like role="alert" for error messages [OK]

Common Mistakes:

• Ignoring ARIA roles for screen readers
• Removing interactive elements unnecessarily
• Relying only on visual styles for errors