We're talking performance today.

And before you scroll away thinking "yeah yeah, lazy load your images, use a CDN" — I promise this is not that blog. We're going deeper. We're talking about the stuff that actually comes up in system design interviews AND the stuff that makes your production app not feel like garbage.

Let's get into it.

Why Performance Even Matters (Beyond the Obvious)

Here's the real talk: a 1 second delay in page load = ~7% drop in conversions. Google uses Core Web Vitals as a ranking signal. And your users on mobile in tier-2 cities? They're on 4G with 200ms latency. If your app isn't optimized, they're gone.

But in interviews, performance is also where juniors and seniors get separated. A junior says "use lazy loading." A senior says "here's when to use it, why, and what the tradeoff is." That's what we're building today.

The Four Pillars We're Covering Today

1. Virtualization

2. Code Splitting

3. Lazy Loading

4. Bundle Size Optimization

Each one has a when to use it, a how it works, and a real example. Let's go.

1. Virtualization — Don't Render What You Can't See

Imagine you have a list of 10,000 rows in a table. If you render all 10,000 DOM nodes at once, your browser is sweating. FPS drops. Scrolling feels janky. Users hate it.

Virtualization (also called windowing) solves this by only rendering the rows currently visible in the viewport — plus a small buffer above and below.

How it works

You maintain a virtual list. As the user scrolls, you calculate which items should be visible based on scroll position and item height, and only render those. Items that scroll out of view get unmounted (or recycled).

// Without virtualization — renders all 10,000 rows
function BadList({ items }) {
  return (
    <div>
      {items.map(item => <Row key={item.id} data={item} />)}
    </div>
  );
}

// With react-window — only renders ~20 visible rows
import { FixedSizeList } from 'react-window';

function GoodList({ items }) {
  return (
    <FixedSizeList
      height={600}
      itemCount={items.length}
      itemSize={50}
      width="100%"
    >
      {({ index, style }) => (
        <div style={style}>
          <Row data={items[index]} />
        </div>
      )}
    </FixedSizeList>
  );
}

When to use it

• Lists with 100+ items that users scroll through

• Data tables, feeds, chat history, autocomplete dropdowns with many results

The tradeoff

Virtualization adds complexity. For small lists (under 50 items), it's overkill. Don't over-engineer.

2. Code Splitting — Don't Ship What You Don't Need Yet

By default, a React app bundles everything into one giant JS file. User lands on your home page? They're downloading code for your settings page, your admin dashboard, and that feature you shipped last quarter that nobody uses.

Code splitting breaks your bundle into smaller chunks that load on demand.

How it works in React

React has React.lazy and Suspense built-in for this.

import React, { Suspense, lazy } from 'react';

// Before — eagerly loaded, always in bundle
import HeavyDashboard from './HeavyDashboard';

// After — lazily loaded, separate chunk
const HeavyDashboard = lazy(() => import('./HeavyDashboard'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <HeavyDashboard />
    </Suspense>
  );
}

Vite and webpack both handle the actual chunk splitting automatically once you use dynamic imports.

Route-based splitting — the most common pattern

import { lazy, Suspense } from 'react';
import { Routes, Route } from 'react-router-dom';

const Home = lazy(() => import('./pages/Home'));
const Dashboard = lazy(() => import('./pages/Dashboard'));
const Settings = lazy(() => import('./pages/Settings'));

function App() {
  return (
    <Suspense fallback={<PageLoader />}>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/dashboard" element={<Dashboard />} />
        <Route path="/settings" element={<Settings />} />
      </Routes>
    </Suspense>
  );
}

Now each route is its own chunk. User never visits settings? Settings code never downloads.

When to use it

• Route-level splitting: always, almost no downside

• Component-level: heavy components like rich text editors, charts, map libraries

• Feature flags: code behind a flag shouldn't be in the main bundle

3. Lazy Loading — Images and Components on Demand

We covered component lazy loading above. But images are actually where lazy loading has the biggest impact for most apps.

Native lazy loading (just use this)

<img src="product.jpg" alt="Product" loading="lazy" />

That's it. The browser handles it. It defers loading images that are below the fold until the user scrolls near them. Zero JS required.

Intersection Observer — when you need control

For more custom behaviour (like infinite scroll, or lazy loading non-image content), use the Intersection Observer API.

import { useEffect, useRef, useState } from 'react';

function LazyImage({ src, alt }) {
  const imgRef = useRef(null);
  const [isVisible, setIsVisible] = useState(false);

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]) => {
        if (entry.isIntersecting) {
          setIsVisible(true);
          observer.disconnect(); // stop observing once loaded
        }
      },
      { threshold: 0.1 }
    );

    if (imgRef.current) observer.observe(imgRef.current);
    return () => observer.disconnect();
  }, []);

  return (
    <div ref={imgRef}>
      {isVisible
        ? <img src={src} alt={alt} />
        : <div className="placeholder" />
      }
    </div>
  );
}

The threshold option

threshold: 0.1 means "trigger when 10% of the element is visible." Set it higher (0.5) for elements you want mostly in view before loading.

4. Bundle Size — The Invisible Performance Tax

Your bundle size is a silent killer. Every kb of JS has to be:

• Downloaded over the network

• Parsed by the browser

• Compiled and executed

A 500kb bundle vs a 200kb bundle isn't just a download difference — the parse and execution time on a mid-range Android phone can differ by seconds.

Check your bundle first

Don't optimise blindly. Use rollup-plugin-visualizer with Vite:

// vite.config.js
import { visualizer } from 'rollup-plugin-visualizer';

export default {
  plugins: [
    visualizer({ open: true }) // opens a treemap of your bundle after build
  ]
}

Run npm run build and it opens a visual breakdown. You'll probably find one library eating 40% of your bundle.

Common culprits and fixes

Moment.js — 67kb gzipped just for date formatting. Replace with date-fns (tree-shakeable, you only import what you use) or dayjs (2kb).

// Bad — imports entire moment library
import moment from 'moment';

// Good — tree-shakeable, only imports format
import { format } from 'date-fns';

Lodash — don't import the whole thing.

// Bad — imports entire lodash
import _ from 'lodash';
_.debounce(fn, 300);

// Good — only imports debounce
import debounce from 'lodash/debounce';

Icon libraries — importing from @mui/icons-material wrongly can pull in thousands of icons.

// Bad — might import entire icon set depending on bundler config
import { Delete } from '@mui/icons-material';

// Good — direct import, guaranteed single icon
import DeleteIcon from '@mui/icons-material/Delete';

Tree shaking — make sure it's working

Tree shaking removes unused exports from your bundle. It only works with ES modules (import/export). If a library uses CommonJS (require), it can't be tree-shaken.

Check package.json of your dependency for "module" or "exports" field — that's a sign it supports ESM and tree shaking.

Putting It All Together — Interview Answer Framework

When a system design interviewer asks about performance, don't just list techniques. Structure your answer:

1. Identify the bottleneck first

• Is it initial load time? → Code splitting, bundle size

• Is it runtime rendering? → Virtualization, memoization

• Is it network? → Lazy loading, caching, CDN

2. Propose the solution with the tradeoff

• "I'd use virtualization here because we have 10k rows — the tradeoff is added complexity but the rendering performance gain is worth it."

3. Mention metrics

• LCP (Largest Contentful Paint) — loading

• FID/INP (Interaction to Next Paint) — interactivity

• CLS (Cumulative Layout Shift) — visual stability

Saying "I'd measure this with Lighthouse and set a performance budget" puts you ahead of 90% of candidates.

Quick Summary

What's Next

Day 5 we're going into state management patterns — when to use local state vs context vs Redux vs Zustand, and how to think about this in a system design interview without just saying "it depends."

If this helped, drop a reaction or share it with someone grinding frontend interviews. And if you disagree with anything here — good, argue with me in the comments. That's how we both learn.

I used to build components in one big blob. Everything in one file — state, logic, markup, API calls. It worked. Until someone asked me to reuse just part of it somewhere else, and I realised I had no idea how to do that cleanly.

That's what component design patterns solve. They're not fancy abstractions for the sake of it — they're answers to real problems you will hit as your codebase grows. And they come up in frontend system design interviews all the time, so worth knowing properly.

Three patterns I think every React dev should have in their toolkit: custom hooks, compound components, and render props. Let's go through each one with real examples.

Pattern 2 — Custom hooks

The problem: You have the same stateful logic copy-pasted across 5 components. A fetch call, a debounce, a form handler. Every time you fix a bug in one, you forget to fix the other four.

The solution: Extract it into a custom hook.

// hooks/useFetch.ts
function useFetch<T>(url: string) {
  const [data, setData] = useState<T | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    fetch(url)
      .then(res => res.json())
      .then(setData)
      .catch(setError)
      .finally(() => setLoading(false));
  }, [url]);

  return { data, loading, error };
}

Now any component can just:

const { data, loading, error } = useFetch<User[]>('/api/users');

The component has no idea how fetching works. It just gets the result. Change the fetch logic once in useFetch and every component using it gets the fix automatically.

Rule of thumb: If you're copying stateful logic (anything using useState or useEffect) between components, that's a custom hook waiting to be extracted.

Pattern 2 — Compound components

The problem: You're building a <Tabs> component. You want the API to feel natural and flexible — consumers should be able to control what tabs show up, what order they're in, maybe add custom content between them. But you also don't want to pass 15 props into one giant component.

The solution: Compound components — a parent that owns shared state, and child components that consume it via context.

// The parent holds state and provides context
const TabsContext = createContext(null);

function Tabs({ children }) {
  const [active, setActive] = useState(0);
  return (
    <TabsContext.Provider value={{ active, setActive }}>
      <div>{children}</div>
    </TabsContext.Provider>
  );
}

// Children consume the context
function Tab({ index, children }) {
  const { active, setActive } = useContext(TabsContext);
  return (
    <button
      onClick={() => setActive(index)}
      style={{ fontWeight: active === index ? 600 : 400 }}
    >
      {children}
    </button>
  );
}

function TabPanel({ index, children }) {
  const { active } = useContext(TabsContext);
  return active === index ? <div>{children}</div> : null;
}

// Attach children as properties (optional but common)
Tabs.Tab = Tab;
Tabs.Panel = TabPanel;

Usage feels completely natural:

<Tabs>
  <Tabs.Tab index={0}>Overview</Tabs.Tab>
  <Tabs.Tab index={1}>Settings</Tabs.Tab>

  <Tabs.Panel index={0}>Overview content here</Tabs.Panel>
  <Tabs.Panel index={1}>Settings content here</Tabs.Panel>
</Tabs>

You've seen this pattern in the wild — Radix UI, Headless UI, Reach UI all use it heavily. It's why their component APIs feel so clean.

Rule of thumb: If you're building a UI component where the consumer should control structure and composition, reach for compound components.

Pattern 3 — Render props

The problem: You have logic that produces some data or state, and you want to let the consumer decide how to render it. Not just what data to show, but how to show it — completely different UI in different contexts.

The solution: Render props — pass a function as a prop, call it with the data, let the consumer return whatever JSX they want.

function MouseTracker({ render }) {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  return (
    <div onMouseMove={e => setPosition({ x: e.clientX, y: e.clientY })}>
      {render(position)}
    </div>
  );
}

Consumer decides the UI completely:

<MouseTracker render={({ x, y }) => (
  <p>Mouse is at {x}, {y}</p>
)} />

// Or somewhere else, totally different UI:
<MouseTracker render={({ x, y }) => (
  <Cursor style={{ left: x, top: y }} />
)} />

Same logic, completely different rendering. That's the power of render props.

These days, custom hooks have largely replaced render props because hooks are cleaner. But render props still show up in older codebases and in some specific scenarios — like when you need the rendered output to be tightly coupled to DOM events. Worth knowing.

Rule of thumb: If you need to share logic where the consumer needs full control over what gets rendered, render props (or a custom hook returning data) work well.

When to use which

The honest answer is — most of the time, you'll reach for custom hooks. They're the cleanest, most composable, and easiest to test. Compound components are your go-to for complex UI components. Render props are worth understanding for interviews and legacy code.

Why this matters for system design interviews

When you're designing a component library or a design system in an interview, the interviewer wants to see that you think about API design — not just "does it work" but "is it easy to use, flexible, and maintainable."

Compound components show you've thought about the consumer's experience. Custom hooks show you separate logic from UI. These signals require senior-level thinking.

What's next

Day 4 is going into performance patterns — virtualization, code splitting, lazy loading, and how to think about bundle size. Stuff that actually moves the needle in production apps.

If you've used any of these patterns in production and run into edge cases, drop them in the comments — I'm genuinely curious what breaks in the real world.

I spent two days last week staring at the React Profiler, wondering why a simple filter dropdown was causing 47 components to re-render. Forty-seven. For a dropdown.

That's when I stopped just using React and started actually understanding how it works under the hood. Turns out, a lot of the "mysterious" performance issues make complete sense once you get the rendering model. Let's break it down.

First — what even is a "render"?

In React, a render is just React calling your component function. That's it. When React renders <UserCard />, it literally runs the UserCard function and looks at what JSX came out.

People think rendering = DOM update. It doesn't. Rendering is React running your function. Updating the DOM is a separate step that only happens if something actually changed.

This distinction matters a lot.

What triggers a re-render?

Three things cause React to re-render a component:

1. State changes — you call setState or dispatch to a reducer. React re-renders that component and everything below it in the tree.

2. Props changes — when a parent re-renders, all its children re-render too. Even if the child's props didn't change. Yes, really.

3. Context changes — if a useContext value updates, every component consuming that context re-renders. The diagram above shows the full flow. Notice there's no "props actually changed" check by default — React just re-renders the whole subtree. This is where most performance issues come from.

The render, reconcile, commit cycle

Once React decides to render, here's what happens:

Render phase — React calls your component function and builds a new virtual DOM tree. This is pure JavaScript, nothing touches the browser yet.

Reconciliation — React compares the new virtual DOM with the previous one. This is the "diffing" step. React figures out the minimum set of changes needed.

Commit phase — React applies those changes to the actual DOM. This is the expensive step, but React tries to minimize it.

The key insight: just because React renders your component doesn't mean it updates the DOM. If nothing visually changed, the commit phase does nothing. Renders are cheap. DOM updates are expensive.

The re-render problem in real life

Here's a pattern I see everywhere — and had in my own code:

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

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>Click me</button>
      <ExpensiveChild />  {/* re-renders every time count changes */}
    </div>
  );
}

Every time you click the button, ExpensiveChild re-renders — even though it has nothing to do with count. React doesn't know that. It just sees "parent rendered, re-render all children."

Fix 1 — React.memo

Wrap the child in React.memo and React will skip re-rendering it if its props haven't changed:

tsx

const ExpensiveChild = React.memo(() => {
  return <div>I only render when my props change</div>;
});

Now clicking the button won't touch ExpensiveChild at all. But there's a catch — if you're passing a function or object as a prop, this breaks down fast.

Fix 2 — useCallback for stable function references

tsx

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

  const handleClick = useCallback(() => {
    console.log('clicked');
  }, []); // stable reference across renders

  return <ExpensiveChild onClick={handleClick} />;
}

Without useCallback, handleClick is a brand new function object on every render. React.memo sees a new prop value and re-renders anyway. useCallback gives you the same function reference between renders so the memo check actually works.

Fix 3 — useMemo for expensive calculations

tsx

const filteredList = useMemo(() => {
  return hugeList.filter(item => item.active);
}, [hugeList]);

Don't run this on every render. Memoize it and only recalculate when hugeList actually changes.

When NOT to memoize

This is the part nobody talks about — memoization has a cost too.

React has to store the previous value, run the comparison, and decide whether to use the cached result. For simple components and cheap calculations, this overhead is often more expensive than just re-rendering.

My rule of thumb:

• React.memo → only for components that render often AND are expensive to render

• useMemo → only for genuinely expensive calculations (think filtering/sorting 1000+ items)

• useCallback → mostly when passing callbacks to memoized children or as useEffect deps

Don't sprinkle these everywhere "just in case." Profile first, optimize second.

How to actually find the problem — React Profiler

Stop guessing. Open React DevTools, go to the Profiler tab, hit record, interact with your app, and stop recording.

You'll see a flamegraph showing exactly which components rendered and how long each one took. The bars that are wide and re-render repeatedly are your targets.

I found my 47-component re-render problem in about 3 minutes with the Profiler. Turned out a context value was being recreated on every render because the object wasn't memoized. One useMemo fixed it.

The mental model to remember

React rendering is a pull system, not a push system. When state changes, React doesn't surgically update just the affected component — it re-runs the entire subtree from that point downward, then figures out what actually needs to change in the DOM.

Your job as a developer is to give React hints — via memo, useCallback, useMemo — about what hasn't changed so it can skip work.

But don't optimize blindly. Profile first, find the actual bottleneck, then apply the right fix.

What's next

Day 3 is going to be on component design patterns — specifically compound components, render props, and custom hooks, and when to reach for each one. These patterns come up a lot in system design interviews so worth understanding properly.

Drop a comment if the Profiler thing clicked for you — or if you've had a wild re-render bug I should know about.

Day 1 — Designing Scalable Frontend Architecture

When I first started building frontend apps, everything was fine. Components worked, state was managed, API calls happened. Then the app grew. And one day I opened the codebase and thought — what the hell is going on here.

Components were 400 lines long. State was scattered everywhere. Three different places were calling the same API. Debugging meant spelunking through files with no idea where something lived.

That's when it clicked for me — frontend architecture isn't just about writing clean code, it's about designing a system that doesn't collapse under its own weight.

This is blog #1 of my series documenting what I'm learning from GreatFrontend. Let's get into it.

What even is frontend architecture?

It's the set of decisions you make before writing a single component — how you'll organize code, manage state, handle data fetching, and structure folders — so that when the app grows, it stays maintainable.

The goal isn't perfection. It's making sure that six months later, a new dev (or future-you) can open the codebase and not immediately want to quit.

Good frontend architecture is:

Scalable — adding features doesn't require rewriting existing ones

Maintainable — bugs are easy to find and fix

Collaborative — multiple people can work without constantly stepping on each other

Step 1: Think in layers

The single most useful mental model I've internalized is: separate your concerns into layers. Every frontend app can be broken into three:

The diagram above shows how these layers talk to each other — and more importantly, what they don't do. The UI layer never calls an API directly. That's the rule.

The moment you call fetch('/api/users') inside a component, you've created a hidden dependency. Change the API? Now you're hunting through 12 components. Put it in the data layer, and you change it in one place.

Step 2: Folder structure that doesn't fight you

Most beginner projects look like this:

components/
utils/
pages/

It works for a week. Then components/ has 60 files and you spend more time finding things than building them.

The better approach is feature-based architecture:

features/
  auth/
    components/    ← auth-specific UI
    hooks/         ← useLogin, useLogout
    services/      ← authService.ts
  cart/
    components/
    hooks/
    services/
shared/
  ui/              ← Button, Modal, Input (reusable anywhere)
  utils/
  constants/

Everything related to auth lives in features/auth/. When a new dev joins and needs to touch auth logic, they know exactly where to look. When you delete a feature, you delete one folder.

The shared/ folder is for stuff that genuinely has no business logic — pure UI components, utility functions, constants. If it's in shared/, it should have zero knowledge of your app's domain.

Step 3: State management — don't overthink it

I see a lot of people reach for Redux on day one. You don't need it. Use the simplest thing that works, and upgrade when you actually feel the pain.

Here's the decision tree I use:

• useState → local component UI state (is this dropdown open? what's in this input field?)

• Context / Zustand → state shared across multiple components (user auth, theme, cart)

• React Query / TanStack Query → anything that comes from a server

Concrete example — an e-commerce app:

• Cart items → Zustand (global, client-owned state)

• Product list → React Query (server state, needs caching + refetching)

• "Is the filter dropdown open?" → useState (local, nobody else cares)

The common mistake is using useState for everything, then prop-drilling 5 levels deep. Or worse, putting everything in Redux, including whether a tooltip is visible. Global state is expensive to maintain — only put things there that genuinely need to be global.

Step 4: The API layer — build a service layer

Never, ever call fetch directly in a component. Build a service layer instead.

// services/userService.ts
export const getUser = async (id: string) => {
  const res = await fetch(`/api/users/${id}`);
  if (!res.ok) throw new Error('Failed to fetch user');
  return res.json();
};

Then wrap it in a hook using React Query:

// hooks/useUser.ts
import { useQuery } from '@tanstack/react-query';
import { getUser } from '../services/userService';

export const useUser = (id: string) => {
  return useQuery({
    queryKey: ['user', id],
    queryFn: () => getUser(id),
  });
};

And in your component:

// components/UserProfile.tsx
const { data: user, isLoading } = useUser('123');

The component has no idea how the data gets fetched. It just asks for it. This is the separation of concerns in action — and it makes testing dramatically easier.

Step 5: Performance basics

A few rules that apply to almost every React app:

Lazy load your routes. Don't ship the entire app in one bundle.

const Dashboard = React.lazy(() => import('./pages/Dashboard'));

Don't re-render what doesn't need to be re-rendered. React.memo on expensive components that receive the same props frequently:

const ExpensiveChart = React.memo(({ data }) => {
  // only re-renders if `data` changes
});

Memoize expensive calculations with useMemo. Memoize stable function references with useCallback (especially when passing to child components or as useEffect deps).

These aren't premature optimizations if you're building something that's going to grow — they're just good habits.

Step 6: Testing strategy (the short version)

Three levels:

Three levels:

• Unit tests → individual functions, hooks, pure logic

• Integration tests → user flows across multiple components (login form → redirects to dashboard)

• E2E tests → full user journeys in a browser (Cypress/Playwright)

You don't need 100% coverage. But having some integration tests for your critical paths (checkout, auth, core feature) will save you from shipping broken stuff.

Common mistakes I see (and have made)

❌ API calls inside components — the #1 offender. Ties your UI directly to your data source.

❌ Everything in global state — modal open state does not need to be in Redux. I promise.

❌ Flat folder structure — works until it doesn't. Plan for scale from the start.

❌ Mixing UI and logic in the same component — a 300-line component that fetches data, transforms it, handles errors, and renders a table is doing too much.

The mental model I keep coming back to

Frontend architecture is just one question, asked repeatedly: "Which layer does this belong to?"

If it renders → UI layer.

If it's a shared state → state layer.

If it talks to an API → data layer.

Everything else is details.

What's next

In the next post, I'm diving into how React's rendering actually works — what triggers a re-render, what doesn't, and how to read the React Profiler to find where your app is slow. That one's going to be very hands-on because I've been debugging a gnarly re-render issue at work for the past few weeks.

If you're learning frontend system design too, drop a comment — I would love to know what topics you're finding most confusing.