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.
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.
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.
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.
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.
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.
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 (2)
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!
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!