`React.lazy` and `Suspense` are most useful when they reduce meaningful loading work without making the interface fragmented or unnecessarily complicated. ### 1. Lazy Load Heavy or Infrequently Used Features Good candidates include: ```text Admin pages Charts Code editors Rich text editors Large settings panels Rarely opened tools Large routes ``` For example: ```jsx const CodeEditor = lazy(() => import("./CodeEditor") ); ``` ### 2. Do Not Lazy Load Every Small Component Avoid creating a separate chunk for trivial UI such as: ```text Button Badge Logo Simple heading Small icon wrapper ``` The loading overhead can be greater than the benefit. ### 3. Place lazy Calls at Module Scope Correct: ```jsx const Editor = lazy(() => import("./Editor") ); function Page() { return ; } ``` Avoid: ```jsx function Page() { const Editor = lazy(() => import("./Editor") ); return ; } ``` Creating the lazy component while rendering can create unstable component identity and reset state. ### 4. Always Provide an Appropriate Suspense Boundary ```jsx }> ``` A lazy component needs an appropriate Suspense boundary somewhere above it. ### 5. Avoid One Global Spinner for Every Feature This architecture: ```jsx }> ``` may cause a small lazy feature to replace far more UI than necessary. Use boundaries that correspond to meaningful sections. ### 6. Avoid Too Many Tiny Boundaries The opposite extreme is also problematic: ```text Header spinner Button spinner Card spinner Label spinner Icon spinner ``` Loading UI can become visually unstable and confusing. ### 7. Use Useful Fallback UI Instead of always showing: ```jsx

``` consider a fallback matching the real layout: ```jsx }> ``` This can reduce layout movement and make the loading experience easier to understand. ### 8. Do Not Assume Suspense Fetches Data Suspense coordinates waiting UI. It does not automatically perform: ```text API calls Caching Retries Authentication Error handling ``` Those concerns belong to the compatible framework, data source, or application logic. ### 9. Handle Loading Errors Separately Suspense handles waiting, not every error condition. If a lazy-loaded [JavaScript](/courses/javascript) chunk fails to load, an error boundary can provide failure UI around that area. Conceptually: ```text Suspense → waiting state Error Boundary → error state ``` ### 10. Consider Prefetching for Likely Next Actions Lazy loading waits until code is needed, but sometimes the application can predict what the user is likely to open next. For example: ```text User hovers over Dashboard link → optionally begin loading dashboard code ``` Frameworks and build systems may provide preloading or prefetching mechanisms that improve navigation without forcing every chunk into the initial bundle. ### 11. Use Framework-Level Code Splitting When Appropriate If the application's router or framework already provides route-based code splitting, use its recommended mechanism rather than manually rebuilding the same architecture with many `lazy()` calls. ### Practical Decision Guide ```text Heavy feature not needed initially? → consider lazy loading Tiny component used immediately? → normal import Lazy child waiting? → Suspense boundary Whole section should load together? → one shared boundary Sections can appear independently? → separate meaningful boundaries Need waiting UI? → Suspense Need failure UI? → Error Boundary ``` ### Interview-Ready Answer Use `React.lazy` for meaningful code-splitting opportunities such as large routes or heavy features, declare lazy components outside rendering [functions](/javascript/functions-in-javascript), and place them inside appropriately scoped Suspense boundaries. Avoid both over-splitting and one giant global loading boundary. Suspense handles waiting UI, while errors require separate error-handling boundaries.