9 Tips for Data-Heavy, Performant Frontend Development in React

1. Design With Performance in Mind From Day One

For this one, I want to start with an example.

I had this dashboard that used Vis.js as a graph visualization library. If you don’t know (as I didn’t back then), Vis.js uses the Canvas API for rendering. Which, for the most part, shouldn’t be a problem. A lot of data visualization libraries also use Canvas API.

Except when you have 5000 nodes and thousands more edges between them.

If you want to see how bad the performance was, you can check out this demo. Just type out ‘5000’ in the number of nodes. Also, keep in mind that my network visualization was not as simple as this demo.

I had to replace this heavily customized Vis.js component with another network visualization library, Sigma.js. Sigma.js uses WebGL instead of Canvas API, which for my case made tremendous difference as it’s rendering and physics pipeline is non-blocking. It also has a very nice React wrapper.

If you are also interested in seeing Sigma.js under heavy load, you can check out this demo. Click on “start layout” for physics performance.

The lesson that I am trying to portray with this story is this: Beforehand, if I researched and made sure that Vis.js complied with my requirements; I wouldn’t have to do all the work switching back. And the thing is that I was actually lucky enough that I was not deep enough in my project that I was able to switch back. You may not be.

Quite literally best thing you can do for performance is thinking ahead. The worst issues I had with performance happened because I didn’t think ahead. Assume the worst case. Also, your future self will thank you. Think about performance early, before problems arise.

❌ Incorrect:

• Do everything as they come
• Don’t make any plans

✅ Correct:

• Think ahead: “What happens when this has 100K rows/nodes?”
• Design your UI/UX to be scalable (e.g., think about filters, tabs, summaries instead of dumping all the data at once).
• Talk to your backend team (or your future self) early about pagination, indexes, and filtering.

2. Avoid Unnecessary Renders

Super critical to understand and internalize. Always happens, and hard to keep it on check.

React re-renders can sneak up on you. Especially when you’re juggling a dozen interdependent components, super deep prop-drills that cause expensive re-renders, and state flying around in complete chaos (Speaking from experience 😥).

Profiling your app with the React DevTools profiler or even newer tools like Million.js can help catch components that are rendering more than they should. But profiling only helps you see the issue: State architecture is the real battleground.

1
const AppContext = createContext();
2

3
const AppProvider = ({ children }) => {
4
  const [largeData, setLargeData] = useState(generateBigData());
5
  const [currentPage, setCurrentPage] = useState(0);
6
  const [user] = useUser();
7
  const [theme] = useTheme();
8
  return (
9
    <AppContext.Provider value={{largeData, setLargeData, currentPage, setCurrentPage, user, theme}}>
10
      {children}
11
    </AppContext.Provider>
12
  );
13
};
14

15
const TableWrapper = () => {
16
  const {largeData, currentPage, setCurrentPage} = useContext(TableDataContext);
17
  return <Table data={largeData} page={currentPage} setPage={setCurrentPage}/>
18
}
19

20
const OtherComponent = () => {
21
    const {user, theme} = useContext(AppContext);
22
  return (
23
    <h1 style={{...theme}}>
24
      Hello {user}!
25
    </h1>
26
  )
27
}
28

29
const App = () => {
30
  return (
31
    <AppProvider>
32
      <OtherComponent/>
33
      <TableWrapper>
34
      <TableWrapper>
35
    </AppProvider>
36
  )
37
}

1
const TableDataContext = createContext();
2
const AppContext = createContext();
3

4
const TableDataProvider = ({ children }) => {
5
  const [largeData, setLargeData] = useState(generateBigData());
6
  const [currentPage, setCurrentPage] = useState(0);
7
  return (
8
    <TableDataContext.Provider value={{largeData, setLargeData, currentPage, setCurrentPage}}>
9
      {children}
10
    </TableDataContext.Provider>
11
  );
12
};
13

14
const AppProvider = ({ children }) => {
15
  const [user] = useUser();
16
  const [theme] = useTheme();
17
  return (
18
    <AppContext.Provider value={{user, theme}}>
19
      {children}
20
    </AppContext.Provider>
21
  );
22
};
23

24
const TableWrapper = () => {
25
  const {largeData, currentPage, setCurrentPage} = useContext(TableDataContext);
26
  return <Table data={largeData} page={currentPage} setPage={setCurrentPage}/>
27
}
28

29
const OtherComponent = () => {
30
  const {user, theme} = useContext(AppContext);
31
  return (
32
    <h1 style={{...theme}}>
33
      Hello {user}!
34
    </h1>
35
  )
36
}
37

38
const App = () => {
39
  return (
40
    <AppProvider>
41
      <OtherComponent/>
42
      <TableDataProvider>
43
        <TableWrapper>
44
        <TableWrapper>
45
      </TableDataProvider>
46
    </AppProvider>
47
  )
48
}

1
const useStore = create((set) => ({
2
  data: [],
3
  largeData: null,
4
  setLargeData: (data) => set({ largeData: data }),
5
}));
6

7
// This component will only re-render if largeData changes
8
const TableWrapper = () => {
9
  const largeData = useStore((state) => state.selectedItem);
10
  return <Table data={largeData}/>;
11
};

3. Paginate or Virtualize Large Lists and Tables

Don’t render 100,000 items at once. Your browser and your users will thank you.

“So, how will I show my list/table containing 100,000 users then?”, I can hear you ask.

My advice:

• Use libraries like react-virtual or react-window to only render visible elements. This is called virtualization.
• Or, if you are making a table, just use tools like Material React Table or TanStack Table to have virtualization and pagination built in.

❌ Incorrect:

1
return (
2
  <div>
3
    {bigList.map(item => (
4
      <div key={item.id}>{item.name}</div>
5
    ))}
6
  </div>
7
);

✅ Correct:

1
import { useVirtualizer } from '@tanstack/react-virtual';
2

3
const VirtualList = ({ bigList }) => {
4
  const parentRef = useRef();
5

6
  const rowVirtualizer = useVirtualizer({
7
    count: bigList.length,
8
    getScrollElement: () => parentRef.current,
9
    estimateSize: () => 35,
10
  });
11

12
  return (
13
    <div ref={parentRef} style={{ height: '400px', overflow: 'auto' }}>
14
      <div style={{ height: rowVirtualizer.getTotalSize(), position: 'relative' }}>
15
        {rowVirtualizer.getVirtualItems().map(virtualRow => {
16
          const item = bigList[virtualRow.index];
17
          return (
18
            <div
19
              key={item.id}
20
              style={{
21
                position: 'absolute',
22
                top: 0,
23
                left: 0,
24
                height: 35,
25
                transform: `translateY(${virtualRow.start}px)`,
26
              }}
27
            >
28
              {item.name}
29
            </div>
30
          );
31
        })}
32
      </div>
33
    </div>
34
  );
35
};

4. Flatten and Normalize Your Data

Deeply nested objects are hard to manage and update efficiently. Flattening makes data manipulation and rendering easier.

This process is particularly useful when you’re working with large datasets, as it allows for better performance and easier updates.

Think about it like this: JavaScript objects are basically maps. Let’s assume you are trying to access an element 3 objects deep. You have to do 3 lookup operations just to access this data. If your object were to be flat, you would be able to access this data in a single lookup.

Also, keeping nested objects/arrays are very memory inefficient, especially for JavaScript.

❌ Incorrect:

1
const user = {
2
  id: '1',
3
  profile: {
4
    name: 'Jane',
5
    address: {
6
      city: 'Istanbul'
7
    }
8
  }
9
};
10

11
const city = user.profile.address.city;

✅ Correct:

1
const normalizedUser = {
2
  id: '1',
3
  name: 'Jane',
4
  city: 'Istanbul'
5
};
6

7
const city = normalizedUser.city;

5. Debounce or Throttle Expensive Updates

Real-time input can bottleneck performance. Debounce user input when filtering or processing data.

This tip is also super critical if there is some kind of API call being made with real-time input, such as a search suggestion or filtered table data.

❌ Incorrect:

1
<input onChange={(e) => filterData(e.target.value)} />

✅ Correct:

1
import debounce from 'lodash.debounce';
2

3
const debouncedFilter = useMemo(() => debounce(filterData, 300), []);
4

5
<input onChange={(e) => debouncedFilter(e.target.value)} />

6. Use Web Workers for Heavy Computation

If you remember (or have read and not skipped it) from the first section, I talked about how I solved my performance issue about Vis.js by switching to another library. The following tip, web workers, was one of the main reasons why I did so.

Sigma.js uses Graphology, which in turn uses Web Workers for physics simulation. This kept rest of the app responsive even if there were tremendous amounts of nodes on the graph.

Heavy calculations on the main thread block the UI. Offload to a Web Worker to keep the app responsive.

❌ Incorrect:

1
const result = heavyCalculation(data); // UI freezes

✅ Correct:

1
self.onmessage = (e) => {
2
  const result = heavyCalculation(e.data);
3
  self.postMessage(result);
4
};
5

6
// In component
7
// ...
8
const worker = new Worker(new URL('./worker.js', import.meta.url));
9
worker.postMessage(data);
10
worker.onmessage = (e) => setResult(e.data);
11
// ...

7. Don’t Abuse State

Probably one of the easiest to understand/implement of these tips.

Don’t get me wrong, the WYSIWYG principle of React is really nice. But, not everything needs to live in state. Use refs or memoized values for static data or computed values.

If you are confused about when to use refs and when to use state, check out this post from React team.

❌ Incorrect:

1
const [items, setItems] = useState(bigDataArray); // huge array in state

✅ Correct:

1
const itemsRef = useRef(bigDataArray); // store in ref if no reactivity needed
2

3
const items = useMemo(() => processData(bigDataArray), [bigDataArray]);

8. Keep an Eye on Bundle Size

Import only what you use. Large libraries can bloat your app and hurt load times.

This tip might be redundant depending on how smart your build tool or how critical the loading time is. Still, a little extra optimization never hurts.

❌ Incorrect:

1
import * as d3 from 'd3'; // everything, even unused modules

✅ Correct:

1
import { scaleLinear } from 'd3-scale';
2
import { select } from 'd3-selection';

9. Profile, Profile, Profile

Guessing where the slowdown is? Don’t. Use profiling tools to find the real bottlenecks.

Profiling will not only speed up your application as is, it will reveal future bottlenecks before they even emerge and when they are easier to fix.

❌ Incorrect:

• “It seems fast enough to me.” 🙈

✅ Correct:

• Profile your app with the React DevTools profiler or even newer tools like Million.js.

Wrap-Up

Every one of these performance tips comes from personal experiences where either I hit a wall and had to take a step back and think about things; or after realizing my mistake, when I had to rewrite A LOT of my code for performance fixes.

If you’re building data-heavy UIs in React, I would heavily suggest keeping these in mind, as it will absolutely save your app and your sanity.

Happy shipping! 🛳️✨

Çağan