Sharepoint 2013 – Displaying List Views Across Multiple Pages

Displaying Long Lists in SharePoint

As a SharePoint site collects more data over time, the lists and libraries within can grow extremely long with thousands of items which present challenges for rendering and managing long lists. Out-of-the-box, SharePoint displays only a limited number of list items per page, usually 20 items. So when a list grows beyond that threshold, the user experience degrades as page load times increase exponentially. Additionally, long lists become difficult to scan visually or search for particular items.

The Problem of Long Lists

SharePoint stores all list items for a given list in a single database table, only loading small batches into memory as-needed when rendering pages. But with extremely long lists, each page view still puts strain on the database server to load hundreds and thousands of records per request. This also multiplies load on the web front-end server attempting to render the responses. So both database and web servers experience degraded performance proportional to the number of items in these long lists. This results in unacceptably slow page response times and load failures during peak usage.

Out-of-the-Box Display Limits

The standard SharePoint list view web part is configured by default to show only 20 items per page in order to balance response performance and usability for average lists. But the display limit can be manually increased up to 5000 items in the web part settings. Setting such high thresholds is not recommended however since page load performance drops significantly once passing a few hundred items. Showing so many records also diminishes visual scanability as items are scrolled off screen. So alternative solutions are preferred for displaying extremely long SharePoint lists.

Enabling Server-Side Paging

For optimum performance with long SharePoint lists, server-side data paging should be leveraged which spreads the number of items rendered across multiple pages. Paging is enabled by configuring properties on the list view web part used to query and display items from the troublesome long list. With paging enabled, filters are applied on the server during initial query to retrieve only the subset of items for the currently viewed page.

Reduced Loads and Faster Response

Since paging restricts each query to retrieve only those list records applicable for the current page, both database and web server resource loads are reduced in proportion to the number of items displayed per page. So by tuning the appropriate threshold for number of items retrievable per page request, acceptable response performance can be maintained even for extremely large lists. Testing should be performed with sample data sets matching production list volumes to determine optimal paging settings.

Configure Paging in List View Web Part

Below are the essential steps to activate server-side paging on a SharePoint list view web part:

1. Edit Web Part Properties
2. Under “Miscellaneous” section enable server-side paging
3. Set paging limit for number of items retrievable per page
4. Default settings will automatically handle paging controls and navigation once configured. The RowLimit property determines how many records to fetch per request.

Code Sample for Enabling Paging

SharePoint list views are defined using CAML (Collaborative Application Markup Language) syntax for structuring query filters, sorting, and display transformations. The snippet below illustrates adding two key parameters to activate paging for a list view web part querying large volumes of data:

<View>
   <Query>
     <Where>
       ... filters go here ...
     </Where>
   </Query>

   <RowLimit Paged="TRUE">50</RowLimit>

   <ViewFields>
     ... view fields go here ...
   </ViewFields
</View>

The important settings are the “Paged” attribute set to “TRUE” on the RowLimit node which toggles on server paging, along with the numeric value defining items per page. Additional CAML code samples could be included to define sorting, filters, field selection, and other view attributes.

Customizing the Paging Interface

By default once server paging is activated, SharePoint handles rendering a basic pagination control with Next and Previous links along with page numbers. But sites may want to customize the paging user interface by matching branding styles, tweaking layout, and adding interactive behaviors.

Paging UI Design Options

The out-of-box pagination links render as plain text without much style formatting applied. To brand the paging controls, define custom CSS classes and override styles for the .ms-paging element and sub-nodes. This allows changing visual styles for active page numbers, hover states, borders, colors, and positioning.

If more significant layout changes are needed, custom display templates can fully replace the entire default paging component by rendering all indexes, navigation links, and event handlers from scratch.

Enhanced Paging Interactivity

Using client-side script libraries like jQuery, extra interactivity can improve the user experience when paging through very long lists. As examples, load animations during page change requests or disabling Next links when end of list is reached. Virtual scrolling can mimic alphabet indexes for quickly jumping to subsets of records.

By attaching scripts to pagination control events, rich behaviors are possible without changing server configuration. But care should be taken not to make excessively expensive function calls on every paging click which could reduce performance. Find balance between enhanced UI and fast response times.

Considerations and Limitations

While activating server-side paging delivers noticeable gains in page response and stability with extremely large SharePoint lists, the approach still has practical limitations on maximum scalability. Additionally, architectural changes or alternative solutions should be considered relative to use context.

Scalability Limits

Testing against projected production list volumes is advised to determine pragmatical thresholds for the number of items feasibly managed in a single list with paging enabled. Although SharePoint technically supports up to 30 million items in a list, such extreme sizes would face practical challenges.

Complex custom code often becomes necessary to work around various limitations when pushing maximum capacity. At a certain point it becomes more effective to refactor the information architecture rather than stretch a single list to such extremes.

When to Consider Alternatives

For read-heavy lists exceeding several hundred thousand rows, indexed columns can improve filtering and sorting performance by avoiding full table scans. But indexes also impose their own overhead during writes and storage. So only apply very selectively based on query patterns.

For lists grouped by common attributes like regions or years, creating separate views filtered on those elements may prove more efficient than one massive global list. Views segmented this way divide server workload across pages while still maintaining a single underlying table.

In more extreme cases with millions of records, migrating the excess volume to an external database with dedicated data model may become necessary. SharePoint can connect externally through Business Connectivity Services (BCS).

Troubleshooting Paging Issues

If errors occur after enabling server paging, check the SharePoint logs for underlying exception details. Verify paging threshold settings align to expectations and confirm query filters apply properly. Tracing database queries can validate correct construction of row limit and pagination logic.

Double check enhanced security trimming policies like item level permissions are not inadvertently filtering out expected results improperly. Test connectivity and permissions on related back end services like search and user profiles.