DEV Community: Ogasawara Kakeru

ReactJs Performance ~ Server-Side Rendering (SSR) and Static Generation ~

Ogasawara Kakeru — Sun, 10 May 2026 22:23:26 +0000

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.

Rendering Strategy Comparison

Client-Side Rendering (CSR)

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

Server-Side Rendering (SSR)

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

Static Site Generation (SSG)

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

Next.js SSR Implementation

// 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 (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <button>Add to Cart</button>
    </div>
  );
}

Next.js SSG Implementation

// 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 (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

**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
export async function getStaticProps() {
const data = await fetchData();

return {
props: {
data,
},
revalidate: 60, // Rebuild the page every 60 seconds
};
}




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 |

ReactJs Performance ~ Memory Leak Prevention ~

Ogasawara Kakeru — Thu, 07 May 2026 01:36:20 +0000

Memory leaks gradually reduce the responsiveness of React applications. At first everything feels normal, but after extended usage — around 10 to 15 minutes — the UI may start lagging, animations become choppy, and in severe cases the application can freeze or crash completely.

Frequent Causes of Memory Leaks in React

1. Timers and intervals that are never cleared

// ❌ Risky: interval continues even after component removal
function AutoCounter() {
  const [value, setValue] = useState(0);

  useEffect(() => {
    window.setInterval(() => {
      setValue((previous) => previous + 1);
    }, 1000);

    // No interval cleanup
  }, []);

  return <div>{value}</div>;
}

// ✅ Better: clear interval during unmount
function ManagedAutoCounter() {
  const [value, setValue] = useState(0);

  useEffect(() => {
    const timer = window.setInterval(() => {
      setValue((previous) => previous + 1);
    }, 1000);

    return () => {
      window.clearInterval(timer);
    };
  }, []);

  return <div>{value}</div>;
}

2. Event handlers that remain attached:

// ❌ Incorrect: listener remains active after unmount
function ResponsiveLayout() {
  useEffect(() => {
    window.addEventListener('resize', updateViewportSize);

    // Cleanup is missing
  }, []);

  return <div>Responsive page</div>;
}

// ✅ Correct: unregister listener during cleanup
function SafeResponsiveLayout() {
  useEffect(() => {
    window.addEventListener('resize', updateViewportSize);

    return () => {
      window.removeEventListener('resize', updateViewportSize);
    };
  }, []);

  return <div>Responsive page</div>;
}

3. WebSocket sessions left active:

// ❌ Problematic: socket connection is never terminated
function RealtimeFeed() {
  useEffect(() => {
    const socket = new WebSocket('wss://stream.example.dev');

    socket.onmessage = receiveLiveUpdate;

    // No cleanup logic
  }, []);

  return <div>Streaming updates...</div>;
}

// ✅ Safer approach: disconnect on component cleanup
function StableRealtimeFeed() {
  useEffect(() => {
    const socket = new WebSocket('wss://stream.example.dev');

    socket.onmessage = receiveLiveUpdate;

    return () => {
      socket.close();
    };
  }, []);

  return <div>Streaming updates...</div>;
}

4. Retaining references to heavy data objects:

// ❌ Inefficient: keeps heavy data in memory
function InefficientComponent({ dataset }) {
  const cacheRef = useRef(null);

  useEffect(() => {
    // Stores transformed data without cleanup
    cacheRef.current = transformDataset(dataset);
  }, [dataset]);

  return <div>Data ready</div>;
}

// ✅ Improved: clears unused references properly
function OptimizedComponent({ dataset }) {
  const cacheRef = useRef(null);

  useEffect(() => {
    cacheRef.current = transformDataset(dataset);

    return () => {
      // Remove retained reference during cleanup
      cacheRef.current = undefined;
    };
  }, [dataset]);

  return <div>Data ready</div>;
}

Memory Leak Detection Checklist

Leak Category	Detection Technique	Severity	Estimated Fix Time	Fix Difficulty
Unremoved event listeners	Inspect with memory profiling tools	High	5–10 minutes	Low
Uncleared timers or intervals	Check console warnings and logs	High	2–5 minutes	Low
Persistent WebSocket connections	Monitor through the Network panel	High	10–20 minutes	Low
Retained large object references	Compare heap snapshots	Medium	15–30 minutes	Medium
Unintended closure retention	Analyze heap snapshots	Medium	20–40 minutes	High
Lingering DOM node references	Track using memory profiler	Low	30–60 minutes	Low

// Enable only during local development
if (process.env.NODE_ENV === 'development') {
  useEffect(() => {
    const monitorHeapUsage = () => {
      if (!performance.memory) return;

      const heapSizeInMB =
        performance.memory.usedJSHeapSize / (1024 * 1024);

      console.log(
        `[Heap Monitor] Current usage: ${heapSizeInMB.toFixed(2)} MB`
      );

      // Warn when memory consumption becomes unusually high
      if (heapSizeInMB >= 200) {
        console.warn(
          '[Heap Monitor] Potential memory leak detected.'
        );
      }
    };

    // Run memory inspection every 5 seconds
    const timerId = window.setInterval(monitorHeapUsage, 5000);

    return () => {
      window.clearInterval(timerId);
    };
  }, []);
}

Chrome DevTools provides a Memory profiling tool that helps identify memory leaks through heap snapshots and allocation tracking. A common workflow is to capture one snapshot before a user action and another afterward, then compare the results to detect objects that remain unexpectedly in memory.

If certain objects continue to exist even though they are no longer needed and should have been garbage collected, this usually suggests a memory retention issue or leak.

ReactJs Performance ~ Web Workers for Heavy Computations ~

Ogasawara Kakeru — Sun, 03 May 2026 08:29:22 +0000

JavaScript runs on a single thread, which means intensive tasks can freeze the UI and hurt the user experience.

To avoid this, you can offload heavy work to background threads using Web Workers.

🔧 When Web Workers are useful

Processing images or videos in the browser
Handling large datasets (sorting, filtering, transformations)
Performing CPU-heavy calculations (e.g. simulations, analytics)
Parsing large files like CSV, JSON, or XML
Running cryptographic or hashing operations
Managing real-time data streams without blocking the UI

Web Worker implementation example

// dataWorker.js
self.addEventListener('message', event => {
  const { items, taskType } = event.data;

  const output = runBackgroundTask(items, taskType);

  self.postMessage({
    status: 'completed',
    result: output,
  });
});

function runBackgroundTask(items, taskType) {
  if (taskType !== 'transform') {
    return items;
  }

  return items.map(item => {
    return applyHeavyTransformation(item);
  });
}

function applyHeavyTransformation(item) {
  // Put CPU-heavy logic here
  return {
    ...item,
    processed: true,
  };
}

// DataProcessor.jsx
import { useEffect, useState } from 'react';

function DataProcessor({ items }) {
  const [result, setResult] = useState([]);
  const [isRunning, setIsRunning] = useState(false);

  useEffect(() => {
    const backgroundWorker = new Worker(
      new URL('./dataWorker.js', import.meta.url)
    );

    backgroundWorker.addEventListener('message', event => {
      setResult(event.data.result);
      setIsRunning(false);
    });

    setIsRunning(true);

    backgroundWorker.postMessage({
      items,
      taskType: 'transform',
    });

    return () => {
      backgroundWorker.terminate();
    };
  }, [items]);

  if (isRunning) {
    return <LoadingIndicator />;
  }

  return <DataVisualization data={result} />;
}

In this example, the expensive transformation is moved outside the main React rendering flow.

The component sends raw data to the worker, waits for the processed result, and keeps the UI responsive while the task runs in the background.

Performance Comparison by Task Type

Task	Main Thread	Worker Thread	UI Smoothness	Implementation Difficulty
Image filtering	~800ms (blocks execution)	~850ms (runs off the main thread)	Maintains 60 FPS	Moderate
Data sorting (100k items)	~450ms (blocking)	~480ms (non-blocking)	Maintains 60 FPS	Low
JSON parsing (large payload)	~600ms (causes freeze)	~620ms (handled in background)	Maintains 60 FPS	Low
Physics simulations	~1200ms (UI freeze)	~1250ms (processed asynchronously)	Maintains 60 FPS	High
Cryptographic operations	~350ms (blocking)	~360ms (keeps UI responsive)	Maintains 60 FPS	Moderate
Video transcoding	Not feasible (too heavy)	Executed in background	Maintains 60 FPS	Very High

⚠️ Things to know before using Web Workers

While Web Workers are powerful, they come with a few trade-offs:

They cannot directly interact with the DOM
Memory is isolated from the main thread (SharedArrayBuffer is an advanced workaround)
Communication between threads introduces latency (~5–10ms per message)
Data must be serialized/deserialized when passing between threads

🧠 When should you actually use them?

A good rule of thumb:

If a task takes longer than ~50ms, it's a good candidate for a Web Worker.

For shorter operations, the cost of message passing can outweigh the performance gains.

In those cases, you might be better off using:

requestIdleCallback → to run tasks when the browser is idle
Simple async patterns → to avoid blocking rendering

🛠️ Modern tooling makes it easier

Today’s tooling significantly reduces the complexity of working with Web Workers:

Vite / Webpack → allow direct worker imports with minimal setup
Comlink → abstracts message passing into a simple function-call-like API

These tools make it much easier to integrate background processing into modern frontend applications without dealing with low-level boilerplate.

💡 Practical perspective

Use Web Workers selectively.

They shine in CPU-heavy scenarios, but for lightweight tasks, simpler approaches often lead to better overall performance and maintainability.

ReactJs Performance ~ Tree Shaking and Bundle Analysis ~

Ogasawara Kakeru — Wed, 29 Apr 2026 22:37:33 +0000

Reduce Your Bundle Size with Effective Tree Shaking

Modern JavaScript bundlers are smart—but they’re not mind readers. If you want smaller production bundles, you need to structure your code in a way that makes unused code easy to remove.

What actually makes tree shaking work?

Tree shaking relies on static analysis. That means your code has to be predictable and explicit so the bundler can safely eliminate what’s not used.

Here are the fundamentals:

1. Stick to ES Modules

Use import / export syntax so the bundler can analyze dependencies at build time.

import { fetchData } from "./api";

export const load = () => fetchData();

Avoid CommonJS where possible:

const { fetchData } = require("./api");

This pattern makes it harder for bundlers to optimize.

Be precise with imports

Pulling in an entire library when you only need one function is one of the fastest ways to bloat your bundle.

// ❌ Pulls in everything
import _ from "lodash";

const result = _.debounce(fn, 300);
// ✅ Only what you need
import { debounce } from "lodash-es";

const result = debounce(fn, 300);
// ✅ Even more direct
import debounce from "lodash-es/debounce";

const result = debounce(fn, 300);

Declare side effects explicitly

Bundlers avoid removing files that might cause side effects. You can help them by clarifying this in package.json:

{
  "sideEffects": false
}

⚠️ Be careful: if your code includes things like global styles, polyfills, or initialization logic, marking everything as side-effect-free can break your app.

Prefer named exports in reusable code

Named exports give bundlers clearer signals about what’s being used.

export const Card = () => {};
export const Tooltip = () => {};

Then import only what you need:

import { Card } from "@/components/ui";

Don’t guess—inspect your bundle

Instead of assuming optimizations are working, analyze the output.

Install analyzer

npm install --save-dev webpack-bundle-analyzer

Example setup

const { BundleAnalyzerPlugin } = require("webpack-bundle-analyzer");

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: "static",
      openAnalyzer: false,
      reportFilename: "report.html",
    }),
  ],
};

Build and review

npm run build

Open the generated report and look for unexpectedly large modules.

Common hidden bundle killers

Here are issues that often show up in real projects:

・Heavy date libraries used for simple formatting
・Importing entire icon packs instead of individual icons
・Duplicate dependencies caused by version mismatches
・Legacy browser polyfills that aren’t needed anymore
・Source maps accidentally included in production builds

Practical improvements
Replace heavy utilities

// Instead of a large library
import { format } from "date-fns";


const label = format(new Date(), "yyyy-MM-dd");

Limit icon imports

// ❌ Loads everything
import * as Icons from "lucide-react";
// ✅ Only what you use
import { Search, User } from "lucide-react";

Final thoughts

Tree shaking isn’t automatic magic—it’s a collaboration between your code and your tooling.

If you:

・write explicit imports
・structure exports clearly
・and verify your bundle output

you’ll consistently ship smaller, faster applications.

ReactJs Performance ~ Database and API Optimization~

Ogasawara Kakeru — Mon, 27 Apr 2026 01:19:36 +0000

Frontend performance means nothing if API takes 3 seconds to respond. backend optimization is frontend optimization.

API performance strategies:

1. Implement efficient data fetching:

// Bad: Sequential fetches (slow)
async function loadDashboard() {
  const user = await fetchUser();
  const posts = await fetchPosts(user.id);
  const comments = await fetchComments(posts.map(p => p.id));
  return { user, posts, comments };
}
// Total time: ~600ms

// Good: Parallel fetches (fast)
async function loadDashboard() {
  const [user, posts, comments] = await Promise.all([
    fetchUser(),
    fetchPosts(),
    fetchComments()
  ]);
  return { user, posts, comments };
}
// Total time: ~200ms (fastest query wins)

2. Use GraphQL for precise data fetching:
Instead of multiple REST endpoints returning excess data, GraphQL lets you request exactly what you need in one query. This reduces payload size (30-60% smaller) and eliminates multiple round trips.

3. Implement caching strategies:

import { useQuery } from '@tanstack/react-query';

function UserProfile({ userId }) {
  const { data, isLoading } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetchUser(userId),
    staleTime: 5 * 60 * 1000, // 5 minutes
    cacheTime: 30 * 60 * 1000, // 30 minutes
  });

  if (isLoading) return <Skeleton />;
  return <ProfileCard user={data} />;
}

Backend Optimization Impact:

🚀 API Performance Optimization Strategies (Practical Guide)

When improving API performance, it's important to balance speed, cost, and implementation effort.

Here are some practical techniques with realistic expectations:

Technique	Speed Impact	Data Transfer	Difficulty	Cost Impact
Index tuning (DB)	Significant (50–75% faster)	No change	Easy	Very low
Query refinement	Moderate to high (35–65% faster)	No change	Medium	Noticeable reduction
Payload compression (gzip/brotli)	Slight improvement (10–25%)	Reduced (60–85%)	Easy	Moderate
HTTP/2 or HTTP/3	Moderate (25–45% faster)	No change	Easy (config)	Minimal
Edge caching (CDN)	High (40–70% faster)	No change	Medium	Depends on usage
Request batching (GraphQL / REST)	High (45–65% faster)	Reduced (25–50%)	Medium	Moderate

💡 Key Takeaways

Start with the database → indexing gives the biggest ROI with minimal effort
Compression is underrated → huge bandwidth savings with almost no downside
CDN is powerful but situational → best for read-heavy APIs
Batching reduces overfetching → especially effective in GraphQL environments

🧠 Practical Strategy

If you're building an API (especially with Next.js / React stack), a good order is:

Fix slow queries (DB + API layer)
Add compression (gzip or brotli)
Enable HTTP/2
Introduce CDN if needed
Optimize request patterns (batching / caching)

ReactJs Performance ~ Optimizing Images and Assets~

Ogasawara Kakeru — Thu, 23 Apr 2026 06:55:35 +0000

In typical React apps, images account for 50–70% of page weight. Properly optimising them can dramatically improve load times and user experience.

Modern image optimisation checklist

1.Use WebP/AVIF formats, which are 30-50% smaller than JPEG.
2.Implement responsive images to serve the appropriate size.
3.Lazy load off-screen images – defer non-critical images.
4.Use modern image components such as Next.js Image or Gatsby Image.
5.Use modern image components such as Next.js Image or Gatsby Image.
6.Set explicit dimensions to prevent layout shift.
7.Implement placeholders (LQIP or blurred thumbnails).

Image Optimization Implementation:

import Image from 'next/image';

function ProductGallery({ images }) {
  return (
    <div className="gallery">
      {images.map((img, idx) => (
        <Image
          key={img.id}
          src={img.url}
          alt={img.description}
          width={800}
          height={600}
          loading={idx < 3 ? 'eager' : 'lazy'} // Prioritize above-fold
          placeholder="blur"
          blurDataURL={img.thumbnail}
          quality={85}
        />
      ))}
    </div>
  );
}

Image Optimization Impact Table:

Image Optimization Strategies

Technique	Main Effect	Performance Impact	Setup Cost	Notes
WebP	Smaller image payloads than older formats	Helps pages load faster in many cases	Low	Good default choice with fallback support
AVIF	Stronger compression, especially for large assets	Can improve loading performance further	Medium	Better savings, but support strategy should be considered
Responsive images	Sends more appropriate image sizes to each device	Especially effective on mobile	Medium	Reduces unnecessary downloads
Lazy loading	Delays non-critical images until needed	Improves initial page load	Low	Useful for below-the-fold content
Compression	Cuts image weight without changing the layout	Improves delivery speed	Low	Often one of the easiest wins
Explicit dimensions	Reserves space before images load	Prevents layout shift	Low	Important for visual stability
CDN delivery	Serves cached assets closer to users	Improves loading consistency	Medium	Helps at scale and across regions

CDN integration is important, too. Cloudflare Images, Cloudinary and Imgix automatically provide the optimal format, size and compression based on the device making the request. This means that one API call replaces dozens of manual optimisation steps.

ReactJs Performance ~ Virtualization for Large Lists~

Ogasawara Kakeru — Mon, 20 Apr 2026 21:41:09 +0000

Rendering very large lists in React can quickly become a performance bottleneck.

For example, trying to render thousands of items at once often leads to laggy UI or even browser instability.

Virtualization addresses this by limiting how many elements are actually mounted in the DOM.

Instead of rendering the entire list, only the items currently visible in the viewport are rendered, along with a small buffer.

As the user scrolls, items that move out of view are removed, and new ones are mounted dynamically.

This keeps the DOM size small and the rendering cost low.

Libraries like react-window and react-virtualized make it easy to implement this pattern without handling all the edge cases manually.

Normal Rendering

function ItemGrid({ items }) {
  // All items are rendered at once
  return (
    <section>
      {items.map((item) => (
        <ItemCard key={item.id} data={item} />
      ))}
    </section>
  );
}

// Outcome: noticeable delay and UI lag when the list is very large

Virtualized Rendering

import { FixedSizeList as VirtualList } from 'react-window';

function ItemList({ data }) {
  return (
    <VirtualList
      height={700}
      itemCount={data.length}
      itemSize={100}
      width="100%"
    >
      {({ index, style }) => {
        const item = data[index];

        return (
          <div style={style}>
            <ItemCard item={item} />
          </div>
        );
      }}
    </VirtualList>
  );
}

Virtualization Performance (My Perspective)

List Size	Normal Rendering	Virtualized Rendering	Main Benefit	Scrolling Experience
Small lists	Usually acceptable	Slightly more efficient	Limited impact	Smooth
A few hundred rows	Can start feeling heavier	Remains responsive	Noticeable reduction in work	Smooth
Around 1,000 rows	Often slows down	Still stable	Much lower rendering cost	Smooth
Several thousand rows	Performance drops sharply	Handles large datasets well	Major DOM reduction	Mostly smooth
Tens of thousands of rows	Can become impractical	Still usable with tuning	Very high efficiency gain	May depend on row complexity

The exact numbers depend on the browser, row complexity, and component structure, but the overall trend is consistent: virtualization becomes much more valuable as the list grows.

When to virtualise:

Lists with 50+ items
Items with moderate-to-high complexity
Infinite scroll implementations
Tables with many rows
Chat message histories

When not to virtualise:

Small lists (fewer than 20 items) – the overhead isn't worth it

Lists that need to be fully searchable by the browser
Print-friendly content
SEO-critical content (virtualised content isn't included in the initial HTML)

One consideration: virtualised lists require fixed or calculated heights. Items with variable heights need React Window's VariableSizeList with a measurement phase, which adds complexity. For most cases, design list items with consistent heights.

ReactJs Performance ~ State Management~

Ogasawara Kakeru — Fri, 17 Apr 2026 20:45:57 +0000

・The choice of state management can have a dramatic effect on React performance, but most comparisons focus on developer experience rather than runtime characteristics.

Having implemented Context, Redux, Zustand and Jotai in production apps, the following factors were found to be important: re-render frequency, serialisation overhead and selector performance. Each solution balances these factors differently.

Tool	My Impression	Trade-off	Good Use Case
Context API	Simple but limited at scale	Re-renders can spread easily	Local or tightly related state
Redux	Structured and predictable	More setup and concepts	Large apps with strong debugging needs
Zustand	Lightweight and practical	Less opinionated structure	Modern apps that value simplicity
Jotai	Flexible and fine-grained	Requires understanding atom-based thinking	Derived and modular state
Recoil	Good for dependent state	Heavier choice for some teams	Complex state relationships
MobX	Powerful and reactive	Different mental model	Observable-style architecture

A pitfall for Context API:
When using the Context API, updating a single value (like mode) will cause all components consuming the context to re-render.

import { createContext, useState } from 'react';

const UIContext = createContext(undefined);

export function UIProvider({ children }) {
  const [theme, setTheme] = useState('dark');
  const [account, setAccount] = useState(null);

  // Even a small change like "theme" will trigger re-render for all consumers
  const state = {
    theme,
    updateTheme: setTheme,
    account,
    updateAccount: setAccount,
  };

  return (
    <UIContext.Provider value={state}>
      {children}
    </UIContext.Provider>
  );
}

Solution: Split contexts according to their update frequency:

// Contexts split by how often they change
const AccountContext = createContext(null);      // Rare updates
const AppearanceContext = createContext(null);   // Medium updates
const AlertContext = createContext(null);        // Frequent updates

// Each component subscribes only to the data it actually needs
function Navbar() {
  const account = useContext(AccountContext); // Re-renders only when account changes

  return <p>Hello, {account?.username}</p>;
}

The Zustand approach offers better performance:

import { create } from 'zustand';

// Components subscribe only to specific slices of state
const useAppStore = create((set) => ({
  account: null,
  colorMode: 'dark',
  messages: [],

  updateAccount: (account) => set({ account }),
  switchMode: (mode) => set({ colorMode: mode }),
  pushMessage: (msg) =>
    set((prev) => ({
      messages: [...prev.messages, msg],
    })),
}));

// This component reacts only to "colorMode"
function ModeSwitcher() {
  const colorMode = useAppStore((s) => s.colorMode);
  const switchMode = useAppStore((s) => s.switchMode);

  return (
    <button onClick={() => switchMode(colorMode === 'dark' ? 'light' : 'dark')}>
      Switch Mode
    </button>
  );
}

ReactJs Performance ~Code Splitting and lazy Loading Storatrgies~

Ogasawara Kakeru — Mon, 13 Apr 2026 23:15:34 +0000

The size of your JavaScript bundle directly impacts your First Contentful Paint (FCP) and Largest Contentful Paint (LCP), which are two critical Core Web Vitals metrics that affect both user experience and SEO rankings.

The problem is that most React apps ship one massive JavaScript bundle containing every component, library and feature. Users on mobile devices download megabytes of code for features they might never use. My rule of thumb is that if a feature isn't visible when the page first loads, it shouldn't

Strategic code splitting approaches:
Route-based splliting

import { lazy, Suspense } from 'react';

//Users download only when they visit
const Home= lazy(() => import('./pages/Home'));
const About= lazy(() => import('./pages/About'));
const Detail= lazy(() => import('./pages/Detaile'));

function App() {
  return (
    <Suspense fallback={<p>Loading...</p>}>
      <Routes>
        <Route path="/home" element={<Home/>} />
        <Route path="/about" element={<About/>} />
        <Route path="/detail" element={<Detail/>} />
      </Routes>
    </Suspense>
  );
}

Conponent-based splitting

// Down load hevy component when you need it.
const Video= lazy(() => import('./Video'));

function MediaSection({ showVideo }) {
  return (
    <div>
      {showVideo && (
        <Suspense fallback={<p>Loading...</p>}>
          <Video/>
        </Suspense>
      )}
    </div>
  );
}

Library splitting

// Only load when needed
const PDF = () => import('react-pdf');
const Excel = () => import('xlsx');

async function handleExport(type) {
  if (type === 'pdf') {
    const { PDFDownloadLink } = await PDF();
    // Use PDFDownloadLink
  } else if (type === 'excel') {
    const XLSX = await Excel();
    // Use XLSX
  }
}

✨ Code Splitting: Practical Impact Overview

Here’s a simplified breakdown of how different code splitting strategies affect performance and when to use them:

Strategy	Bundle Size Reduction	Performance Gain (TTI)	Complexity	When It Works Best
Route-based split	~60–80%	~40–60% faster	Easy	Applications with multiple pages
Component split	~30–50%	~20–35% faster	Moderate	Pages with many independent features
Library split	~20–40%	~15–30% faster	Easy	Projects using large third-party libraries
Vendor split	~15–25%	~10–20% faster	Easy	Long-term caching optimization
Dynamic import	~40–70%	~30–50% faster	Moderate	Features loaded on demand
Prefetching	N/A (preloading)	~50–80% faster navigation	Moderate	Predictable user interactions

ReactJs Performance ~React Compiler~

Ogasawara Kakeru — Sun, 12 Apr 2026 22:12:48 +0000

React 19 introduced the React Compiler to optimize components without useMemo or useCallback.

Before

const Component = ({ datas}) => {

  const memoizedDatas= useMemo(() => {
    return datas.map(item => format(item));
  }, [datas]);

  const handleOnClick = useCallback(() => {
    doSomething(memoizedDatas);
  }, [memoizedDatas]);

  return <div onClick={handleOnClick}>{memoizedDatas.map(data => data.item)}</div>;
};

After

const Component = ({ datas}) => {

  const memoizedDatas= datas.map(item => format(item));

  const handleOnClick= () => {
    doSomething(memoizedDatas);
  };

  return <div onClick={handleOnClick}>{memoizedDatas.map(data => data.item)}</div>;
};

ReactJs Performance ~React Rendering Pattern~

Ogasawara Kakeru — Fri, 10 Apr 2026 08:48:56 +0000

・Before dealing with performance optimization, we have to understand React Rendering Pattern, which makes the app slow.

React's rendering issues are composed of three phases as follows:
・Trigger of render: changing of state or props.
・Rendering of components: calling components.
・Committing changes to the DOM.

Most of the issues are involved in the rendering of components, such as unnecessary calling components or too heavy calculations.

React19 introduced the React Compiler that memoizes components and values automatically by applying useMemo and useCallback everywhere it's safe to do so. However, it doesn't solve architectural issues such as overlaying broad context providers or huge component trees.

Unnecessary re-renders

Unnecessary re-renders happen when a component updates even though its props or state haven’t changed, which can introduce delays and make interactions feel sluggish.

Excessive computations

Excessive computations during rendering can block the main thread, causing temporary UI freezes and reducing overall responsiveness.

Rendering large lists

Rendering large lists all at once increases processing time, which can lead to noticeable delays and choppy scrolling.

Context update cascades

When a context value changes, it can trigger re-renders across many components, resulting in slower updates and degraded performance.

Inline function usage

Defining functions inline within components creates new instances on every render, which can add overhead and lead to subtle performance issues.

Deep component trees

Deep component trees increase rendering complexity, which can slow down both initial page load and subsequent updates.

ReactJs Performance Strategy Profiler

Ogasawara Kakeru — Tue, 07 Apr 2026 22:38:26 +0000

You can measure the performance of the app by wrapping the component tree with <Profiler>.

<Profiler id="App" onRender={onRender}>
  <App />
</Profiler>

Props

id: The string that identifies which part of the UI is measured.
onRender: The callback that receives information about what is rendered and how much time is taken.

onRender callback

function onRender(id, phase, actualDuration, baseDuration, startTime, commitTime) {
  // Aggregate or log render timings...
}

params
id: The id property of the <Profiler> corresponding to the tree that was just committed. If you are using multiple profilers, this allows you to identify which tree was committed.

phase: “mount”, ‘update’, or “nested-update”. This indicates whether the tree was mounted for the first time or re-rendered due to changes in props, state, or hooks.

actualDuration: The number of milliseconds the and its child elements spent rendering for the current update. This indicates how effectively the subtree is utilizing memoization (e.g., memo and useMemo). Ideally, this value should decrease significantly after the initial mount as more child elements are rendered only when their props change.

baseDuration: An estimate in milliseconds of the time it would take to re-render the entire subtree without optimizations. It is calculated by summing the time taken for the last render of each component in the tree. This value estimates the worst-case rendering cost of the tree (e.g., during initial mount or when memoization is not used). To verify whether memoization is working, compare this value with actualDuration.

startTime: The timestamp of when React began rendering the current update.

commitTime: The timestamp of when React committed the current update. Since this value is shared across all profilers within a single commit, it can be used for grouping as needed.

Pitfall
Because profiling introduces additional overhead, it is disabled by default in production builds. To perform profiling in a production environment, you must explicitly use a special production build with profiling enabled.

Note
You can use the element to collect measurement results programmatically. If you prefer an interactive profiler, try the Profiler tab in React Developer Tools. It provides similar functionality as a browser extension.