DEV Community: Md Enayetur Rahman

Optimize Loading Sequence (Part 2)

Md Enayetur Rahman — Sat, 13 Dec 2025 09:55:12 +0000

#LearningPatterns52 | Based on “Learning Patterns” (v1.1) by Lydia Hallie & Addy Osmani

This article continues the Optimize Loading Sequence pattern. Part 1 covered why sequencing is hard and which metrics matter. Here in Part 2 we move from diagnosis ➜ prescription.

Introduction

The book frames loading as a queue‐management problem: which byte hits the wire first, and why?

The browser already has heuristics, but you — not the network stack — know what the user must see & use first.

Your job: override defaults with hints that pull critical assets forward and push distractions back.

1 · Critical CSS

Learning Patterns defines critical CSS as the minimal style‑set required to paint above‑the‑fold content.

The recommended flow:

Inline ≤ 15 KB of critical rules in the <head>
Mark the remainder with rel="preload" & as="style"
Defer non‑render‑blocking styles via media="print" → onload swap

The book’s Lighthouse trace shows a 31 % LCP improvement simply by isolating 5.8 KB of hero styles.

2 · Fonts

Fonts block text render. The pattern suggests:

preload the most‑used weight (woff2)
Combine font-display: swap plus a 3 s FOIT timeout
Scope icon fonts to subsets or shift them to SVG sprites

Example: a P75 mobile session saw CLS drop from 0.23 ➜ 0.04 after the fallback/swap approach.

3 · Images

Above‑the‑Fold

Learning Patterns advises:

Step	Tactic
1	Use a low‑quality placeholder (`lqip`, SVG blur)
2	Send the hero via `fetchpriority="high"` or HTTP/2 push
3	Serve modern formats (AVIF, WebP)

Below‑the‑Fold

Mark with loading="lazy" and, if bandwidth is tight, wrap in an IntersectionObserver to delay even the request creation.

4 · Scripts

First‑Party JS

Split: isolate hydration logic required for the initial route
Defer modules that act post‑interactive
Move expensive polyfills behind feature detection

Third‑Party JS

The authors label them “performance dark matter.” Recommendations:

Convert blocking <script> tags to async or delayed import
Stub APIs until after TTI (e.g., push calls into a queue)
Load via a single proxy host to reuse TCP/QUIC connections

5 · How Chrome Prioritises Resources (Book Table)

Priority Bucket	Examples	TLS Handshake?	Queue Age Limit
Highest	In‑document CSS, critical `preload`	Yes	Immediate
High	Images with `fetchpriority="high"`; JS in `<head>`	Yes	5 round‑trips
Medium	Deferred/async scripts; fonts	If needed	10 round‑trips
Low	Lazy images, `rel="prefetch"`	If idle	Infinite
Lowest	`rel="prerender"`	Only when idle	Infinite

(Table reproduced from *Learning Patterns, ch. “Optimize Loading Sequence”)*

6 · Case Study — Next.js SSR (Before Optimisation)

“Even modern SSR frameworks can ship bytes in the wrong order.” — Learning Patterns

Default Sequence

1. _app.js (159 KB)       ← blocking
2. vendors.js (321 KB)    ← blocking
3. route page.js (71 KB)
4. main.css (34 KB)
5. hero.jpg (1.2 MB)
6. webfont.woff2 (96 KB)

Impact:

LCP (mobile): 4.8 s
TBT: 620 ms (main thread busy parsing JS)
CLS: 0.19 (font & image late)

The book’s flame chart shows the browser idle for 200 ms waiting on main.css that arrived after two big JS bundles.

7 · Proposed Sequence (No 3rd‑Party)

1. critical.css (inline)                    ← paints header
2. hero.jpg?width=560&format=avif          ← fetched with fetchpriority=high
3. font.woff2 (preload)                    ← text remains stable
4. route page.js (hydration + suspense)
5. vendors.js (chunked + deferred)
6. rest.css (preloaded; onload rel=stylesheet)

Reasons

Inline critical CSS unblocks first paint.
Hero image early fetch secures LCP.
Font preload prevents FOUT/CLS.
Code‑split hydration chunk cuts TBT by trimming unused routes.

8 · Proposed Sequence (With 3rd‑Party)

1‒4. Same as above
5. stub-analytics.js (1 KB inline)          ← captures events in queue
6. thirdparty.js (async, after load)         ← executes post‑TTI
7. chat-widget.css (preload, media=print)   ← swapped on scroll

Reasons

A 1 KB stub guarantees data isn’t lost but doesn’t block painting.
Full analytics, A/B test, or chat scripts run after TTI, avoiding TBT spikes.
Widget styles load off‑screen, so they’re quarantined from first paint.

Conclusion

Learning Patterns’ big takeaway: ordering beats bandwidth.

By nudging the browser’s queue, you can often shave >30 % off LCP without new servers or CDNs.

Happy shipping! 🚀

All figures & workflow steps are reproduced or summarised from “Learning Patterns” (v1.1).

Optimize Loading Sequence (Part 1) – Metrics & Challenges

Md Enayetur Rahman — Sat, 13 Dec 2025 09:53:41 +0000

Series: #LearningPatterns51 | Based on “Learning Patterns” by Lydia Hallie & Addy Osmani

Why Loading Sequence Matters
Key Metrics to Track
Why True Optimization Is Tricky
- 1 · Sub‑optimal Sequencing
- 2 · Network & CPU Utilization
- 3 · Third‑Party Products
- 4 · Platform Quirks
- 5 · HTTP/2 Prioritization Pitfalls
- 6 · Resource‑Level Optimization Gaps
Conclusion

Why Loading Sequence Matters

The Loading Sequence pattern in Learning Patterns reminds us that a page’s perceived speed depends less on raw bandwidth and more on which bytes arrive first. Smart sequencing lets users interact sooner and search engines rank us higher.

Key Metrics to Track

Metric	What It Measures	Why It Matters
TTFB (Time To First Byte)	Server → client latency before first byte	Shows back‑end speed & CDN reach
FCP (First Contentful Paint)	When any DOM content paints	First visual feedback
LCP (Largest Contentful Paint)	Render time of the hero element	Core Web Vitals ranking signal
TBT (Total Blocking Time)	Main‑thread blocking between FCP & TTI	CPU hogs that delay interactivity
CLS (Cumulative Layout Shift)	Unexpected layout movement	UX stability, ad/script impacts
Speed Index	Visual completeness over time	Overall perceived speed

The book recommends baselining at least FCP, LCP, and TBT before optimizing so you can verify real‑world wins.

Why True Optimization Is Tricky

1 · Sub‑optimal Sequencing

Even small order mistakes—e.g. loading a carousel script before the CSS that hides its overflow—force the browser to repaint.

Example: A hero image <img> lazy‑loaded after below‑the‑fold ads can push LCP > 3 s. Fix by preloading the hero image and deferring ad scripts.

2 · Network & CPU Utilization

High‑end dev machines rarely replicate mid‑tier phone realities. Mobile radios add ~300 ms RTT and CPUs throttle under thermal limits.

Example: A bundle that gzips to 150 kB may parse/run in 40 ms on desktop but 250 ms on a Moto G—enough to spike TBT.

3 · Third‑Party Products

Analytics, ads, chat widgets — the “unbudgeted bytes” of every sprint. They often ship un‑minified or run expensive polling loops.

Example: One AB‑testing SDK injected 17 extra <script> tags, delaying FCP by 800 ms. The book suggests “performance budgets per supplier” and using async defer by default.

4 · Platform Quirks

Browsers implement standards differently. Safari blocks font preloads older than 2 weeks in cache; Chrome preload scanner ignores media predicates.

Example: An @font-face swap that’s near‑instant in Chrome flashes unstyled text (FOUT) in Firefox because of its font‑loading timeout heuristic.

5 · HTTP/2 Prioritization Pitfalls

HTTP/2 multiplexes requests, but priority inheritance varies by server. If your hero image is listed after a 1 MB analytics JSON, it can still starve.

Example: Switching from Apache to nghttpx with correct weight settings cut LCP from 4.1 s to 2.3 s in the book’s case study.

6 · Resource‑Level Optimization Gaps

Image compression, SVG clean‑up, tree‑shaking — each resource has its own optimal path. Miss one and you give back hard‑won gains.

Example: A React app that treeshook but forgot to strip moment.js locales shipped +280 kB of unused data.

Conclusion

Optimizing loading isn’t a one‑time tweak; it’s a cross‑discipline negotiation between design, back‑end, DevOps, and third‑party vendors. Part 1 laid out what to measure and why perfection is elusive.

In Part 2 we’ll dive into prescriptive techniques: critical CSS extraction, priority hints, server push best practices, and more.

Inspired by the Loading Sequence insights from **Learning Patterns* by Lydia Hallie & Addy Osmani.*

Islands Architecture in Practice – A Deep Dive

Md Enayetur Rahman — Sat, 13 Dec 2025 09:41:25 +0000

#LearningPatterns50 | Based on “Learning Patterns” by Lydia Hallie & Addy Osmani

Table of Contents
What Sparked Islands Architecture?
Islands of Dynamic Components Explained
Implementing Islands — The Core Mechanics
Ecosystem & Framework Support
DIY: A Minimal Islands Implementation
- 1 · Install Astro
- 2 · Create an Island Component (src/components/Counter.jsx)
- 3 · Use the Island in a Page (src/pages/index.astro)
- Vanilla Roll‑Your‑Own (Optional)
Pros & Cons
Conclusion

What Sparked Islands Architecture?

Single‑Page Applications (SPAs) gave us fluid UX but at a heavy cost: large JS bundles, hydration delays, and poor first‑page performance. Islands Architecture emerged as a middle path:

MPA ergonomics – ship mostly static HTML for fast TTFB and reliable SEO.
Targeted interactivity – hydrate only the parts that need it, shrinking JS and CPU usage.

The term was popularized by Addy Osmani’s 2019 post “The Cost Of JavaScript Frameworks” and later formalized in Learning Patterns.

Islands of Dynamic Components Explained

An island is a self‑contained, interactive component surrounded by inert, static HTML (the “ocean”).

+--------------------------------------------------------+
|             Static hero section (pure HTML)            |
|  +-----------------------------------------------+     |
|  |  <SearchBox/>   ← interactive island (hydrated) |   |
|  +-----------------------------------------------+     |
|      Static marketing copy (no client JS)            |
|  +-----------------------------------------------+     |
|  |  <SubscribeForm/>  ← another island             |   |
|  +-----------------------------------------------+     |
+--------------------------------------------------------+

Only the SearchBox and SubscribeForm download/execute JS; everything else remains lightweight markup.

Implementing Islands — The Core Mechanics

Server renders full HTML for the page.
Interactive components embed a tiny marker (e.g. data-island="ComponentName") plus their serialized props.
On the client, a micro‑runtime scans the DOM, lazy‑loads each component bundle, and mounts it into its placeholder.
Each island runs in isolation; no global SPA router required.

This is essentially partial hydration.

Ecosystem & Framework Support

Framework	Islands Support	Notes
Astro	✅ Built‑in (`client:only`, `client:visible`, etc.)	Zero JS by default
Qwik	✅ Resumability + island hydration (`q:scoped`)	Ultra‑deferred execution
Slinkity	✅ Islands on top of Eleventy	Great for static sites
Marko 6	✅ Streaming islands (`<client>` tag)	Hydrates only when needed
Fresh (Deno)	✅ Per‑component islands	Runs on Deno Deploy

DIY: A Minimal Islands Implementation

Below is a tiny proof‑of‑concept with Astro.

1 · Install Astro

npm create astro@latest my‑islands‑demo
cd my‑islands‑demo && npm i

2 · Create an Island Component (`src/components/Counter.jsx`)

import { useState } from "react";

export default function Counter({ initial = 0 }) {
  const [count, setCount] = useState(initial);
  return (
    <button
      className="px-3 py-2 rounded bg-blue-600 text-white"
      onClick={() => setCount(c => c + 1)}
    >
      Count: {count}
    </button>
  );
}

3 · Use the Island in a Page (`src/pages/index.astro`)

---
import Counter from "../components/Counter.jsx";
---

<html lang="en">
  <body>
    <h1>Islands Demo</h1>

    <!-- 👇 Hydrate this component only when it becomes visible -->
    <Counter client:visible initial={5} />

    <p>No other JS was shipped!</p>
  </body>
</html>

Run npm run dev and inspect the network tab—only ~1 KB of JS for the counter.

Vanilla Roll‑Your‑Own (Optional)

If you can’t switch frameworks, you can sprinkle islands into any SSR stack:

<!-- server‑rendered -->
<div id="search" data-props='{"term": ""}'></div>
<script type="module">
  import SearchBox from "/static/search.js";
  const el   = document.getElementById("search");
  const props = JSON.parse(el.dataset.props);
  SearchBox.mount(el, props);      // your own mini runtime
</script>

Pros & Cons

✅ Pros	❌ Cons
Lower JS payloads – only hydrate what’s necessary.	Mental model shift – designers/devs must think in islands.
Great Core Web Vitals – faster FCP, TTI.	State sharing between islands can be tricky (requires events or server).
Progressive enhancement out of the box.	Tooling lock‑in if you lean on a specific island framework.
SEO‑friendly – full HTML delivered up front.	Not a silver bullet for highly interactive dashboards (might still need SPA techniques).

Conclusion

Islands Architecture re‑balances the SPA/MPA spectrum: deliver static HTML for speed, sprinkle interactivity where it actually adds value. Frameworks such as Astro and Qwik automate the heavy lifting, but you can experiment with your own mini‑runtime today.

If your next project is content‑heavy with just a few interactive widgets, give islands a try—you might never look back at full‑page hydration.

Happy shipping, and see you in the next pattern! 🚀

Optimizing Core Web Vitals in the Next.js Movies App – A Full Playbook

Md Enayetur Rahman — Sat, 13 Dec 2025 09:39:11 +0000

#LearningPatterns49 | Source: “Learning Patterns” by Lydia Hallie & Addy Osmani

Why Core Web Vitals?
Benchmark: Next.js Movies
Cumulative Results
Optimization Checklist – 11 Changes
Conclusion & Key Take‑aways

Why Core Web Vitals?

Google’s Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) map directly to perceived speed, responsiveness and stability. The authors dedicated an entire chapter to showing how to move each metric into the “good” range without crippling DX.

Benchmark: Next.js Movies

The team built a fully‑featured movie‑browser powered by the TMDB API—search, filter, favorites, server‑side rendering and authentication—to mimic a real‑world SPA. All experiments below were run against that code‑base.

Cumulative Results

Metric (average across pages)	Before	After	Δ
LCP	3.43 s	2.86 s	−16 %
INP (TBT proxy)	60 ms	20 ms	−67 %
Speed Index	4.2 s	3.5 s	−17 %
Lighthouse Perf	88 %	94 %	+6 pts

Table reproduced from the book’s “Cumulative Improvements” section.

Optimization Checklist – 11 Changes

#	Category	What changed	Why it helps	Key gain
1	Trim heavy deps	Font‑Awesome → `@svgr/webpack`; `react-burger-menu` → custom; `react-select` → `react-select-search`; `react-slick` → `react-glider`; `react-rating` → `react-stars`; native smooth‑scroll polyfill → `react-scroll`	Removes KBs and main‑thread work	LCP −23 %, TBT −51 % (SVG swap)【0†L55-L65】
2	Code‑split UI chrome	Sidebar & comments wrapped in `React.lazy` + `Suspense`	Sends less JS on critical path	TBT −71 %【2†L5-L9】【2†L20-L27】
3	Inline critical CSS, defer the rest	Moved node‑module CSS out of `_app.js`; in‑lined dark/light‑mode CSS	Unblocks rendering, lowers FCP/LCP	2‑5 % faster LCP/TTI【4†L9-L18】【4†L37-L38】
4	Fix CLS completely	Adopted aspect‑ratio boxes for posters	Reserves space before images load	CLS → 0【3†L14-L18】【3†L21-L22】
5	Preconnect origins	TMDB image & API domains	Warms DNS/TLS early	Small but measurable FCP/Speed Index drop【3†L30-L36】【3†L38-L40】
6	Re‑order API calls	Metadata & poster calls run in parallel	Main content arrives sooner	LCP −16 %, Perf +5 pts【3†L43-L50】【3†L65-L70】
7	Preload predictable API response	First‑visit “Popular movies – page 1” fetched during HTML parse	Eliminates post‑render spinner	LCP −12.6 %, TTI −7.8 %【7†L73-L79】【7†L77-L79】
8	Preload logo & trademark	Added media‑conditioned `<link preload>`	Improves repeated nav	FCP & Speed Index −5‑6 %【7†L81-L88】【7†L89-L90】
9	Make SSR responsive	Used `@artsy/fresnel` so server renders all break‑points, client only hydrates one	Reduces JS & CSS per viewport	Faster Speed Index; no functionality loss【7†L91-L96】
10	Lazy‑load carousel CSS	In‑lined Glider styles only on pages that need them	Cuts render‑blocking CSS	Page Perf +2 pts【4†L28-L31】【4†L37-L38】
11	Review loading sequence	Followed Aurora team’s ideal ordering for CSS, fonts, JS, images	Systematic CWV protection	Framework for future regressions【1†L15-L23】【10†L91-L100】

Conclusion & Key Take‑aways

Swap, don’t just tweak: Replacing a whole dependency can deliver outsized wins.
Sequence matters: Critical data and assets must arrive first; speed without order still hurts LCP.
Measure every change: The team ran Lighthouse & WebPageTest after each tweak to avoid regression noise.
Zero CLS is achievable: Reserving space (aspect‑ratio boxes / next/image) is usually enough.
Performance is iterative: These 11 optimizations built on one another—no single silver bullet.

“Excellent user experience translates to passing Core Web Vitals.” — Learning Patterns

Happy optimizing! 🚀

Selective vs Progressive Hydration

Md Enayetur Rahman — Sat, 13 Dec 2025 09:36:59 +0000

Hydration is the moment a server‑rendered React tree becomes interactive in the browser. Two patterns help us ship less JS and unblock the main thread:

Progressive Hydration – hydrate over time.
Selective Hydration – hydrate what matters first.

Progressive Hydration

Progressive hydration defers work until a component actually needs to be interactive—for example when it scrolls into view. Instead of hydrating the whole page at once, we hydrate in slices, scheduling each slice when the browser is idle or a trigger fires. This spreads CPU cost and reduces the Time‑to‑Interactive (TTI).

Simplified Example

// Hydrator.js
import { hydrateRoot } from "react-dom/client";

export function hydrateWhenVisible(id) {
  const el = document.getElementById(id);
  if (!el) return;

  // Only hydrate once the element is in the viewport
  const io = new IntersectionObserver(([entry]) => {
    if (entry.isIntersecting) {
      hydrateRoot(el, <App />);
      io.disconnect();
    }
  });
  io.observe(el);
}

<!-- index.html -->
<div id="users" data-hydrate="visible">
  <!-- SSR'ed markup for <Users /> -->
</div>

<script type="module">
  import { hydrateWhenVisible } from "/Hydrator.js";
  hydrateWhenVisible("users");
</script>

The Users list stays HTML‑only until the user scrolls to it, then we mount React.

Selective Hydration

Selective hydration arrived with React 18+ streaming SSR. When React streams HTML, it can immediately hydrate chunks that have already arrived, without waiting for the entire page. Even better, if the user interacts with an already‑rendered—but not yet hydrated—portion, React prioritizes that slice.

Simplified Example

// server.jsx
import { renderToPipeableStream } from "react-dom/server";
import express from "express";

const app = express();

app.get("/", (req, res) => {
  const { pipe } = renderToPipeableStream(
    <App />,
    {
      onAllReady() {
        res.setHeader("Content-Type", "text/html");
        pipe(res);
      },
    }
  );
});

// client.jsx streamed chunk
<Suspense fallback={<Spinner />}>
  <Comments />   {/* arrives later */}
</Suspense>

If the user taps inside <Comments> before its JS arrives, React hydrates that subtree first, keeping the interaction snappy.

Pros & Cons

Pattern	Pros	Cons
Progressive	• Defers JS & CPU • Excellent for below‑the‑fold content • Works in React ≤17 with small libs	• Manual; you must decide triggers • First interaction may still load JS • Multiple idle callbacks can complicate state sync
Selective	• Automatic priority on user interaction • Plays well with streaming SSR/Suspense • Reduces main‑thread blocking for critical UI	• React 18+ only • Needs streaming infra (Node & CDN that supports `flush()`) • Debugging hydration order can be tricky

When to Use What?

Use Progressive Hydration if you have large, non‑critical widgets (maps, big lists, ads) and you’re on a React version before 18 or can’t stream HTML.
Use Selective Hydration if you already stream with React 18+ and want React to automatically prioritize interactivity.

Conclusion

Both patterns share a goal: ship less JavaScript upfront and make real user interactions faster.

Progressive hydration lets you orchestrate hydration.
Selective hydration lets React orchestrate hydration based on what the user does.

Mix‑and‑match: you can progressively hydrate low‑priority widgets while React selectively hydrates streamed chunks. The result is a faster, more resilient UX—exactly what modern users (and Core Web Vitals) demand.

Beyond SSR: Demystifying React Server Components for Real‑World Apps

Md Enayetur Rahman — Sat, 13 Dec 2025 09:34:40 +0000

Inspired by the insights in Lydia Hallie & Addy Osmani’s Learning Patterns.

Why look beyond classic SSR?

Server‑side rendering (SSR) was a game‑changer for the initial performance of React apps. But as applications grew, teams hit a few pain points:

Bundle duplication – The same components get shipped to both server and client.
Hydration costs – After HTML is streamed, the browser must download JavaScript, parse it, and re‑attach event listeners.
Tight data -- UI coupling – Fetching data inside getServerSideProps (or equivalent) forces full‑page reloads when only a section needed updating.
Limited in‑flight streaming – You can send HTML early, but JavaScript for large chunks often arrives all at once.

React Server Components (RSC) aim to address these issues while preserving React’s developer experience.

What is a Server Component?

A server component is rendered only on the server. It never appears in the client bundle, so there is zero JavaScript cost for that component in the browser.

// app/page.tsx   (Next.js 14+)
import ProductList from "./ProductList"; // ✅ server component

export default async function Page() {{
  const products = await fetchProducts(); // runs on the server
  return (
    <main className="p-6">
      <h1 className="text-3xl font-semibold mb-4">Our catalog</h1>
      {/* ProductList is rendered on the server; 
          the HTML is streamed to the client. */}
      <ProductList products={{products}} />
    </main>
  );
}}

Key characteristics

Can await database or API calls directly.
Output is HTML only; no client‑side JS bundle.
Can render client components as children (marked with "use client").

Automatic Code Splitting (RSC vs. `React.lazy()`)

Traditional React relies on dynamic import patterns:

// Before
import React, {{ lazy, Suspense }} from "react";
const HeavyChart = lazy(() => import("./HeavyChart"));

export function Dashboard() {{
  return (
    <Suspense fallback={{<Spinner/>}}>
      <HeavyChart />
    </Suspense>
  );
}}

With Server Components, React performs tree‑shaking on the server:

// After – HeavyChart is a Server Component
// It is excluded from the client bundle automatically.
import HeavyChart from "./HeavyChart"; // no 'lazy' needed

export function Dashboard() {{
  return (
    <>
      <Summary />
      <HeavyChart /> {/* streamed as HTML; zero JS sent */}
    </>
  );
}}

Because HeavyChart never reaches the browser, code splitting becomes implicit—React ships only the minimal JS required for interactive parts.

SSR vs. Server Components — at a glance

Capability	Classic SSR	React Server Components
Eliminates client JS for non‑interactive UI	❌ No (hydration needed)	✅ Yes
Can access secure server resources during render	✅ Yes	✅ Yes
Partial streaming without extra bundling config	🚧 Limited	✅ Built‑in
Requires hydration cost in the browser	✅ Always	⚠️ Only for client components
Works with existing `useEffect`, DOM APIs	✅ Yes	⚠️ Only inside client components
Ships duplicate logic (server + client)	✅ Often	❌ Never for pure server components

Putting it together

Server Components complement — not replace — SSR:

SSR is still useful for the shell of your page and for client components that need early HTML.
RSC lets you push heavy, non‑interactive work entirely to the server, trimming bundles and hydration time.

In practice you’ll mix them:

// 'layout.tsx' is a server component by default
import "@/styles/globals.css";
import {{ Suspense }} from "react";

export default function RootLayout({{ children }}) {{
  return (
    <html>
      <body>
        <NavBar />              {/* client component */}
        <Suspense fallback={{<Skeleton/>}}>
          {{children}}           {/* could include server + client parts */}
        </Suspense>
      </body>
    </html>
  );
}}

Conclusion

React Server Components let you scale UX and codebases without punishing runtime performance:

Smaller client bundles – ship less JavaScript.
Faster TTI – fewer hydration bytes, more streaming.
Simpler data fetching – await directly in components.
Automatic code splitting – implicit through server‑only execution.

As teams iterate, learning when to choose a client vs. server boundary becomes the new architecture art. Learning Patterns reminds us that patterns evolve; RSC is the natural next turn in React’s performance playbook.

Happy hacking—see you in the diff!

Streaming Server‑Side Rendering in React: A Learning Patterns Deep Dive

Md Enayetur Rahman — Sat, 13 Dec 2025 09:32:20 +0000

Streaming Server‑Side Rendering in React: A Learning Patterns Deep Dive
- Table of Contents
- What Is Streaming Server‑Side Rendering?
- Why Streaming?
- How React Implements Streaming
- Code Example – Express + React 18
- Three Takeaways
- Pros & Cons
- Conclusion

What Is Streaming Server‑Side Rendering?

Traditional server‑side rendering (SSR) waits until the entire HTML for a page is ready before sending it to the browser. Streaming SSR, by contrast, sends chunks of HTML as soon as they are generated.

This allows the browser to start parsing, painting, and hydrating the parts of the UI that are ready, improving Time to First Byte (TTFB) and Largest Contentful Paint (LCP).

Why Streaming?

From Learning Patterns:

Progressive Perceived Performance – users see something sooner, even on slow networks.
Reduced Blocking – slow data fetching or expensive computations in one part of the tree no longer block the entire document.
Back‑pressure Friendly – servers can push bytes as they become available, smoothing CPU spikes.

How React Implements Streaming

React 18 introduced two APIs inside react-dom/server:

API	Environment	Description
`renderToPipeableStream()`	Node.js (streams)	Emits HTML chunks into a Node Writable (e.g., an HTTP response).
`renderToReadableStream()`	Edge runtimes / Deno	Emits a web `ReadableStream` for platforms like Cloudflare Workers.

Key concepts from the book:

Suspense Boundaries act as natural chunk boundaries.
Client‑Side Hydration still happens, but progressively (hydrateRoot).
Error Entrapment – errors inside a boundary stream a fallback instead of crashing the whole response.

Code Example – Express + React 18

Below is a minimal, production‑safe example that streams an app using renderToPipeableStream:

// server.ts
import express from "express";
import fs from "fs";
import { renderToPipeableStream } from "react-dom/server";
import App from "./App";
import React from "react";

const app = express();

app.get("*", (req, res) => {
  // Prepare HTML shell
  const { pipe } = renderToPipeableStream(<App url={{req.url}} />, {
    onShellReady() {
      // Set headers early for better streaming
      res.statusCode = 200;
      res.setHeader("Content-Type", "text/html");

      // Begin streaming!
      pipe(res);
    },
    onError(err) {
      console.error(err);
    },
  });

  // Abort the stream if the client disconnects
  res.on("close", () => pipe?.abort?.());
});

app.listen(3000, () =>
  console.log("➜  Server listening at http://localhost:3000 🚀")
);

// App.tsx
import React, { Suspense } from "react";
import { Router } from "./Router";

export default function App({ url }: { url: string }) {
  return (
    <Suspense fallback={<p>Loading…</p>}>
      <Router initialUrl={{url}} />
    </Suspense>
  );
}

Three Takeaways

onShellReady fires when the initial HTML shell is ready (no data).
Suspense fallbacks are sent immediately; React in the browser swaps them when data resolves.
Abort logic prevents resource leaks if the connection drops.

Pros & Cons

	Pros	Cons
Performance	Faster FCP & LCP; critical CSS/JS can stream early.	Extra bytes from multiple script tags and fallbacks.
User Perception	Immediate feedback reduces bounce rates.	Janky experience if fallbacks are poorly designed.
Scalability	Better CPU utilization under load; back‑pressure friendly.	Longer connections per request can hurt throughput on very chatty pages.
Developer DX	Works with Suspense; single render pass; minimal boilerplate.	More moving parts (streaming + hydration), dev tools still maturing.
SEO	Crawlers receive meaningful HTML sooner.	Some bots don’t execute JS; ensure critical markup is in the shell.

Conclusion

Streaming SSR equips React apps with a progressive rendering pipeline that can dramatically enhance real‑world performance, especially on slower networks.

However, like every pattern in Learning Patterns, it shines only when aligned with product constraints:

Use it when you have data bottlenecks or large above‑the‑fold payloads.
Think twice when your pages are mostly static, or when infrastructure limits long‑lived connections.

Experiment, measure, and iterate—bytes don’t lie. 🏎️

References

Hallie, Lydia & Osmani, Addy. “Learning Patterns.” Chapter “Streaming Server‑Side Rendering”.
React 18 RFC: "Selective Hydration & Streaming".

Progressive Hydration in React: Taming the Hydration Monster

Md Enayetur Rahman — Sat, 13 Dec 2025 09:29:19 +0000

Learning Patterns Deep‑Dive – Pattern 45

Based on “Learning Patterns” by Lydia Hallie & Addy Osmani

Progressive Hydration in React: Taming the Hydration Monster
- Table of Contents
- The Hydration Problem
- Why Traditional Hydration Breaks Down
- Meet Progressive Hydration
- How it Works
- Implementation Walk‑through
- Step 1 – Identify Hydration Boundaries
- Step 2 – Lazy‑load & Hydrate on Demand
- Step 3 – Scheduling with Concurrent Mode
- Step 4 – Bringing in React Server Components
- Pros & Cons
- ✅ Pros
- ❌ Cons
- Conclusion

The Hydration Problem

Server‑side rendering (SSR) sends a static HTML shell to the browser, then JavaScript “hydrates” it by attaching React’s event listeners and state.

While SSR improves First Contentful Paint (FCP), classic hydration still blocks the main thread:

Pain Point	Why it happens
⚙️ Long block on JS execution	All component bundles download & execute before the page becomes interactive.
💤 Slow Time‑to‑Interactive (TTI)	The entire app competes for the main thread at once.
🤯 Jank on low‑end devices	Big hydration tasks freeze scrolling & gestures.

Why Traditional Hydration Breaks Down

Monolithic – One huge hydration task, regardless of what the user actually sees.
Priority‑blind – A hidden accordion in the footer hydrates as early as the hero carousel.
Bandwidth‑heavy – JS for every route ships up front, wasting KBs on first paint.

Learning Patterns frames this as the “Hydration Bottleneck” and urges us to “treat hydration like we treat code‑splitting: progressively.”

Meet Progressive Hydration

Definition – Hydrate only the parts of the UI that matter **when* they matter.*

How it Works

Islands / Boundaries – Slice your markup into “islands” (interactive) and “static ocean” (just HTML+CSS).
Lazy Bundles – Each island ships its own JS chunk, deferred or preloaded.
Event Replay – User events captured before hydration are replayed once the island is ready.
Scheduler Integration – React 18’s startTransition() lets hydration yield to more urgent work.

⛵ Analogy: Instead of refitting the whole ship in dry‑dock, fix one deck at a time while the ship keeps sailing.

Implementation Walk‑through

Step 1 – Identify Hydration Boundaries

/* server.jsx – React 18 SSR */
import { Suspense } from "react";
import Footer from "./islands/Footer.client";   // interactive island
import Hero from "./islands/Hero.client";       // interactive island
import StaticTestimonials from "./components/StaticTestimonials"; // no JS

export default function App() {
  return (
    <>
      <Hero />
      <StaticTestimonials />
      <Footer />
    </>
  );
}

Files ending in .client compile into JS bundles.
Components without that suffix render as pure HTML.

Step 2 – Lazy‑load & Hydrate on Demand

// islands/Hero.client.jsx
"use client";
import { useEffect } from "react";

export default function Hero() {
  useEffect(() => {
    console.log("Hero island hydrated! 🚀");
  }, []);
  /* …interactive JSX… */
}

The server streams the markup right away; the JS for Hero downloads only when needed (e.g., via import() or HTTP/2 Push).

Step 3 – Scheduling with Concurrent Mode

import { startTransition } from "react";

function hydrateIsland(importFn) {
  startTransition(() => {
    importFn().then(({ default: Island }) => {
      ReactDOM.createRoot(container).render(<Island />);
    });
  });
}

startTransition tells React: “lower priority; keep the UI responsive.”
Hydration yields to user input, tackling islands when the thread is free.

Step 4 – Bringing in React Server Components

// app/page.server.jsx  (Next.js / React 18)
import ProductList from "./ProductList.server";

export default async function Page() {
  const products = await fetch("/api/products").then(r => r.json());
  return (
    <>
      {/* Renders on the server, zero JS sent */}
      <ProductList products={products} />

      {/* Hydrated client island for the cart */}
      <AddToCartButton />
    </>
  );
}

Server Components stream ready‑to‑use HTML; only truly interactive islands (e.g., AddToCartButton) ship JS and hydrate progressively.

Pros & Cons

✅ Pros

Faster TTI – Only critical islands block interactivity.
Lower JS Cost – Each page loads just enough code.
Graceful Degradation – Static parts work even if JS fails.
Main‑thread Friendly – Hydration tasks can yield via Concurrent Mode.

❌ Cons

Complex Build Setup – Need split pipelines for server vs client code.
Tooling Maturity – RSC & progressive hydration are still evolving.
Event Replay Edge Cases – Lost events if not buffered correctly.
Debugging Overhead – Mixed execution contexts (server/client) complicate tracing.

Conclusion

Progressive hydration flips the traditional SSR model on its head: hydrate what matters, when it matters.

With React 18’s Concurrent Mode and the emerging React Server Components architecture, you can ship lighter pages, stay responsive, and delight users—especially on slow networks and devices.

Takeaway: Start small. Convert a footer or sidebar into an island, measure TTI, then iterate. The performance gains compound quickly!

Happy hydrating! 💧

Incremental Static Generation (ISR) in Next.js: Freshness at Scale

Md Enayetur Rahman — Sat, 13 Dec 2025 09:26:48 +0000

Modern teams love Static Site Generation (SSG) for its speed and reliability. But as your site grows—and content changes frequently—pure SSG starts to hurt: builds get slow, pages go stale, and redeploys become bottlenecks. Incremental Static Generation (ISR) is the practical pattern that keeps static fast while making it fresh.

1) The problem with pure SSG

SSG pre-renders pages at build time and serves them from a CDN. That’s fantastic for performance but introduces a few pain points at scale:

Stale content: Once deployed, pages don’t update until the next build. News, pricing, stock, and listings drift out of date.
Long build times: Large sites require generating thousands of pages in a single build, slowing CI/CD.
All-or-nothing deployments: A tiny copy change requires a whole-site rebuild & redeploy.
Operational friction: Content teams depend on developer-triggered deploys to publish updates.

Goal: Keep static speed, reduce staleness, and decouple content updates from full redeploys.

2) How ISR solves it (mental model)

Incremental Static Regeneration (ISR) allows pages to be statically generated and regenerated after a configurable interval or on demand—without a full rebuild.

Serve static instantly from cache/CDN.
Revalidate the page in the background when it’s “too old” or when a change is pushed.
Next request gets the fresh page; failures keep the last good version.
Granular control: choose per-page timing or trigger updates per path or per data “tag”.

This follows a familiar pattern: cache + time/notification-based invalidation, analogous to stale‑while‑revalidate.

3) How ISR works under the hood (flow)

First request after build renders and caches the static HTML.
Subsequent requests are served from cache (fast).
When the page exceeds its revalidate window (e.g., 60s), a request triggers background regeneration.
If regeneration succeeds, the cache swaps in the fresh HTML atomically.
If regeneration fails, the old version remains (graceful degradation).

You control when this happens (time-based) and what gets refreshed (path- or tag-based on-demand revalidation).

4) Code: Pages Router (Next.js 12/13+)

a) Time-based revalidation with `getStaticProps`

// pages/products/[id].tsx
import { GetStaticPaths, GetStaticProps } from 'next';

export const getStaticPaths: GetStaticPaths = async () => {
  // Pre-render a subset; fall back for the rest
  const ids = await fetchFeaturedIds();
  return {
    paths: ids.map((id) => ({ params: { id } })),
    fallback: 'blocking', // or true (shows a fallback UI)
  };
};

export const getStaticProps: GetStaticProps = async ({ params }) => {
  const product = await fetchProduct(params!.id as string);
  if (!product) {
    return { notFound: true };
  }
  return {
    props: { product },
    // Re-generate this page in the background at most once per 60 seconds
    revalidate: 60,
  };
};

export default function ProductPage({ product }: { product: Product }) {
  return <ProductView product={product} />;
}

Notes

fallback: 'blocking' avoids a visible loading state for uncached paths.
revalidate: 60 means the page may be regenerated in the background at most once per 60 seconds after it becomes stale.

b) On-demand revalidation (Pages Router)

Create an API route that your CMS/webhook can call after content changes:

// pages/api/revalidate.ts
import type { NextApiRequest, NextApiResponse } from 'next';

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  // 1) Verify a secret to prevent abuse
  const secret = process.env.REVALIDATE_SECRET;
  if (req.query.secret !== secret) {
    return res.status(401).json({ message: 'Invalid token' });
  }

  try {
    const { path } = req.query;
    if (typeof path !== 'string') {
      return res.status(400).json({ message: 'Missing ?path=' });
    }

    // 2) Revalidate the given path
    await res.revalidate(path); // e.g., "/products/123"
    return res.json({ revalidated: true, path });
  } catch (err) {
    return res.status(500).json({ revalidated: false, error: (err as Error).message });
  }
}

How to use

Configure your CMS to hit /api/revalidate?secret=...&path=/products/123 after content updates.
Only the changed page refreshes—no redeploy required.

5) Code: App Router (Next.js 13/14+)

With the App Router, you can control revalidation per route or per fetch, and use tag‑based invalidation for powerful CMS workflows.

a) Time-based revalidation per route

// app/blog/[slug]/page.tsx
export const revalidate = 120; // seconds

import { getPostBySlug } from '@/lib/posts';

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPostBySlug(params.slug);
  if (!post) return notFound();
  return <Article post={post} />;
}

b) Time-based revalidation per fetch

// app/lib/data.ts
export async function getProducts() {
  const res = await fetch('https://api.example.com/products', {
    // Revalidate this fetch every 60s
    next: { revalidate: 60 },
  });
  return res.json();
}

c) Tag-based caching & revalidation (recommended for CMS-driven content)

Tag your fetches, then revalidate by tag when content changes:

// app/lib/data.ts
export async function getPost(slug: string) {
  const res = await fetch(`https://cms.example.com/posts/${slug}`, {
    next: { tags: ['posts', `post:${slug}`] },
  });
  return res.json();
}

Trigger revalidation by tag in a Route Handler:

// app/api/revalidate/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { revalidatePath, revalidateTag } from 'next/cache';

export async function POST(req: NextRequest) {
  const { secret, path, tag } = await req.json();
  if (secret !== process.env.REVALIDATE_SECRET) {
    return NextResponse.json({ message: 'Invalid token' }, { status: 401 });
  }

  if (tag) {
    await revalidateTag(tag);       // e.g., "posts" or `post:my-slug`
  }
  if (path) {
    await revalidatePath(path);     // e.g., "/blog/my-slug"
  }

  return NextResponse.json({ revalidated: true, path, tag });
}

Why tags?

Many pages share the same data (e.g., a “latest posts” list). Revalidating by tag refreshes every page that used that data—without hunting down each path.

6) Updating existing pages in practice

You have three primary strategies:

Time-based (hands-off): choose a sensible revalidate interval per page or per fetch.
Event-driven (precise): call /api/revalidate (Pages) or /api/revalidate (App Route) when CMS content changes.
Hybrid (safe default): short time-based windows + event-driven hooks for critical updates.

Example: CMS webhook → App Router

CMS publishes a post and issues POST /api/revalidate with { secret, tag: "posts" }.
All routes fetching with { next: { tags: ['posts'] } } refresh automatically on next request.
Editors see updates immediately; visitors get static speed.

7) Pros of ISR

Static-speed performance: Low TTFB from CDN/caches, great Core Web Vitals.
Freshness without redeploys: Background regeneration and on-demand invalidation keep content up to date.
Build-time wins: No need to pre-render every page; generate on first request and refresh incrementally.
Cost & scale: Less server work than full SSR on every request; avoids monolithic rebuilds.
Resilience: If regeneration fails, the last good page continues to serve.
SEO-friendly: Crawlable, stable HTML with timely updates.
Great with CMS: Tag-based revalidation maps cleanly to content models and editorial workflows.

8) Caveats & good practices

Highly personalized pages still need SSR or client-side rendering.
Very volatile data (e.g., live prices) may require shorter revalidate windows or SSR.
Atomic multi-page updates: prefer tag-based revalidation so related pages refresh together.
Fallback UX: if you use fallback: true, ensure a good loading skeleton for first render.
Error handling: log regeneration failures; consider alerting for critical pages.
Cache-awareness: understand your platform’s CDN and region behavior to avoid surprise staleness.

9) Conclusion

ISR gives you the best of both worlds: the speed and stability of static sites with the freshness of dynamic systems. Adopt a cache-first mindset: render statically, revalidate by time, and revalidate by event/tag when content changes. Start with conservative intervals (e.g., 60–120s), wire up CMS webhooks, and reach for SSR only when personalization or ultra-fresh data truly demands it.

TL;DR: Ship fast static pages. Keep them fresh—incrementally.

Quick Reference

Pages Router: getStaticProps + revalidate, res.revalidate(path)
App Router: export const revalidate, fetch(..., { next: { revalidate, tags } }), revalidatePath, revalidateTag
Good defaults: revalidate: 60–300 for listings; on-demand for critical content

Static Rendering (SSG) in React: From Classic Builds to Data‑Driven Pages

Md Enayetur Rahman — Sat, 13 Dec 2025 09:24:10 +0000

Static rendering—also called Static‑Site Generation (SSG)—pre‑generates HTML during your build step, so visitors receive ready‑to‑serve pages without invoking a JavaScript runtime on each request. The pattern marries the speed of a CDN with the developer experience of React. Below we’ll unpack how it works, then walk through three escalating examples:

Classic SSG (purely static)
SSG with build‑time data
SSG with individual detail pages

Finally, we’ll cover key considerations and wrap up with a quick checklist.

1. How Static Rendering Works

Build step – Your React components are rendered to HTML strings.
Asset emission – The build outputs plain .html, .css, and .js files.
CDN deployment – The files are uploaded to edge nodes worldwide.
Request/response cycle – A user’s browser receives an already rendered page, massively reducing Time to First Byte (TTFB) and Largest Contentful Paint (LCP).

Because there’s no server‑side computation per request, SSG excels at:

Performance (edge‑cached, no cold starts)
Reliability (few moving parts)
Cost efficiency (mostly bandwidth)
SEO (search crawlers get full HTML)

2. Classic SSG Implementation

Below is a minimal one‑page build using Node + react-dom/server. At build time we render <App /> to HTML and write it to /dist/index.html.

// build.js
import fs from "node:fs/promises";
import React from "react";
import { renderToStaticMarkup } from "react-dom/server";
import App from "./App.js";

(async () => {
  const html = renderToStaticMarkup(<App />);
  const doc = `<!DOCTYPE html><html><head><title>Static App</title></head><body>${html}</body></html>`;
  await fs.mkdir("dist", { recursive: true });
  await fs.writeFile("dist/index.html", doc);
  console.log("✅  Built static page ➜  dist/index.html");
})();

Run:

node build.js   # generates /dist/index.html
npx serve dist  # serves the folder locally

What we achieved

Zero runtime JavaScript (unless you hydrate later)
Blazing‑fast first paint
Works great for truly unchanging pages—docs, marketing landing pages, etc.

3. SSG with Build‑Time Data (Next.js)

When your page depends on HEADLINE data that changes only daily/weekly, you can fetch during the build:

// pages/index.tsx
export default function Home({ posts }) {
  return (
    <main>
      <h1>Blog</h1>
      <ul>
        {posts.map(p => <li key={p.id}>{p.title}</li>)}
      </ul>
    </main>
  );
}

export async function getStaticProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts?_limit=10");
  const posts = await res.json();
  return {
    props: { posts },
    revalidate: false   // no ISR in this example
  };
}

During next build, the API is hit once, and the resulting HTML carries the fetched data. Early visitors get pre‑filled content — no spinners, no blocking XHR.

4. SSG with Individual Detail Pages

For dynamic routes like /posts/[id], pair getStaticPaths with getStaticProps:

// pages/posts/[id].tsx
export default function Post({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.body}</p>
    </article>
  );
}

export async function getStaticPaths() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts?_limit=10");
  const posts = await res.json();
  const paths = posts.map(p => ({ params: { id: p.id.toString() } }));
  return { paths, fallback: false }; // pre‑generate 10 pages
}

export async function getStaticProps({ params }) {
  const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${params.id}`);
  const post = await res.json();
  return { props: { post } };
}

getStaticPaths enumerates which IDs to pre‑render.
fallback controls behavior for non‑generated IDs ('blocking' | 'true' | 'false').

You can scale this by enabling Incremental Static Regeneration (ISR) or on‑demand revalidation so you’re not rebuilding the entire site for every content change.

5. Key Considerations

Consideration	Why It Matters	Mitigation
Build Time	Thousands of pages mean longer builds.	Split builds, ISR, parallelization.
Data Freshness	Static pages can become stale.	Use `revalidate` (ISR) or webhooks to trigger rebuilds.
Personalization	SSG can’t easily personalize per user.	Combine with client‑side rendering or edge middleware.
Large Data Sets	Generating every permutation might be impractical.	Opt for partial prerender + `fallback: "blocking"` for rarer paths.
Secret Data	Anything included at build is public.	Keep private data on the server; call via API at runtime.

6. Conclusion

Static rendering sits at the intersection of predictability and performance. Use it when:

Content changes infrequently or on a predictable schedule
SEO and initial‑paint speed are paramount
You’re comfortable pushing updates via CI/CD rather than at request time

For highly dynamic, user‑specific dashboards you’ll still reach for SSR or CSR. But for landing pages, docs, blogs, e‑commerce product listings, and marketing sites, SSG remains a battle‑tested pattern—and, as Learning Patterns highlights, one of the simplest ways to deliver a snappy, resilient user experience.

Checklist

[ ] Identify pages with stable content
[ ] Fetch external data in getStaticProps
[ ] Generate dynamic routes with getStaticPaths
[ ] Decide if ISR is required for freshness
[ ] Automate deployment to a CDN/edge platform

Happy building! 🏗️🚀

Mastering Server‑Side Rendering (SSR)

Md Enayetur Rahman — Sat, 13 Dec 2025 09:21:01 +0000

“Server‑side rendering is **not* the goal. Faster time‑to‑interactive, better SEO and predictable data is.”*

— Learning Patterns, Hallie & Osmani

1. What is Server‑Side Rendering?

Server‑Side Rendering (SSR) means generating the HTML for each request on the server, then sending that markup to the browser so the user sees meaningful UI before JavaScript finishes hydrating.

The sequence is:

Request → browser asks for a page
Render → server executes component tree to HTML
Send → server returns HTML + critical assets
Hydrate → client JavaScript attaches event listeners

SSR differs from Static Site Generation (HTML produced at build time) and purely Client‑Side Rendering (HTML generated after JS loads).

2. Classic React SSR (before frameworks)

npm i express react react-dom react-dom/server

// server.js – minimal SSR with Express
import express from "express";
import { readFileSync } from "fs";
import React from "react";
import { renderToString } from "react-dom/server";
import App from "./App.js";

const htmlTemplate = readFileSync("./index.html", "utf8");
const server = express();

server.get("*", (req, res) => {
  const markup = renderToString(<App url={req.url} />);
  const html = htmlTemplate.replace("<!--app-->", markup);
  res.send(html);
});

server.listen(3000, () => console.log("SSR app ↘ http://localhost:3000"));

This works, but you must hand‑roll routing, code‑splitting, data‑fetch orchestration, streaming, and more.

3. Pros & Cons of SSR

✅ Pros	🚧 Cons
First content paints fast on slow devices	Server must render on every request — cost & latency
SEO‑friendly (HTML visible to crawlers)	More complicated cache strategy than static generation
Consistent data (no layout shift from client fetching)	Adds coupling between server and client environments
Enables progressive streaming & React Suspense	Cannot fully leverage CDN edge unless cached

4. SSR with Next.js

Next.js automates bundling, routing, code‑splitting and hot‑reloading while exposing two flavours of SSR:

4.1 Pages Router – `getServerSideProps`

// pages/index.jsx
export async function getServerSideProps() {
  const res = await fetch("https://api.example.com/posts");
  const posts = await res.json();
  return { props: { posts } };
}

export default function Home({ posts }) {
  return (
    <main>
      <h1>Latest posts</h1>
      <ul>{posts.map(p => <li key={p.id}>{p.title}</li>)}</ul>
    </main>
  );
}

Every request runs getServerSideProps; HTML streams back to the client.

4.2 App Router (Next 14 +) – Server Components & Streaming

// app/page.tsx (acts like a React Server Component)
import PostList from "./PostList";   // also a server component

export default async function Home() {
  const posts = await fetch("https://api.example.com/posts").then(r => r.json());

  return (
    <>
      <h1>Latest posts</h1>
      {/* PostList can stream in parallel */}
      <PostList initialPosts={posts} />
    </>
  );
}

The App Router uses React Server Components (RSC) and Suspense‐based streaming so HTML chunks arrive progressively.

5. React for the Server (RSC vs SSR)

React 19 stabilised Server Components, letting parts of the tree run only on the server — no JS shipped to the client.

// components/ServerChart.server.jsx
import db from "@/lib/db";
import Chart from "@/components/Chart";   // client component

export default async function ServerChart() {
  const data = await db.sales.findMany();
  return <Chart data={data} />;
}

.server.jsx executes on the server, can access secrets, returns serialized props.
Client receives just the final HTML for that chunk plus minimal hydration JS for purely interactive children.

This complements SSR: pages can statically stream and embed dynamic server logic.

6. Putting It All Together

Small sites → prefer Static generation; sprinkle RSC for secure data.
Content‑heavy, SEO‑critical apps → SSR via Pages or App router.
Data‑intensive dashboards → mix SSR + RSC + streaming for best TTFB and interactivity.

7. Conclusion

Server‑Side Rendering has matured from hand‑rolled renderToString() scripts to first‑class primitives in Next.js 14 and React 19.

By combining SSR, React Server Components and streaming, you can deliver fast‑painting, SEO‑friendly, user‑centric experiences without drowning in complexity.

Inspired by principles in “Learning Patterns” — Hallie & Osmani, ch. 5 (Rendering Strategies).

Next.js Client‑Side Rendering: Bundles, Performance & Practical Optimisations

Md Enayetur Rahman — Sat, 13 Dec 2025 09:19:06 +0000

This article is part of my Learning Patterns series, where I distill insights from Lydia Hallie & Addy Osmani’s book into real‑world React/Next.js workflows.

1  |  What is Client‑Side Rendering (CSR)?

In CSR, the server ships only a bare‑bones HTML container; React and its JavaScript take over in the browser—handling routing, data fetching and templating.

Server ⟶ <div id="root"></div>  
Browser ⟶ downloads `/static/js/bundle.js` ⟶ runs React ⟶ paints UI

Quick demo in a Next.js 14 app

// app/csr-clock/page.js
"use client";
import { useEffect, useState } from "react";

export default function Clock() {
  const [now, setNow] = useState(Date.now());
  useEffect(() => {
    const id = setInterval(() => setNow(Date.now()), 1000);
    return () => clearInterval(id);
  }, []);
  return <p className="text-center text-2xl">{new Date(now).toLocaleTimeString()}</p>;
}

Everything (including the interval) runs on the client, so no extra round‑trips are needed.

2  |  Understanding the JavaScript Bundle

What lands in the bundle?

Static imports in every route.
Third‑party dependencies.
Your own components and utilities.

The book reminds us that “the bigger the bundle, the longer users stare at a blank screen” before FCP and TTI kick in.

Peeking inside

# Install once
npm i -D @next/bundle-analyzer
# Build with analysis
ANALYZE=true npm run build

This opens an interactive treemap showing which packages bloat the bundle.

Measuring real performance

# Local Lighthouse
npx lighthouse http://localhost:3000 --view

# Web‑Vitals snippet (in _app.tsx)
import { reportWebVitals } from 'next/web-vitals';
export function reportWebVitals(metric) {
  console.log(metric);
}

3  |  Pros & Cons of CSR

| 💚 Strengths | 😬 Trade‑offs |
| --------------------------------------------------------------| --------------- -------------------------------------------------|
| SPA‑like fluid navigation—no full page reloads | Initial blank screen until JS downloads & executes |
| Clear separation between API & UI layers | SEO is tougher: crawlers may time‑out before content appears |
| Powerful client‑only interactions (e.g. real‑time dashboards) | Large bundles hit FCP/LCP/TTI, especially on low‑end devices |
| Works offline/with service‑workers | Potential duplication of validation logic across client & server |

4  |  Five Ways to Speed‑Up CSR in Next.js

Performance is inversely proportional to bundle size—so shrink, split and delay JS!

4.1 Route‑based code splitting (automatic)

Next.js ships each page as its own chunk. Avoid giant layouts that re‑import heavy libs everywhere.

4.2 Component‑level code splitting

import dynamic from "next/dynamic";

const EmojiPicker = dynamic(() => import("./EmojiPicker"), {
  ssr: false,
  loading: () => <p>Loading…</p>,
});

EmojiPicker drops out of the initial bundle and loads on demand.

4.3 Tree‑shaking & dead‑code elimination

Use ES modules (import { X } from "y")
Prefer lightweight icon/lib alternatives (e.g. @svgr/webpack over Font‑Awesome).

4.4 Inline critical CSS, defer the rest

Inline the bare minimum styles needed for first paint—defer bulky component CSS with @import() inside the component file.

4.5 Audit third‑party packages

Regularly compare alternatives (react-select → react-select-search, etc.) and watch Lighthouse/TBT drop.

Real‑world win (Next.js Movies App)

Lazy‑loading a sidebar reduced Total Blocking Time by 71%.
Swapping Font‑Awesome for inline SVG slashed LCP by 23%.

5  |  Putting It All Together – A Checklist

Analyze your bundles after every dependency addition.
Split routes & heavy components with next/dynamic.
Inline only the CSS needed for FCP.
Ship SVGs/icons smartly—avoid icon fonts.
Monitor Web‑Vitals in production and iterate.

6  |  Conclusion

Client‑Side Rendering isn’t dead—it just demands discipline. By treating every kilobyte of JavaScript as a cost and applying the patterns above, you keep CSR fast, SEO‑friendly enough, and enjoyable to build.

Inspired by pages on CSR, bundle‑splitting and performance tuning in **Learning Patterns* (Hallie & Osmani, 2021).*

DEV Community: Md Enayetur Rahman

Optimize Loading Sequence (Part 2)

Introduction

1 · Critical CSS

2 · Fonts

3 · Images

Above‑the‑Fold

Below‑the‑Fold

4 · Scripts

First‑Party JS

Third‑Party JS

5 · How Chrome Prioritises Resources (Book Table)

6 · Case Study — Next.js SSR (Before Optimisation)

Default Sequence

7 · Proposed Sequence (No 3rd‑Party)

Reasons

8 · Proposed Sequence (With 3rd‑Party)

Reasons

Conclusion

Optimize Loading Sequence (Part 1) – Metrics & Challenges

Table of Contents

Why Loading Sequence Matters

Key Metrics to Track

Why True Optimization Is Tricky

1 · Sub‑optimal Sequencing

2 · Network & CPU Utilization

3 · Third‑Party Products

4 · Platform Quirks

5 · HTTP/2 Prioritization Pitfalls

6 · Resource‑Level Optimization Gaps

Conclusion

Islands Architecture in Practice – A Deep Dive

Table of Contents

What Sparked Islands Architecture?

Islands of Dynamic Components Explained

Implementing Islands — The Core Mechanics

Ecosystem & Framework Support

DIY: A Minimal Islands Implementation

1 · Install Astro

2 · Create an Island Component (src/components/Counter.jsx)

3 · Use the Island in a Page (src/pages/index.astro)

Vanilla Roll‑Your‑Own (Optional)

Pros & Cons

Conclusion

Optimizing Core Web Vitals in the *Next.js Movies* App – A Full Playbook

Table of Contents

Why Core Web Vitals?

Benchmark: Next.js Movies

Cumulative Results

Optimization Checklist – 11 Changes

Conclusion & Key Take‑aways

Selective vs Progressive Hydration

Progressive Hydration

Simplified Example

Selective Hydration

Simplified Example

Pros & Cons

When to Use What?

Conclusion

Further Reading

Beyond SSR: Demystifying React Server Components for Real‑World Apps

Why look beyond classic SSR?

What is a Server Component?

Key characteristics

Automatic Code Splitting (RSC vs. React.lazy())

SSR vs. Server Components — at a glance

Putting it together

Conclusion

Streaming Server‑Side Rendering in React: A Learning Patterns Deep Dive

Table of Contents

What Is Streaming Server‑Side Rendering?

Why Streaming?

How React Implements Streaming

Code Example – Express + React 18

Three Takeaways

Pros & Cons

Conclusion

Progressive Hydration in React: Taming the Hydration Monster

Table of Contents

The Hydration Problem

Optimize Loading Sequence (Part 2)

2 · Create an Island Component (`src/components/Counter.jsx`)

3 · Use the Island in a Page (`src/pages/index.astro`)

Optimizing Core Web Vitals in the Next.js Movies App – A Full Playbook

Automatic Code Splitting (RSC vs. `React.lazy()`)

a) Time-based revalidation with `getStaticProps`

3. Pros & Cons of SSR

4.1 Pages Router – `getServerSideProps`

4.2 App Router (Next 14 +) – Server Components & Streaming

1  |  What is Client‑Side Rendering (CSR)?

2  |  Understanding the JavaScript Bundle

3  |  Pros & Cons of CSR

4  |  Five Ways to Speed‑Up CSR in Next.js

5  |  Putting It All Together – A Checklist

6  |  Conclusion