Mastering Ext JS Performance: Scaling Data Grids from 500 to 1,000,000+ Records

Enterprise applications rarely fail because a grid cannot render a few hundred records.

The real challenge begins when that same application evolves into a business-critical platform handling 50,000, 500,000, or more than 1 million records—while users still expect fast search, responsive scrolling, accurate filtering, and an interface that remains usable throughout the working day.

At that scale, performance is no longer a component-level configuration problem.

It becomes an end-to-end data architecture problem.

As Rafael Méndez highlighted in his JS Days 2026 presentation, front-end teams need to move beyond isolated grid optimizations and examine the complete data-flow pipeline. Database execution, API serialization, network latency, client-side store management, and DOM rendering all contribute to the final user experience.

For applications built with Sencha Ext JS, this distinction is particularly important. Ext JS provides the architecture needed to manage large datasets efficiently—but the framework can only perform well when the application assigns each workload to the right layer.

The question is therefore not:

Can the browser display the data?

It is:

How much data should the browser hold, how much should it render, and where should each data operation execute?

Why Large Datasets Change the Ext JS Performance Equation

At a few hundred records, a conventional Ext.data.Store can comfortably load data into browser memory.

The browser receives the JSON payload, creates JavaScript model instances, performs sorting and filtering, and renders the grid.

As the dataset grows, that architecture starts accumulating costs in three areas.

1. Client-side memory

Maintaining tens of thousands of model instances increases browser heap consumption and can trigger garbage-collection pauses or instability.

2. Network and JSON processing

Large HTTP responses increase transfer time and require the browser to deserialize increasingly large JSON payloads.

3. DOM and rendering workload

Rendering thousands of table rows creates significant layout and DOM-management overhead, resulting in slower scrolling and reduced interface responsiveness.

These limitations mean that simply optimizing the grid configuration is rarely enough.

The application must instead control the amount of data that enters the browser in the first place.

The Four-Stage Ext JS Data Scaling Strategy

There is no single data-loading architecture that is appropriate for every dataset.

A 300-record lookup table does not need the same infrastructure as a million-record operational dataset.

The source architecture defines four progression stages:

The principle is simple:

Scale the data architecture with the dataset—not ahead of it and not behind it.

Stage 1: Use Ext.data.Store for Small Datasets

For datasets containing approximately 500 records or fewer, loading the complete dataset into browser memory remains a straightforward approach.

A standard Ext.data.Store can retrieve the data, maintain the model instances, and bind directly to the grid.

At this scale, client-side sorting, filtering, and rendering generally avoid the complexity of more advanced buffering architectures.

But even at this stage, schema discipline matters.

A well-defined Ext.data.Model establishes the foundation for future scaling.

Define fields explicitly

Financial and operational values should use appropriate numeric types.

Dates should have explicit parsing formats.

Identifiers such as telephone numbers, postal codes, or other values containing formatting characters should remain strings rather than being converted to integers.

Calculated fields should also be defined at the model layer instead of recalculated repeatedly inside rendering functions.

For example:

    Ext.define('App.model.Customer', {
        extend: 'Ext.data.Model',

        idProperty: 'id',

        fields: [
            { name: 'id', type: 'int' },
            { name: 'firstName', type: 'string' },
            { name: 'lastName', type: 'string' },

            {
                name: 'fullName',
                type: 'string',
                calculate: function(data) {
                    return data.firstName
                        ? data.firstName + ' ' + data.lastName
                        : '';
                }
            },

            {
                name: 'registrationDate',
                type: 'date',
                dateFormat: 'Y-m-d'
            },

            { name: 'annualValue', type: 'float' },
            { name: 'phone', type: 'string' },
            { name: 'isActive', type: 'boolean' }
        ]
    });

The idProperty deserves particular attention.

A stable unique identifier is not simply a database convenience. As applications move toward pagination, buffering, and virtualized data, record identity becomes essential for tracking selections, cache behavior, and changes.

Stage 2: Introduce Server-Side Pagination for Tens of Thousands of Records

Once a dataset reaches tens of thousands of records, sending the entire dataset to the browser becomes increasingly inefficient.

The solution is to separate:

Total dataset size

from

Client working-set size.

With Ext JS pagination, the browser requests only the records required for the current page.

For example:

    Ext.define('App.store.CustomersPaging', {
        extend: 'Ext.data.Store',

        model: 'App.model.Customer',

        pageSize: 100,

        proxy: {
            type: 'ajax',
            url: '/api/customers',

            reader: {
                type: 'json',
                rootProperty: 'data',
                totalProperty: 'total'
            }
        }
    });

The request can be structured around:

• pageSize
• start
• limit

The server returns the requested records together with the total number of matching records.

That allows Ext.toolbar.Paging to manage navigation and display the user’s position within the broader dataset.

The database must perform the truncation

There is an important architectural distinction here.

Pagination only delivers a meaningful performance improvement when the server and database retrieve the requested slice rather than loading the entire dataset into server memory first.

Production implementations should therefore use indexed database queries such as:

    LIMIT 100
    OFFSET 100

The browser should receive 100 records—not 50,000 records that are subsequently hidden by the UI.

That separation is what makes pagination an architectural optimization rather than merely a visual one.

Stage 3: Use Ext.data.BufferedStore for Million-Record Datasets

At one million records, conventional pagination can become a usability problem.

The user may not want to navigate through thousands of pages simply to locate a record.

At the same time, loading one million model instances into browser memory is not viable.

This is where Ext.data.BufferedStore and virtual scrolling become important.

The architecture separates the dataset into three layers:

Layer 1: Remote dataset

The complete dataset remains in the database.

Layer 2: Client working set

BufferedStore maintains a controlled rolling cache of pages.

Layer 3: Visible DOM

The grid renders only the rows required for the active viewport and its rendering buffer.

    Database
    1,000,000+ records
          │
          ▼
    BufferedStore
    Controlled page cache
          │
          ▼
    Ext JS Grid
    Visible DOM rows

This is the fundamental idea behind virtualized data rendering:

The user can navigate through a massive dataset without the browser holding or rendering the entire dataset.

How BufferedStore Controls Memory

Several configuration parameters determine how aggressively the store manages its working set.

leadingBufferZone
Controls how many records are fetched ahead of the user’s current position.

This reduces the probability that a user reaches the end of the loaded buffer before the next request completes.

trailingBufferZone
Maintains a smaller working set behind the user’s current position so that short reverse movements do not immediately trigger additional requests.

purgePageCount
Controls how many pages remain cached before older pages are removed.

This is a critical memory-governance mechanism.

Ext.define('App.store.CustomersBuffered', {
    extend: 'Ext.data.BufferedStore',

    model: 'App.model.Customer',

    pageSize: 100,

    leadingBufferZone: 300,
    trailingBufferZone: 100,
    purgePageCount: 10,

    autoLoad: true,

    proxy: {
        type: 'ajax',
        url: '/api/customers/buffered',

        reader: {
            type: 'json',
            rootProperty: 'data',
            totalProperty: 'total'
        }
    }
});

The objective is not to maximize the amount of data cached.

It is to maintain enough data to create a responsive experience while keeping memory bounded.

The Hidden Cost of Buffered Data: Startup and Diagnostics

Virtual scrolling introduces its own engineering considerations.

A BufferedStore can issue an initial burst of page requests to populate the viewport and surrounding buffer zones. The source notes that this may involve several requests during initialization.

That means backend architects should account for this behavior when configuring:

• API rate limits
• Database connections
• Connection pools
• Server concurrency

There is also a diagnostic distinction developers need to understand.

store.getCount() does not necessarily represent the number of physical records currently held in the client cache in every buffered-store scenario.

For detailed memory diagnostics, developers may need to inspect the store’s page map and active network requests rather than relying on a single count value.

Stage 4: Move Sorting and Filtering to the Database

Virtual scrolling solves the problem of moving through large datasets.

It does not solve the problem of querying the entire dataset locally.

Imagine a database containing one million records while the browser currently has 500 cached records.

If the application performs a local filter, it can only filter those 500 records.

The result may be locally accurate but globally wrong.

That is why large-scale applications should delegate operations such as sorting, filtering, and searching to the backend.

In Ext JS, the relevant configuration is:

    remoteSort: true,
    remoteFilter: true

For example:

    Ext.define('App.store.CustomersRemoteOps', {
        extend: 'Ext.data.BufferedStore',

        model: 'App.model.Customer',

        pageSize: 100,

        leadingBufferZone: 300,
        trailingBufferZone: 100,
        purgePageCount: 10,

        remoteSort: true,
        remoteFilter: true,

        proxy: {
            type: 'ajax',
            url: '/api/customers/search',

            reader: {
                type: 'json',
                rootProperty: 'data',
                totalProperty: 'total'
            }
        }
    });

When the user sorts or filters a column, the client sends the requested operation to the server.

The database performs the global query.

The server returns the new matching slice and updated total.

The client then rebuilds its working buffer.

This creates a clean division:

Browser = intent + presentation

Database = global query execution

Why Local Sorting Can Become Incorrect at Scale

This distinction is easy to overlook.

Suppose the complete dataset contains:

1,000,000 records

but the browser contains:

500 cached records.

Sorting those 500 records does not produce a globally sorted million-record dataset.

It produces a correctly sorted subset.

For enterprise applications, that difference is critical.

When users work with financial, operational, customer, or analytical data, they expect sorting and filtering to represent the full dataset.

Remote operations therefore become a correctness requirement—not simply a performance optimization.

Managing Selection State in Virtualized Grids

Virtualization introduces another challenge: records can leave memory.

Suppose a user selects several rows and then scrolls far enough for those records to be evicted by purgePageCount.

If the application associates selection only with in-memory model instances, those selections can disappear.

The solution is to preserve identity independently of the volatile cache.

First, establish a stable idProperty.

Then configure the selection model appropriately:

    var selectionModel = Ext.create('Ext.selection.CheckboxModel', {
        pruneRemoved: false
    });

With pruneRemoved: false, selected identifiers can remain represented even when their corresponding model instances have been removed from the active page cache.
The broader architectural principle is:

Virtualized data requires state management that is independent of the data currently visible in memory.

Protecting Uncommitted Edits with Delta Management

The same issue applies to editable grids.

Consider a user editing a record near page 2 and then scrolling to page 50.

If page 2 is evicted from the buffer, the edited model instance may no longer exist in memory.

Without an independent change-tracking mechanism, the uncommitted edit can disappear.

A dedicated Delta Management Collection addresses this problem.

Instead of treating the store cache as the authoritative location for pending changes, the application maintains a separate collection keyed by the record’s stable identifier.

Conceptually:

    Ext.define('App.core.DeltaTracker', {
        singleton: true,

        pendingEdits: {},

        trackEdit: function(recordId, field, value) {
            if (!this.pendingEdits[recordId]) {
                this.pendingEdits[recordId] = {};
            }

            this.pendingEdits[recordId] = value;
        },

        getDeltas: function() {
            return this.pendingEdits;
        },

        clearDeltas: function() {
            this.pendingEdits = {};
        }
    });

An alternative is to persist edits immediately through transactional REST APIs.

Either approach removes business-critical state from the volatile buffer cache.

Tuning Buffer Performance for Real-World Networks

Buffer configuration is a balancing exercise.

Too little buffering can cause visible loading during scrolling.

Too much buffering can increase network traffic and memory consumption.

The source provides the following framework:

For example, the source suggests approximately 100 records for a viewport displaying around 35 rows, with larger leading buffers—such as 300–500 records—potentially appropriate for higher-latency enterprise WAN environments.

The key is to tune against actual operating conditions rather than relying on universal configuration values.

Scaling Horizontally: Wide Grids Need Virtualization Too

Large datasets are not the only performance challenge.

Enterprise grids can also become extremely wide.

Financial models, operational dashboards, and analytical interfaces can contain hundreds of columns.

In these scenarios, the browser can spend substantial resources creating and maintaining cell DOM elements across the horizontal dimension.

Ext JS Modern 8.0 introduces bufferColumns to address this class of problem.

    Ext.define('App.view.WideGrid', {
        extend: 'Ext.grid.Grid',

        xtype: 'wide-grid',

        store: 'App.store.CustomersBuffered',

        bufferColumns: true,

        columns: [
            // Wide schema column definitions...
        ]
    });

With horizontal buffering enabled, the grid renders the columns within the active horizontal viewport rather than materializing every cell in the complete schema.

As users scroll horizontally, the framework recycles the relevant DOM structures.

This extends the same virtualization principle from rows to columns.

The Enterprise Ext JS Performance Decision Framework

The correct architecture depends on dataset size and interaction requirements.

For small datasets, simplicity should win.

For medium datasets, pagination separates the complete dataset from the browser’s working set.

For million-record datasets, buffering and virtual scrolling become central.

For large-scale search and sorting, the database should execute global operations.

For wide analytical grids, horizontal buffering can extend the same performance strategy across columns.

Four Principles for Building High-Performance Ext JS Applications

The technical implementation ultimately comes down to four architectural principles.

1. Match the Store Architecture to Dataset Scale

Do not introduce virtualization simply because the framework supports it.

Use the simplest architecture that satisfies the dataset and user requirements.

Hundreds of records do not need million-record infrastructure.

Millions of records should not be treated like hundreds.

2. Push Global Operations to the Backend

Sorting and filtering against a partial client cache produces incomplete results.

Use remoteSort and remoteFilter when the browser does not contain the complete dataset.

Let indexed database engines perform operations against the authoritative dataset.

3. Govern Memory and State Separately

purgePageCount controls memory.

idProperty controls identity.

pruneRemoved helps preserve selection state.

A dedicated delta collection protects uncommitted edits.

These responsibilities should not be conflated.

4. Virtualize Both Dimensions

Large row counts require vertical virtualization.

Wide schemas require horizontal virtualization.

Using BufferedStore together with bufferColumns can keep the browser’s DOM and memory footprint bounded across both dimensions.

Conclusion

Enterprise front-end Framework performance is rarely solved by changing one grid configuration.

The larger opportunity is to redesign where data lives, where operations execute, and how much the browser is required to manage.

For Ext JS applications, the progression is clear:

Hundreds of records → in-memory stores

Tens of thousands → server-side pagination

Millions → buffered stores and virtual scrolling

Global search and sorting → backend delegation

Wide enterprise grids → horizontal column buffering

The most effective optimization is often the work the browser never has to perform.

When database execution, API delivery, client-side buffering, state management, and DOM rendering are treated as one architecture, Ext JS applications can scale from relatively small administrative datasets to enterprise-scale operational and analytical workloads without allowing data volume to dictate the quality of the user experience.

For engineering leaders, that is the larger lesson:

Performance at scale is not about making the browser work harder. It is about designing the system so the browser has less work to do.