Performance
ag-Grid is fast. However ag-Grid can also be configured and extended in many ways.
Often people come to the ag-Grid forum and ask 'why is the grid in my application not that fast?'.
This page explains how you can make the grid go faster.
1. Setting Expectations
ag-Grid can be as fast as demonstrated in the demo application Demo Application.
You can resize the demo application to the same size as the grid in your application by resizing the browser.
Then navigate around the grid (scroll, filter etc) and see how fast the demo grid is compared to your own
implementation. If the demo grid is going faster, then there is room for performance improvements.
2. Check Cell Renderers
ag-Grid can be slowed down by your custom
cell renderers. To test this, remove all
cell renderers from your grid and compare the speed again. If the grid does improve it's speed by
removing cell renderers, try to introduce the cell renderers one by one to find out which ones
are adding the most overhead.
3. Create Fast Cell Renderers
The fastest cell renderers have the following properties:
Do NOT use a framework (eg Angular or React) for the cell renderers. The grid rendering is highly
customised and plain JavaScript cell renderers will work faster than framework equivalents. It is
still fine to use the framework version of ag-Grid (eg for setting ag-Grid properties etc) however
because there are so many cells getting created and destroyed, the additional layer the frameworks
add do not help performance and should be provided if you are having performance concerns.
Not everyone needs blazing fast cell renderers (eg maybe you have users on fast machines with fast browsers,
or maybe your grids have few columns) in which case framework cell renderers may work fine. The suggestion
of not using frameworks for cells is only applicable when you are looking to squeeze for performance gains.
We suggest not using frameworks for cell renderers for because of the large number of cells getting
created and destroyed. Most of the time a cell will not have complex features in it, so using plain
JavaScript should not be a problem. For all other components (filters, editors etc) using the frameworks
won't make much noticeable difference as these components are not created and destroyed as often as
cell renderers.
4. Turn Off Animations
Row and column animations make for a great user experience. However not all browsers are as good at
animations as others. Consider checking the client's browser and turning off row and column animation
for slower browsers.
5. Configure Row Buffer
The rowBuffer property sets the number of rows the grid renders outside of the viewable area.
The default is 10.
For example, if your grid is showing 50 rows (as that's all the fits on your screen without scrolling),
then the grid will actually render 70 in total (10 extra above and 10 extra below). Then when you scroll
the grid will already have 10 rows ready waiting to show so the user will not see a redraw (not all browsers
show the redraw, only the slower ones).
Setting a low row buffer will make initial draws of the grid faster (eg when data is first loaded, or after
filtering, grouping etc). Setting a high row buffer will reduce the redraw visible vertically scrolling.
6. Use Chrome
The grid works fastest on Google Chrome. If you can, tell your users.
7. Understand
For fast changing data, consider using
Batch Update Transactions
which allows the grid to take very large amounts of updates without bringing the browser
to a crawl. This is also demonstrated in the blog
Streaming Updates in JavaScript Datagrids
that shows hundreds of thousands of updates per second.
8. Understand
Read the article 8 Performance Hacks for JavaScript
so you know what the grid is doing, that way you will be able to reason with it.