Log in to GraphQL EditorGet started

Tomasz Gajda

2/24/2025

Is React Killing Web Performance?

React has become the dominant force in modern frontend development, powering everything from small startups to massive enterprise applications. Its component-based architecture, declarative approach, and extensive ecosystem make it a favorite among developers. But as React applications grow in complexity, so do concerns about performance. Are we trading speed and efficiency for the convenience of React? Or is React unfairly blamed for performance issues that stem from improper usage? Let’s break it down.

1. Virtual DOM Overhead and Re-renders

One of React’s biggest selling points is its Virtual DOM, which minimizes direct DOM manipulations by batching updates. In theory, this leads to better performance. However, in practice, inefficient state management and unnecessary re-renders can lead to sluggish apps.

Consider a common mistake: unnecessary state updates triggering frequent re-renders.

const [count, setCount] = useState(0);

const increment = () => {
  setCount(count + 1); *// Causes component re-render every click*
};

return (
  <button onClick={increment}>Clicked {count} times\</button>
);

This may seem harmless, but imagine a scenario where a large component tree is being re-rendered unnecessarily because of a deeply nested state update. The performance impact compounds quickly.

Another example is passing new object references as props, causing child components to re-render when they don’t need to:

const Parent = () => {
  const data = { value: 42 }; // New object reference on every render
  return <Child data={data} />;
};

Using useMemo or useCallback can help mitigate these issues.

2. Optimizations Exist, But They’re Underused

React provides several built-in tools to improve performance, yet many developers either don’t use them or misuse them. Features like memoization (React.memo, useMemo, useCallback), lazy loading (React.lazy, Suspense), and code splitting can significantly boost app speed, but they require conscious effort. For example, memoizing components prevents unnecessary re-renders:

const Child = React.memo(({ data }) => {
  console.log("Rendering Child");
  return <div>{data.value}\</div>;
});

Yet, many React apps don’t implement these optimizations, leading to bloated and sluggish interfaces. React itself isn’t slow—it’s the way we use it.

For a deeper dive into React performance optimizations, check out my blog post: React Performance Optimization Strategies.

3. Over-Reliance on Client-Side Rendering

One of React’s biggest performance drawbacks stems from client-side rendering (CSR). In CSR-heavy applications, the browser must download JavaScript, execute it, and then render the page, leading to slow time-to-first-paint and poor SEO.

This is where frameworks like Next.js and Remix step in, offering server-side rendering (SSR) and static site generation (SSG) to mitigate React’s rendering delays. Consider the difference:

  • CSR (Traditional React SPA): Blank screen → Load JS → Render content
  • SSR (Next.js): Server sends pre-rendered content → Hydrate on client
  • SSG (Next.js, Astro): Pre-built pages served instantly

Adopting SSR/SSG can significantly improve perceived performance, yet many teams continue to build monolithic SPAs that struggle with load times.

4. Is React the Problem, or Are We the Problem?

React itself isn’t inherently slow—poor implementation is. The real issue is:

  1. Developers ignoring performance best practices (e.g., not memoizing components, inefficient state management).
  2. Overuse of client-side rendering when SSR/SSG could be better suited.
  3. Unnecessary JavaScript bloat—many React projects ship excessive JavaScript due to bundling everything into one massive file.

How to Fix It

  • Use React.memo, useMemo, and useCallback to prevent unnecessary renders.
  • Prefer server-side rendering (SSR) or static generation (SSG) for faster initial loads.
  • Reduce bundle size with code splitting, tree shaking, and lazy loading.
  • Avoid excessive global state—use context selectively and rely on local state where possible.

Profile and debug with React DevTools, checking for unnecessary renders.

5. Verdict: React Isn’t the Villain - Bad Practices Are

React isn’t killing web performance—poor optimization habits are. When used correctly, React can deliver highly performant applications. But developers need to take responsibility for how they structure state, manage rendering, and ship JavaScript.

So, is React slow? Not inherently. However, if your React application is experiencing performance issues, it may be worth evaluating your implementation.

Check out our other blogposts

Is React Killing Web Performance?
Tomasz Gajda
Tomasz Gajda
Is React Killing Web Performance?
1 min read
1 day ago
Redux Isn’t Dead, You’re Just Using It Wrong
Tomasz Gajda
Tomasz Gajda
Redux Isn’t Dead, You’re Just Using It Wrong
1 min read
29 days ago
GraphQL cache: using LRU cache with GraphQL Zeus
Michał Tyszkiewicz
Michał Tyszkiewicz
GraphQL cache: using LRU cache with GraphQL Zeus
1 min read
2 months ago

Ready for take-off?

Elevate your work with our editor that combines world-class visual graph, documentation and API console

Get Started with GraphQL Editor