Introduction
NoSsr purposely removes components from the subject of Server Side Rendering (SSR). This component can be useful in various situations where you want content to render only on the client side.Basic Usage
Props
children
- Type:
React.ReactNode - Default:
undefined
defer
- Type:
boolean - Default:
false
true, the component will not only prevent server-side rendering. It will also defer the rendering of the children into a different screen frame.
fallback
- Type:
React.ReactNode - Default:
null
Use Cases
1. Escape Hatch for Broken Dependencies
Some third-party libraries don’t support SSR. You can wrap them with NoSsr:2. Improve Time-to-First Paint
Render only above-the-fold content on the server:3. Reduce Server Load
Skip expensive components during SSR:4. Service Degradation
Under heavy server load, you can turn on service degradation:Deferred Rendering
Thedefer prop delays rendering until the next frame, which can help with perceived performance:
Fallback Content
Provide fallback content that shows during SSR and before client hydration:Client-Only Features
Use NoSsr for features that only make sense on the client:Browser-Specific APIs
Wrap components that use browser-only APIs:Working with Next.js
NoSsr works seamlessly with Next.js:Performance Considerations
When to Use NoSsr
- Third-party components that break SSR
- Components using browser-only APIs
- Below-the-fold content
- Heavy components that slow down SSR
When NOT to Use NoSsr
- Critical above-the-fold content
- SEO-important content
- Content needed for initial page load
- Components that work fine with SSR
Comparison with useEffect
NoSsr is similar to usinguseEffect with an empty dependency array, but provides better fallback support:
Best Practices
- Always provide fallback: Use the
fallbackprop for better UX - Avoid overuse: Only use NoSsr when necessary
- Consider SEO: Don’t wrap SEO-critical content
- Progressive enhancement: Ensure core functionality works without JavaScript
- Monitor performance: Use defer for heavy components