Panels have several features such as a header containing tool icons, the ability to be draggable, collapsible, and have docked items. In many situations, these features just aren't required. In this situation, a container is a much better choice. It's more lightweight in memory and the markup it generates.

Overnesting of containers and panels, particularly those implementing border layouts, are a very common source of performance issues, particularly if the user needs to move between various screens containing over-nested components. Ext JS needs to perform lots of calculations to build a viewport and the layout process is particularly expensive. Every time we find ourselves adding a new component to the hierarchy, it should cause us to stop and re-evaluate.

We also need to think about how a deep hierarchy could affect cases in which we are querying our component structure. With a more complex component tree and a more complicated DOM, any operations to fetch either components or elements from the application will be slower. In many cases, this slowdown will be marginal; in some cases, it'll be a critical consideration when improving your application's performance.

When creating a container or panel with a card layout, by default the layout will immediate render all components within each card. This is usually unnecessary because the user will only see the first card to begin with. Instead, we can use the deferredRender configuration option on the card layout to render items only when their parent card becomes active. This reduces the initial render time, therefore, the time until the application can respond to user input.

Another similar approach involves grids. Ext JS allows you to load a large server response into a store and attempts to display it on a grid, but in situation with thousands of records, the store causes memory usage to balloon and the browser will struggle to keep things smooth with such a large number of DOM nodes making up the grid rows.

The solution is to swap out a standard store for Ext.data.BufferedStore. This uses an enhanced paging mechanism to preload pages of data in advance. Meanwhile, the grid will automatically use Ext.grid.plugin.BufferedRenderer and as the user scrolls through the grid entries, the backing BufferedStore will automatically load in new pages of data while removing old pages. It does this seamlessly, so the user has no idea that the rows are being loaded from the server on the fly. The BufferedRenderer will also dispose of DOM nodes from old nodes as they scroll past, removing the memory burden of such a large amount of data.

All of these techniques have their place. They are also useful tools to be aware of at the start of the architecture process. If a client asks whether the application can handle 10,000 records in a datagrid, we now know that a buffered store can deliver the goods. On the flipside, we need to be conscious of premature optimization; there's no point implementing a buffered store when we're only dealing with a handful of records.