Diagnose and fix Microsoft Lists performance problems

Slow or failing Microsoft Lists pages are most often caused by list design (large unindexed lists, many lookups, complex JSON or calculated columns) rather than the Lists service. Start with quick, reversible checks (private browser, alternate network, minimal view) to isolate browser/network/tenant problems, then apply fixes such as limiting view results, adding indexes, reducing lookups, and simplifying JSON formatting. If those steps don’t restore acceptable performance, collect timed diagnostics and escalate with Microsoft support.

Is this really a Lists performance problem or something else?

Symptom

Pages load slowly, list views time out, you see "Something went wrong" or "This view cannot be displayed because it exceeds the list view threshold" messages, or item edits fail or are sluggish.

When it appears

• Slowness only on specific lists or views while other SharePoint pages are fine: likely list design.
• Slowness across many Microsoft 365 apps for many users: likely a tenant or service incident.
• Slowness for a single user only: likely browser, cache, or local network issue.

Quick reasoning checklist (run these before changing the list)

1. Open the same list in a private/incognito browser window.

Open a private/incognito window, sign in, open the list

2. Have a colleague on a different network or device open the list.
3. Try a different list or the document library on the same site.
4. Check Microsoft 365 Service health in the Microsoft 365 admin center for any SharePoint/Lists incidents.

Interpretation

• Fast in private/incognito: clear browser cache and disable extensions for the affected user.
• Fast for a colleague on another network: inspect corporate proxy, firewall or DNS.
• Other lists load fine on the same site: the issue is this list or view and you should proceed to design diagnostics.
• Service health reports an incident covering SharePoint/Lists and many users are affected: follow Microsoft guidance or wait for resolution.

Before you start

Product and versions this article applies to

• Microsoft Lists in Microsoft 365 (modern experience) and SharePoint Online list views.

Privileges and preconditions

• Privilege: List Owner or Site Owner to change view definitions and create indexes.
• No restart required.
• Backup: exporting list data or column values is recommended before destructive actions like deleting columns.

Two safe checks to run first

1. Create a minimal test view that only shows ID and Title and limits results to 30 items.

Site contents > Select the list > View options > Create new view > Columns: ID, Title > Item Limit: 30

2. Open the list from another device or network (phone hotspot) to rule out local network issues.

Which scenarios commonly cause slow Lists

Common root causes

• Large unindexed lists: views that require scanning more than the list view threshold will be slow or blocked.
• Heavy lookup and person/group columns: each lookup adds backend queries; many lookups multiply cost.
• Calculated and complex formula columns: formulas are evaluated per row on read and add CPU/latency.
• JSON column or view formatting: complex formatting can slow rendering and increase client-side work.
• Large attachments or many attachment checks: attachments checked on render slow item display.
• Custom web parts or SPFx customizations: extra network calls or inefficient queries can be introduced.
• Folders and flat single-folder designs: a single container with very many items can still trigger large scans if views are not scoped.
• Broken or outdated indexes: an index that doesn't support the view's filter forces a full scan.

Examples

• A list with 120,000 items and a view filtered by Status with no index on Status will hit the list view threshold and either fail or be slow.
• A list that uses five lookup columns can cause many backend calls for each row; opening the view may become unresponsive on moderate connections.

Quick safe checks to run right now

Do these reversible, low-risk tests first.

1. Open in a private browser window.

Open a private/incognito window, sign in, open the list

2. Try a different browser or device.
3. Switch networks (phone hotspot) to rule out corporate proxy or firewall.
4. Open a different list or the site Home page to compare load times.
5. Check Microsoft 365 Service health in the admin center.
6. Run a simple view test: create a brand new view that shows only ID and Title and limits items to 30.

Expected results and interpretations

• Fast in private/incognito: issue is local to the user browser (clear cache, disable extensions).
• Fast on alternate network: investigate proxy, firewall, DNS.
• New minimal view loads quickly: the original view's filters, columns or formatting are the likely cause.
• All lists are slow and service health shows an incident: this is a tenant/service issue; follow Microsoft guidance.

Optimize views and list design for immediate improvement

Where to act: list settings and view definitions. Privilege: List Owner or higher.

Safest, most reversible changes first

1. Limit items returned by the view.

List > Settings (gear) > List settings > Create view / Modify view > Item Limit

Expected result: the page renders faster because fewer rows are returned. If still slow, the query or column rendering is the bottleneck.

2. Add column indexes for fields used in filters or sorts. Create single-column indexes first.

List > Settings > List settings > Indexed columns > Create a new index

Expected result: views that filter on indexed columns run without scanning the full list. If the view still fails with threshold messages, ensure the first filter uses the indexed column.

3. Replace heavy lookup/person columns where practical. Use single-value choice or text columns if live lookup behavior is not required. Reduce lookup count and avoid lookups against very large lists.
4. Simplify or remove JSON column/view formatting. Temporarily remove formatting to test rendering speed.
5. Avoid calculated columns for commonly queried fields; precompute values via Power Automate or a scheduled job if needed.
6. Use folders to partition items when a logical grouping exists; scope views to a folder when appropriate.
7. Prefer the modern experience and modern list pages instead of classic pages or custom web parts that inject extra work.

What to expect after each change

• Index added and view adjusted to use that index: view should open without threshold errors.
• Removed complex JSON: rendering will be faster and produce fewer script errors.
• Reduced lookups and calculated columns: backend query cost drops and common operations become faster.

If changes don’t improve performance

• Check for OR filters: OR combinations often prevent index usage and cause full scans. Rework filters to use AND with indexed columns when possible.
• If OR is unavoidable, create additional indexed views or maintain a denormalized column via Power Automate for filtering.

Measure improvement and verify the fix

How to confirm changes worked.

Use browser developer tools for timing

1. Open the list in a browser and open Developer Tools (F12).
2. Select the Network tab and clear existing logs.
3. Reload the list view and note timing for main REST calls (look for requests to _api/web/lists or _api/web/GetList).

REST call completes significantly faster after optimization (smaller time in ms shown in Network tab).

List view threshold and behavior

• If a view previously returned a threshold error and now opens, the index or filter change worked. If it still fails, confirm which column is the first filter and whether an index exists on it.

User validation checklist

• Open the view from a typical user machine and network.
• Confirm page loads within an acceptable time for your users (your organization’s SLA).
• Test common operations: sorting, filtering, opening item details, editing an item.

If metrics did not improve

• Re-run the minimal view test (ID and Title only). If the minimal view is fast but the optimized view is slow, a specific column or rendering is the remaining problem.
• Capture Network timings and the specific failing REST calls to include with support if escalating.

When to escalate and what data to collect for support

Escalate when multiple users are affected, the issue persists after view and index changes, or you see service-level errors beyond list design.

What to collect before contacting Microsoft support or your tenant admin

• Exact reproduction steps: who, where, which list, which view, what actions.
• Screenshots of the error and timestamps.
• Browser developer tools output: Network tab export or screenshots showing the slow/failed REST calls, their URLs, status codes, and timings.
• ULS or correlation ID if available from SharePoint page errors (copy the correlation ID shown on error pages).
• The list size (number of items), number of columns, which columns are lookup/person/calculated/choice, and any JSON formatting used.
• Whether you tested on another network/device and the results.
• Service health status at the time of the incident.

Common fixes Microsoft or your admin may apply

• They may add or rebuild indexes, investigate backend throttling, or identify tenant-level service incidents.
• For complex scale issues they can propose architectural changes: split the list, use Power Apps or Dataverse for high-volume scenarios, or migrate heavy relational data to a proper database.

Microsoft support will expect clear repro steps and timings. The more precise the data you provide, the faster they can identify whether the cause is tenant configuration, service throttling or list design.

Conclusion

Start with the quick, reversible checks (private window, minimal view, alternate network) to isolate browser or network issues. If the list itself is the problem, add indexes, simplify filters and columns, and reduce JSON formatting. Measure with browser dev tools and, if the issue persists across users, collect diagnostics and escalate with Microsoft support or your tenant admin.

Frequently Asked Questions

Can I safely delete a column to speed up a list?

Deleting a column is destructive unless you export its data first. Export the list or column data to Excel before deleting. Prefer hiding the column from views or removing formatting first; only delete if you’ve preserved the data.

What is the list view threshold and how does it affect performance?

The list view threshold prevents queries that require scanning large numbers of items; it causes some views to fail or be slow when filters aren’t indexed. You cannot change the threshold in Microsoft 365; you must adapt list design and indexing to avoid queries that exceed it.

When should I move data out of SharePoint Lists?

If your list consistently needs highly relational queries, many lookups, or handles transactional workloads at high volume, consider Dataverse or a database. Only plan a migration after you’ve tried indexing, view optimization and denormalization and verified they don’t meet performance needs.