DEV Community

Cover image for What’s the Fastest React Data Grid? Let’s Find Out (Benchmarks)
Sylwia Laskowska
Sylwia Laskowska Community Curator

Posted on

What’s the Fastest React Data Grid? Let’s Find Out (Benchmarks)

Web development has changed a lot. We have LLMs, AI-assisted coding, etc. But some things remain the same: architecture and performance. And one of the classic problems in many applications is presenting large amounts of data, which eventually leads to choosing the right data grid.

I've always been surprised by how quickly this happens. You start working on a seemingly simple application, and a few months later you realize that, sorry, a regular HTML table just doesn't cut it anymore. You need something more serious.

Of course, no reasonable developer is going to build an enterprise-grade data grid from scratch. Your job is to focus on your business domain and use tools that have already been built, optimized, and battle-tested for problems like this.

Luckily, we have plenty of grids to choose from.

So imagine you're building a React application and need to choose a data grid. Which of the popular options available today is actually the fastest?

Six Contenders

This article was created in collaboration with 1771 Technologies, the creators of LyteNyte Grid. We'll put LyteNyte up against the five most downloaded React data grids on npm that meet the benchmark requirements.

So our six contenders are:

  • LyteNyte Grid — a performance-focused React data grid developed by 1771 Technologies.
  • AG Grid — probably one of the best-known enterprise data grids, with support for multiple frameworks.
  • MUI X Data Grid — the data grid from the Material UI ecosystem, with both free and commercial editions.
  • DevExtreme — DevExpress's component suite, which includes a feature-rich React data grid.
  • Handsontable — a spreadsheet-like data grid with a strong focus on editing and Excel-like interactions.
  • Material React Table — a popular React data grid built on top of TanStack Table and Material UI.

1771 Technologies set out to demonstrate that their grid is the fastest. To do that, they created a whole suite of benchmarks comparing rendering performance across different operations and dataset sizes. Sometimes with frankly absurd amounts of data.

And yes: these benchmarks were created by the company whose grid wins them. There is, however, a rather important detail. The entire benchmark suite is open source. You can inspect the methodology, download the code, modify the tests, and run everything yourself. In fact, the authors explicitly encourage you to reproduce the benchmarks and draw your own conclusions.

Which is exactly what I did. But we'll get to that in a moment.

Check out the original benchmark repository on GitHub

Official Results: Who Won?

The original benchmark contains 13 scenarios covering vertical scrolling, sorting, filtering, pinned rows and columns, horizontal scrolling, and full dataset updates. Tests start at 10,000 rows and, in the most extreme case, go all the way to one million rows.

Scrolling

This is where LyteNyte Grid achieved some of its most spectacular results.

In the official benchmark environment, LyteNyte maintained approximately 60 FPS across every tested dataset size, including one million rows.

MUI and AG Grid were much closer at smaller scales, but their performance decreased as the datasets grew. At one million rows, MUI dropped to around 33 FPS, while AG Grid reached around 27 FPS. DevExtreme stayed relatively consistent but much slower, while Material React Table recorded the lowest scrolling FPS. Handsontable couldn't complete the largest tests on the benchmark machine because of memory limitations.

Scrolling performance

Sorting & Filtering

Sorting was more demanding for everyone.

No grid maintained 60 FPS across all sorting scenarios, but LyteNyte still delivered the highest performance at every tested dataset size. AG Grid scaled particularly well between 50K and 100K rows, while Handsontable's performance dropped significantly as the dataset grew.

Sorting performance

Filtering showed a similar pattern. At 100K rows, LyteNyte achieved around 45 FPS, with AG Grid second at around 36 FPS. MUI remained competitive but trailed both, while the differences between the remaining grids became much more pronounced as the dataset increased.

Filtering performance

Pinned Rows, Horizontal Scrolling & Updates

Some of the more interesting results came from scenarios that resemble real enterprise-grid usage: pinned rows and columns, horizontal scrolling, and replacing entire datasets.

With pinned content, LyteNyte achieved around 58 FPS.

Horizontal scrolling was actually a much closer race: LyteNyte reached 60 FPS, AG Grid 57 FPS, and MUI 55 FPS. All three handled horizontal virtualization well.

Full dataset replacement separated them again. LyteNyte achieved around 51 FPS, followed by AG Grid at 39 FPS and MUI at 22 FPS.

Pinned rows, horizontal strolling and updates

You can check out the complete results here: Full React data grid performance benchmark results

I recommend it if you enjoy detailed data about grid performance. Or if you simply love walls of charts 😅

Okay, But Can We Trust a Vendor Benchmark?

I don't trust anyone. 😏

So the first thing I did was fork the repository and run the benchmarks myself, with a slightly modified methodology. My benchmarks were very... unscientific. I didn't turn my computer into a sterile benchmarking environment. I didn't run the tests on some dedicated pipeline with perfectly controlled CPU resources.

Why? Because I wanted to see whether LyteNyte's advantage would survive under much less friendly conditions. A real user doesn't have a perfectly clean CPU waiting exclusively for your grid. They have 80 browser tabs open, Spotify running in the background, an Excel spreadsheet somewhere, and probably three other applications doing mysterious things with their RAM.

So I simply ran the benchmarks on my normal machine, while continuing to do other things in the background.

The goal wasn't to reproduce 1771 Technologies' exact FPS numbers. That wouldn't make much sense anyway: benchmark results naturally vary between machines, browsers, and system load. I wanted to see whether the performance advantage would survive in a noisy, everyday environment.

Three Formula 1 Cars, a Passat, a Fiat Panda...

After running the benchmarks locally, I quickly decided I wasn't going to test all six grids. Instead, I focused on the three strongest overall performers.

Don't get me wrong: I completely understand why 1771 Technologies selected the grids they did. Apart from LyteNyte, they chose the five most downloaded eligible React grids on npm. It's hardly their fault that those are the grids people download.

But looking at some of the official results, I couldn't shake the feeling that I was watching a race between three Formula 1 cars, an old Volkswagen Passat, a Fiat Panda, and someone who had decided to compete on foot.

So I ultimately tested:

  • LyteNyte Grid
  • AG Grid
  • MUI X Data Grid

I also reduced the benchmark from 50 recorded iterations to 10 and skipped the most extreme scenarios, such as scrolling through one million rows. If you want to see exactly what I changed — or run my version yourself — here's my fork:

My benchmark experiments on GitHub

My Results

And this is where things get interesting. My absolute numbers were very different from the official benchmark results. Which is completely expected.

Take the simplest example: Scroll 10K.

In the official environment, LyteNyte was close to 60 FPS. On my machine? The median of my ten runs was only around 37 FPS. AG Grid achieved around 23 FPS, and MUI around 21 FPS.

That's a huge difference in absolute numbers. But the relative result?

LyteNyte → AG Grid → MUI.

My scroll 10k result

The same pattern appeared when I increased the dataset to 200K rows. LyteNyte's median was around 33 FPS, compared with roughly 20 FPS for AG Grid and 17 FPS for MUI.

Pinned rows produced a similar result: approximately 31 FPS for LyteNyte, 20 FPS for AG Grid, and 17 FPS for MUI.

Horizontal scrolling was faster for everyone, but LyteNyte still led with a median of roughly 48 FPS, followed by AG Grid at 39 FPS and MUI at 27 FPS.

Here's how the median FPS from my 10 runs per benchmark compared:

Benchmark LyteNyte Grid AG Grid MUI X Data Grid
Scroll 10K 37.2 FPS 23.1 FPS 20.9 FPS
Scroll 200K 33.0 FPS 19.9 FPS 17.1 FPS
Pinned 200K 31.0 FPS 20.1 FPS 17.0 FPS
Horizontal 50K 48.0 FPS 39.1 FPS 27.0 FPS
Sorting 10K 30.5 FPS 20.1 FPS 29.5 FPS

Not every result reproduced the exact ranking between the other two grids — and that's important.

For example, in my Sorting 10K test, LyteNyte and MUI were almost tied at roughly 30.5 and 29.5 FPS, while AG Grid was around 20 FPS.

So I'm not claiming that every benchmark produced exactly the same ordering.

What did survive remarkably well was the broader pattern: LyteNyte remained the strongest performer across the tests I reran, even though I used a different machine, fewer iterations, and deliberately less controlled conditions.

And that's much more interesting to me than reproducing exactly the same FPS number.

Chart my full benchmark results

Speed Isn't Everything

Of course, you shouldn't choose a data grid based only on how fast it can scroll through 200,000 rows.

There are plenty of other things to consider: accessibility, developer experience, APIs, licensing, pricing, and simply whether the grid supports the things your particular application needs.

The original benchmark authors make the same point: these results measure runtime performance, not overall product quality. And LyteNyte has plenty to offer outside raw performance as well. You can check out its features and available editions on the LyteNyte Grid website.

What don't I like about it?

The biggest limitation for me is that LyteNyte is React-only. That's perfectly fine if you're building a React application, but it immediately rules the grid out for developers working with another framework. AG Grid, for example, supports React, Angular, Vue, and plain JavaScript.

So, what's the fastest React data grid? In these benchmarks, the answer is pretty clear: LyteNyte.

Does that mean you should immediately replace every grid in your applications with it? Of course not. Performance is only one part of the decision.

But if performance is your bottleneck, LyteNyte is definitely worth testing against your own workload. 

Top comments (13)

Collapse
 
pascal_cescato_692b7a8a20 profile image
Pascal CESCATO

I think you can proudly claim to be the only person writing about React and its components whose articles I actually read. 😄 You know my preference for backend — or, to put it more honestly, my almost formal aversion to frontend, which I tend to see as a necessary evil.

But your articles are always interesting, and this benchmark in particular caught my attention. Not so much because of React itself, but because of your approach: you didn't just take the vendor's benchmark results at face value. You actually ran the tests yourself, under much more realistic conditions, and looked at whether the relative advantage survived rather than obsessing over reproducing the exact numbers. That's much more meaningful to me than another set of vendor-approved charts.

And then there's your sense of humor. The image of “three Formula 1 cars, an old Volkswagen Passat, a Fiat Panda, and someone who had decided to compete on foot” absolutely made my day. 😂

Another very enjoyable read, as usual!

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Thank you so much, Pascal! 😄 Exactly, I never take anything at face value. I need to check it for myself! And honestly, that's part of the fun: give me an excuse to experiment with some technology and I'll happily disappear down that rabbit hole. 😂

And yes, that's pretty much what it looked like with those grids. The three slower ones really were the Passat, the Fiat Panda, and the person running on foot. 😂 Well, people are clearly using them, so maybe they're perfectly fast enough for what they need. Who knows!

Really glad you enjoyed it!

Collapse
 
pascal_cescato_692b7a8a20 profile image
Pascal CESCATO

Haha, I can definitely relate to the “disappear down that rabbit hole” part. 😂

And you're absolutely right about the slower grids: benchmarks can tell you which car wins the race, but they don't necessarily tell you whether the Panda is already fast enough to get you where you need to go. 😄

I think that's actually another good lesson from your benchmark: performance numbers are useful, but context matters at least as much. And sometimes the “slow” solution is still the perfectly sensible one.

Keep disappearing down those rabbit holes — they're clearly producing good articles! 😉

Thread Thread
 
sylwia-lask profile image
Sylwia Laskowska

Haha, I definitely have a tendency to disappear down those rabbit holes. 😂 But I have a feeling you do too, judging by how ridiculously polished and well thought-out your projects always are! 😄

Thread Thread
 
pascal_cescato_692b7a8a20 profile image
Pascal CESCATO

Haha, guilty as charged. 😂

I suppose we both have the same problem: once something gets interesting, “just a quick experiment” has a nasty habit of turning into a full-blown rabbit hole. 😄

And I'll happily take “ridiculously polished and well thought-out” as a compliment — even if it probably says more about my inability to leave things alone than anything else. 😂

Thread Thread
 
sylwia-lask profile image
Sylwia Laskowska

Hahaha, exactly! 😂 I have the exact same condition: “But how could I make this even better? Maybe just one more little feature?” And suddenly the “quick experiment” has become an entire project. xD

Thread Thread
 
pascal_cescato_692b7a8a20 profile image
Pascal CESCATO

Exactly! 😂

Although, in my defense, how can you properly experiment with one tiny thing without first putting it in a well-designed architecture, defining the boundaries, thinking about the edge cases, and making sure the whole thing is reproducible?

And once you've done all that, well... you might as well add one more feature. 😇

That's how a “quick experiment” becomes a project. And then, somehow, the project becomes an excuse for another experiment. It's a vicious circle. xD

Collapse
 
learn2027 profile image
meow.hair

Thank you so much, Sylwia, for this valuable article.
😊

You tackled a highly important topic for developers; combining precise technical benchmarks with practical, real-world insights gives us a comprehensive view to make the right decisions, rather than just chasing abstract numbers.
🌊🧊

I wish you continued growth and success, and I look forward to reading more of your insightful work.

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Thank you so much! 😊 That's exactly what I was hoping to achieve with this article: make the decision a little easier for developers by showing what these grids actually look like in practice, not just on paper. Really glad you found it useful!

Collapse
 
greenflux profile image
GreenFlux

(Disclosure: I work at Handsontable.)

This benchmark was fair. We ran it ourselves on the public harness before changing anything, and Handsontable 17.1.0 did exactly what the charts show.

It also gave us a to-do list. After a few weeks of performance work, we reran the same harness with our 18.1.0 build: the 500K and 1M row tests that previously failed with out-of-memory errors now run at ~30 FPS, heap usage dropped as much as 10x (1,338 MB to 126 MB on sorting 100K), and cell updates went from 6.8 to 20 FPS. At 1M rows, Handsontable had the lowest memory footprint of the grids we retested.

LyteNyte is still the fastest scroller in our reruns, ~57 FPS even at 1M rows; genuinely impressive work. Thanks for building the benchmark in the open.

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Hahaha, this might be my favorite comment today. LyteNyte basically handed you a performance optimization roadmap. 😂

And I have to admin, there's clearly some really solid engineering behind that grid. I haven't seen performance like this in a long time!

Collapse
 
elvingts profile image
Adrian

Great benchmark comparisons! In our experience with financial dashboards handling fast-updating ticker grids (10k+ rows with frequent cell updates), virtualization alone isn't always the bottleneck—it's how the grid handles React reconciliation and DOM node recycling per cell.

Grids that bypass React state updates for cell-level mutations (direct DOM manipulation or offloading to canvas/WebGL) tend to maintain steady 60fps scrolling without triggering React render passes on untouched viewport nodes. Really nice to see open-source reproduction steps provided here.

Collapse
 
sylwia-lask profile image
Sylwia Laskowska

Thanks! And yes, exactly! In fact, one of the grids that, as I wrote in the article, behaved like someone entering a Formula 1 race on foot 😂 didn't bypass React reconciliation at all.

That's precisely why running this benchmark with it on my machine was practically impossible and I benchmarked only the three fastest grids. With that many cell updates going through React, completing the full test would have taken forever. 😅