ExtJS: Performance Best Practices

With the Sencha dev team hard at work improving the underlying performance of ExtJS 4 there has been a lot of talk on the forums about how to write fast applications. Those of us who've been using ExtJS for a while will all have experienced sluggish UIs and in many cases the problem lay in our applications, not the library itself.

I thought it might be interesting to get some discussion going about what techniques people have used to improve UI performance in their own applications. It would be interesting to compare notes and possibly generate some metrics to see which 'optimizations' actually work. If there's sufficient interest perhaps it could even turn into a blog post.

Before Sencha Touch I didn't do too much performance optimizing to be honest... Now that I have been using Sencha Touch, performance is a top-tier concern that has been carried over to my Ext JS (3 & 4) work.

1. Create abstracts. This cuts down on code duplication and bunch of other good things.
2. DOM is the slowest thing ever! There is a trade-off with cute "features" and performance. If you have a TabPanel or Card layout, use deferred rendering. I go as far as to destroy cards (or remove all items) that aren't visible.
3. Code smart... there are tons of tricks to accomplish the same thing but with more efficient code.

These three have been at the main-stray of my development this last year and have helped a ton.

One of the biggest, yet distributed across the framework, costs we found in profiling 4.1 was the cost of DOM updates made in methods like afterRender or onRender. Many components made "harmless" calls like createChild('div') or addCls or removeCls in these methods.

We made a big push to move as much of this stuff as possible into beforeRender and the renderTpl which eliminated dozens of reflows. The same should be considered for custom components, especially if those components are heavily used.

I'm not sure how helpful this will be in general, but in 4.1 we added Ext.getDetachedBody() as an alternative to Ext.getBody(). This was to optimize cases where we had to render a component (like a drag-drop proxy) but didn't want to pay for extra reflows. The "detached body" is just a div that is not part of the document, so anything rendered into it cannot be measured, but you can still set classes, styles and event listeners. We simply move these elements to the real getBody on-demand.

Many applications include one or more large grids with many rows and many columns. If you're having performance problems it might be worth experimenting with a much smaller grid, say 10 records and 4 columns. Whilst this obviously isn't acceptable for the finished application it can be useful to help diagnose where your performance problem lies.

If using fewer records does improve performance then it is also worth considering whether the problem lies more generally with loading large volumes of data from your server. For large volumes of data it can take a number of seconds for a browser to parse a JSON response and create the records, before it even begins trying to render the data to the grid.

In many cases a customer will be willing to accept a much smaller page size if it makes the UI much faster. Often the page size for a grid is just a number that was plucked out of the air and a grid that seemed quite snappy in the initial prototype may well be much slower by the time the rest of the UI has been bolted in.

Most of the ExtJS applications I've seen suffer from panel explosion. Everything is done using a panel, or to be more accurate, everything is done using several panels.

There are alternatives.

The first problem is over-nesting. Panels within panels within panels, when one panel would suffice. Often people don't even realize they're doing it.

The next problem is using a panel when there are much more lightweight alternatives. Everyone loves panels but truth be told they're overkill for most parts of a UI. I once saw a UI that displayed a few dozen thumbnail images and each image was rendered as the HTML content of a different panel. All those panel were totally unnecessary. Consider instead...

1. Could you use HTML and CSS instead of a full component? An Ext.Template or Ext.XTemplate might prove helpful.
2. Could you just use a custom Ext.Component? There are various config settings for injecting HTML into a component: autoEl, html, tpl & data.
3. Could you use a DataView to render all of your data instead of a number of individual components?
4. Could you use an Ext.container.Container rather than an Ext.panel.Panel to reduce the overhead?

The more panels (and components in general) you create, the more stress it will put on the layout system and the larger the DOM will be.

The functions used for callbacks and listeners are a common source of problems. They not only take time to create but can also form expensive closures.

Consider this example:

Code:

---

Ext.define('MyClass', {
    ...

    constructor: function(config) {
        ...

        this.store.on('load', function() {
            ...
        }, this);
    }
});

---

The thing to realize is that a new listener function is created each time this constructor runs. This not only takes time but could potentially leak loads of memory though a closure. The preferred pattern looks like this:

Code:

---

Ext.define('MyClass', {
    ...

    constructor: function(config) {
        ...

        this.store.on('load', this.onStoreLoad, this);
    },

    onStoreLoad: function() {
        ...
    }
});

---

In this case the listener function is created once and stored on the class. Each instance will share the same function. The overhead for creating the function is incurred just once and there's no risk of a leaky closure. Even better, this style of coding makes it easy for subclasses to change the listener with a simple override.

For completeness, I should point out that my use of on is probably misguided here. Though there are other factors to consider, it would usually be better to write it using mon instead:

Code:

---

this.mon(this.store, 'load', this.onStoreLoad, this);

---

This will ensure that the listener is automatically removed when instances of MyClass are destroyed.

A common myth is that xtypes provide a performance boost through lazy-instantiation. In general this is not true. As soon as you add an xtype-config to a container it will instantiate the full component, even if it isn't visible.

Whilst xtypes have many great uses they usually have no measurable impact upon application performance or resource consumption.

To improve load times in production builds:

1. Do not use Ext.Loader.
2. All JS files should be concatenated and minified. Even on a fast internal network this can make a huge difference.
3. All CSS files should be concatenated and minified.
4. Consider building a custom version of ext-all.js. Are you really using the whole library?
5. If you use a lot of images then image sprites can help reduce the number of requests and also provide an implicit form of pre-caching for the other images in the sprite.

It can help to improve UI snapiness if you disable animations. This is something you could do selectively such that faster browsers have the animations but slower browsers don't.

Whilst you may be required to support older versions of IE, it isn't necessarily the case that you need to provide an identical UI to the one you offer in newer, faster browsers.

Are there things you could cut in older browsers to help performance? Animations and visual effects are an obvious example but there are others. What about the page size of your grids? It might help to reduce it in older browsers. Many UIs have redundancy built in to make them more convenient, e.g. 3 different ways to do the same thing. Is that strictly necessary?