ReactJs Performance ~ Server-Side Rendering (SSR) and Static Generation ~
Source: Dev.to
SSR and Static Site Generation (SSG) shift page rendering from the client to the server, allowing users to receive pre-rendered HTML immediately. This approach significantly enhances loading speed, user experience, and search engine visibility. The browser first downloads JavaScript files JavaScript runs and generates the UI in the browser Users see content only after rendering completes Estimated load time: around 2–4 seconds The server generates complete HTML before sending it The browser can display content right away JavaScript then adds interactive functionality through hydration Estimated load time: around 0.5–1.5 seconds Pages are generated as static HTML during the build process Content is delivered instantly through a CDN JavaScript hydrates the page to enable interactions Estimated load time: around 0.2–0.8 seconds // pages/products/[id].js
// This function runs on the server each time the page is requested export async function getServerSideProps({ params }) { const product = await fetchProduct(params.id);
return { props: { product, }, }; }
// The component receives product data before the page is rendered export default function ProductPage({ product }) { return (
{product.name}
{product.description}
Add to Cart
); }
// pages/blog/[slug].js
// This function executes during the build process export async function getStaticPaths() { const posts = await fetchAllPosts();
return { paths: posts.map((post) => ({ params: { slug: post.slug }, })), fallback: “blocking”, // Generate pages dynamically when needed }; }
// Fetch data and generate static pages ahead of time export async function getStaticProps({ params }) { const post = await fetchPost(params.slug);
return { props: { post, }, revalidate: 3600, // Refresh the page every hour }; }
// The page is served as pre-rendered HTML export default function BlogPost({ post }) { return (
{post.title}
); }
Rendering Strategy Performance
| Rendering Strategy | Initial Server Response | First Visual Display | Fully Usable State | SEO Performance | Best Fit |
|---|---|---|---|---|---|
| CSR (Client-Side Rendering) | Around 100–200ms | Usually 2–4 seconds | Around 2.5–5 seconds | Weak for search engines | Apps that require authentication or heavy client-side interaction |
| SSR (Server-Side Rendering) | Around 200–500ms | Roughly 0.5–1.5 seconds | About 1–2.5 seconds | Very strong | Frequently updated pages and dynamic data |
| SSG (Static Site Generation) | Around 50–100ms | Roughly 0.2–0.8 seconds | Around 0.5–1.5 seconds | Excellent | Fully static websites and landing pages |
| ISR (Incremental Static Regeneration) | Around 50–150ms | Roughly 0.2–1 second | Around 0.5–1.8 seconds | Excellent | Pages that are mostly static but occasionally updated |
| Partial Hydration | Around 50–150ms | Roughly 0.2–0.8 seconds | Around 0.3–1.2 seconds | Excellent | Applications combining static and interactive sections |
Incremental Static Regeneration (ISR)
ISR combines the speed of static generation with the flexibility of dynamic updates. Pages are pre-rendered as static HTML, but they can be regenerated automatically after a specified interval.
javascript return {
After the revalidation period expires, the first visitor triggers a background regeneration process. That user still receives the existing cached page while the updated version is being rebuilt. Once regeneration finishes, future visitors receive the newly updated page.
This approach provides the speed advantages of static pages while still keeping content regularly updated.
Popular frameworks that support SSR and SSG include Next.js, Remix, Gatsby, and Astro. Although each framework has its own rendering strategy and optimization techniques, all aim to improve initial page loading performance compared to traditional Client-Side Rendering (CSR).
For content-focused websites, SSG can reduce loading times by roughly 60–80% compared to CSR. In highly dynamic applications, SSR often improves perceived performance by around 40–60%. However, these benefits usually come with additional server complexity and potentially higher infrastructure costs.
Implementation Roadmap Rolling out all 15 optimizations at once overwhelms teams. Here’s a practical implementation sequence based on effort vs. impact:
Phase 1 - Quick Wins (Week 1-2):
-Enable React Compiler (automatic memoization) -Implement route-based code splitting -Add image optimization and lazy loading -Configure bundle analyzer
Phase 2 - Foundation (Week 3-4):
-Optimize state management (switch to Zustand if using Context) -Implement virtualization for large lists -Set up performance monitoring -Add database query optimization
Phase 3 - Advanced (Week 5-8):
-Implement tree shaking and bundle optimization -Add PWA capabilities with service workers -Optimize CSS and defer third-party scripts -Implement memory leak prevention
Phase 4 - Architecture (Week 9-12):
-Move to SSR/SSG where appropriate -Implement Web Workers for heavy computations -Full performance audit and tuning
Frontend Optimization Priorities
| Optimization | Effort | Impact | Priority | Prerequisites |
|---|---|---|---|---|
| React Compiler | Low | Very High | 1 | React 19+ |
| Code splitting | Low | Very High | 1 | None |
| Image optimization | Low | High | 1 | None |
| State management | Medium | Very High | 2 | Architecture review |
| Virtualization | Medium | High | 2 | Large lists identified |
| Performance monitoring | Low | High | 2 | Analytics setup |
| Database optimization | Medium | Very High | 2 | Backend access |
| Bundle analysis | Low | High | 3 | Build pipeline |
| PWA features | Medium | Medium | 3 | Service worker knowledge |
| CSS optimization | Medium | Medium | 3 | CSS audit |
| Third-party optimization | Low | High | 3 | Script inventory |
| Memory leak prevention | Medium | Medium | 4 | Development practices |
| Web Workers | High | Medium | 4 | Heavy computation identified |
| SSR/SSG | Very High | Very High | 4 | Framework migration |