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.