Expand All

  Getting Started



  Row Models





Github stars make projects look great. Please help, donate a star, it's free.
Read about ag-Grid's Partnership with webpack.
Get informed on releases and other ag-Grid news only - never spam.
Follow on Twitter


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 renderer's. To test this, remove all cell renderer's 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 renderer's one by one to find out which ones are adding the most overhead.

3. Create Fast Cell Renderer's

The fastest cell renderer's have the following properties:

  • Do NOT use a framework (eg Angular or React) for the cell renderer's. The grid rendering is highly customised and plain JavaScript cell renderer's 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 renderer's (eg maybe you have users on fast machines with fast browsers, or maybe your grids have few columns) in which case framework cell renderer's 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 renderer's 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 renderer's.

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

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.