List View Performance Optimization Pattern

intermediateTested on Xanadu

The List View Performance Optimization Pattern addresses the common challenge of slow-loading list views in ServiceNow, particularly when dealing with large tables with millions of records. Poor list view performance impacts user experience and system resources, especially when users navigate to tables like incident, change_request, or custom tables with extensive data.

This pattern combines several optimization techniques: strategic indexing of frequently filtered columns, reducing the number of visible columns in list layouts, disabling expensive row count operations, using relative query conditions instead of complex joins, and implementing proper pagination with query limits. The pattern works by minimizing database load, reducing network transfer, and optimizing query execution paths.

By implementing these optimizations systematically, administrators can transform slow list views that take 30+ seconds to load into responsive interfaces that load in under 3 seconds, while maintaining the functionality users need for their daily work.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Use This When

Use this pattern when list views take more than 5-10 seconds to load, when dealing with tables containing over 100,000 records, or when users frequently filter on specific columns. This pattern is essential for high-volume production instances where list performance directly impacts productivity.

Avoid When

Avoid this pattern for small tables under 10,000 records where the overhead of optimization exceeds the benefits. Don't implement if users genuinely need to see all available columns or require exact row counts for business processes, as this pattern trades some functionality for performance.

Implementation

Server-side

// Script Include: ListViewOptimizer
var ListViewOptimizer = Class.create();
ListViewOptimizer.prototype = {
    initialize: function() {},
    
    // Optimize a GlideRecord query for list view performance
    optimizeQuery: function(gr, maxRows) {
        maxRows = maxRows || 250;
        
        // Set query limit to prevent runaway queries
        gr.setLimit(maxRows);
        
        // Use chooseWindow for pagination instead of loading all records
        gr.chooseWindow(0, maxRows);
        
        // Order by sys_updated_on (indexed) for consistent pagination
        gr.orderByDesc('sys_updated_on');
        
        // Disable row count to avoid expensive COUNT(*) queries
        gr.setQueryReferences(false);
        
        return gr;
    },
    
    // Create optimized query with relative date conditions
    createOptimizedIncidentQuery: function(daysBack) {
        daysBack = daysBack || 30;
        var gr = new GlideRecord('incident');
        
        // Use relative queries instead of specific dates for better caching
        var cutoffDate = gs.daysAgoEnd(daysBack);
        gr.addQuery('sys_created_on', '>=', cutoffDate);
        
        // Query on indexed fields first to narrow result set
        gr.addQuery('active', true);
        gr.addQuery('state', 'IN', '1,2,3'); // New, In Progress, On Hold
        
        // Apply list view optimizations
        this.optimizeQuery(gr, 100);
        
        gs.info('Optimized incident query created for last ' + daysBack + ' days');
        return gr;
    },
    
    // Get paginated results with metadata for client-side handling
    getPaginatedResults: function(tableName, encodedQuery, pageSize, pageNumber) {
        pageSize = pageSize || 50;
        pageNumber = pageNumber || 0;
        
        var gr = new GlideRecord(tableName);
        if (encodedQuery) {
            gr.addEncodedQuery(encodedQuery);
        }
        
        // Calculate window boundaries
        var startRow = pageNumber * pageSize;
        var endRow = startRow + pageSize;
        
        gr.chooseWindow(startRow, endRow);
        gr.orderByDesc('sys_updated_on');
        gr.query();
        
        var results = [];
        while (gr.next()) {
            results.push({
                sys_id: gr.getUniqueValue(),
                number: gr.getDisplayValue('number'),
                short_description: gr.getDisplayValue('short_description'),
                state: gr.getDisplayValue('state'),
                assigned_to: gr.getDisplayValue('assigned_to'),
                sys_updated_on: gr.getDisplayValue('sys_updated_on')
            });
        }
        
        return {
            records: results,
            pageSize: pageSize,
            pageNumber: pageNumber,
            hasMore: results.length === pageSize
        };
    },
    
    type: 'ListViewOptimizer'
};

Client-side

// Client Script for optimized list view pagination
function loadOptimizedPage(tableName, pageNumber) {
    var ga = new GlideAjax('ListViewOptimizer');
    ga.addParam('sysparm_name', 'getPaginatedResults');
    ga.addParam('sysparm_table_name', tableName);
    ga.addParam('sysparm_page_number', pageNumber);
    ga.addParam('sysparm_page_size', '25');
    
    // Get current list filter if available
    if (typeof g_list !== 'undefined' && g_list.getQuery) {
        ga.addParam('sysparm_encoded_query', g_list.getQuery());
    }
    
    ga.getXMLAnswer(function(response) {
        var data = JSON.parse(response);
        if (data && data.records) {
            updateListView(data.records);
            updatePaginationControls(data.pageNumber, data.hasMore);
        }
    });
}

// Update list view with new data without full page refresh
function updateListView(records) {
    var tbody = document.querySelector('#sys_target tbody');
    if (!tbody) return;
    
    tbody.innerHTML = '';
    records.forEach(function(record) {
        var row = document.createElement('tr');
        row.innerHTML = 
            '<td><a href="/incident.do?sys_id=' + record.sys_id + '">' + record.number + '</a></td>' +
            '<td>' + record.short_description + '</td>' +
            '<td>' + record.state + '</td>' +
            '<td>' + record.assigned_to + '</td>' +
            '<td>' + record.sys_updated_on + '</td>';
        tbody.appendChild(row);
    });
}

The server code demonstrates key optimization techniques: setLimit() and chooseWindow() prevent loading excessive records, orderByDesc on indexed sys_updated_on ensures consistent sorting, and setQueryReferences(false) disables expensive reference field lookups. The pagination method returns structured data with metadata to support client-side navigation without full page reloads.

Alternatives

GlideAggregate with Summary Fields

Use when users need summary statistics rather than detailed records. Provides much faster load times for dashboards but sacrifices drill-down capability into individual records.

Scheduled Data Collection with Cached Views

Implement when real-time data isn't critical and performance is paramount. Creates lightning-fast list views but introduces data latency and requires additional storage for cached results.

REST API with External Pagination Component

Best for modern UI requirements with custom interfaces. Provides ultimate flexibility and performance but requires significant development effort and moves away from standard ServiceNow list functionality.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue