How do you configure a route for lazy loading?

What's really being asked

This question tests whether you can design for performance at the architecture level rather than just writing components. Interviewers want to see that you understand how modern bundlers split code at route boundaries and how router configuration triggers those splits. They also care if you can explain the user impact in concrete terms like time-to-interactive and initial transfer size.

The full answer

A good answer hits four things in order. First, it states that lazy loaded routes are configured by using dynamic imports inside the route definition instead of statically importing the component or module at the top of the router file. Second, it explains that this causes the build tool to emit a separate JavaScript chunk for that route which is only fetched when the user first navigates to the path. Third, it quantifies the benefit by contrasting an eager loaded SPA where every page ships in the initial bundle with a lazy loaded one where the user downloads perhaps fifty to one hundred kilobytes for the shell and then pulls additional chunks on demand. Fourth, it notes that this is critical for large applications because initial bundle size directly correlates with parse and compile time on mobile devices, so route splitting is often the single biggest performance win.

The mistakes people make

A common wrong answer focuses on deferring offscreen images or using the loading attribute on img tags, which is a different optimization. Another red flag is saying lazy loading is automatic or handled by the framework without mentioning dynamic imports or route configuration. Some candidates also claim it reduces server load, but the real win is reducing initial download and main thread work on the client.

What usually comes next

An interviewer might ask how you would handle preloading critical routes or how to avoid a waterfall when nested routes are lazy loaded. They could also ask about error boundaries if a dynamic import fails, or how to measure the before and after with Lighthouse or Webpack Bundle Analyzer.

A concrete example

Imagine an e-commerce admin dashboard with ten distinct sections such as orders, inventory, and analytics. Without lazy loading, the user downloads one megabyte of JavaScript on first visit even if they only check orders that day. With route lazy loading, the initial load might drop to one hundred fifty kilobytes for the layout and shared code, and each admin section loads an additional sixty to one hundred kilobytes only when visited. This keeps the app booting in under one second on mid-tier mobile instead of four or five seconds.