Optimize web part performance in SharePoint Online modern site pages
SharePoint Online modern site pages contain web parts that can contribute to overall page load times. This article will help you understand how to determine how web parts in your pages affect user perceived latency, and how to remediate common issues.
For more information about performance in SharePoint Online modern portals, see Performance in the modern SharePoint experience.
Use the Page Diagnostics for SharePoint tool to analyze web parts
The Page Diagnostics for SharePoint tool is a browser extension for the new Microsoft Edge (https://www.microsoft.com/edge) and Chrome browsers that analyzes both SharePoint Online modern portal and classic publishing site pages. The tool provides a report for each analyzed page showing how the page performs against a defined set of performance criteria. To install and learn about the Page Diagnostics for SharePoint tool, visit Use the Page Diagnostics tool for SharePoint Online.
The Page Diagnostics tool only works for SharePoint Online, and cannot be used on a SharePoint system page.
When you analyze a SharePoint site page with the Page Diagnostics for SharePoint tool, you can see information about web parts that exceed the baseline metric in the Web parts are impacting page load time result in the Diagnostic tests pane.
Possible results include:
- Attention required (red): Any custom web part that is visible in the viewport (screen visible portion of the page which is loaded first) that takes longer than two seconds to load. Any custom web parts outside of the viewport that take longer than four seconds to load. Total load time is displayed in test results and is broken down by module load, lazy load, init and render.
- Improvement opportunities (yellow): Items that may be impacting page load time are shown in this section and should be reviewed and monitored. This may include "out of the box" (OOTB) Microsoft web parts. Results for any Microsoft web parts shown in this section are automatically reported to Microsoft, so no action is required. You should only log a support ticket for investigation if you are experiencing very slow performance on the page and all Microsoft web parts on the page appear in the results in the Improvement opportunities section. Note that a future Page Diagnostics for SharePoint tool update will further break down the results based on the specific configuration of the Microsoft web part.
- No action required (green): No web part is taking longer than two seconds to return data.
If the Web parts are impacting page load time result appears in either the Attention required or Improvement opportunities section of the results, click the result to see details about which web parts are loading slowly. Future updates to the Page Diagnostics for SharePoint tool may include updates to analysis rules, so please ensure you always have the latest version of the tool.
Information available in the results includes:
- Made by shows whether the web part is custom or Microsoft OOTB
- Name and ID shows identifying information that can help you find the web part on the page
- Total shows the total time for the web part to load
- Module Load shows the time taken to fetch and load the web part components
- Lazy Load shows the time for deferred loading of web parts not seen in the main section of the page
- Init shows the time taken for web part initialization
- Render shows the time taken for the web part to fetch and render results
This information is provided to help designers and developers troubleshoot issues. This information should be provided to your design and development team.
Remediate web part performance issues
Follow the guidance in this section to identify and remediate performance issues with web parts listed in the Web parts are impacting page load time results.
There are three categories of possible causes for poor web part performance. Use the information below to determine which issues apply to your scenario and remediate them.
- Web part script size and dependencies
- Optimize the initial script that renders the mainline scenario for view mode only.
- Move the less frequent scenarios and edit mode code (like the property pane) to separate chunks using the import() statement.
- Review dependencies of the package.json file to remove any dead code completely. Move any test/build only dependencies to devDependencies.
- Use of the Office 365 CDN is required for optimal static resource download. Public CDN origins are preferable for js/css files. For more information about using the Office 365 CDN, see Use the Office 365 Content Delivery Network (CDN) with SharePoint Online.
- Reuse frameworks like React and Fabric imports that come as part of the SharePoint Framework (SPFx). For more information, see Overview of the SharePoint Framework.
- Ensure that you are using the latest version of the SharePoint Framework, and upgrade to new versions as they become available.
- Data fetching/caching
- If the web part relies on extra server calls to fetch data for display, ensure those server APIs are fast and/or implement client side caching (such as using localStorage or IndexedDB for larger sets).
- If multiple calls are required to render critical data, consider batching on the server or other methods of consolidating requests to a single call.
- Alternatively, if some elements of data require a slower API, but are not critical to initial rendering, decouple these to a separate call that is executed after critical data is rendered.
- If multiple parts use the same data, utilize a common data layer to avoid duplicate calls.
- Rendering time
- Any media sources like images and videos should be sized to the limits of the container, device and/or network to avoid downloading unnecessary large assets. For more information about content dependencies, see Use the Office 365 Content Delivery Network (CDN) with SharePoint Online.
- Avoid API calls that cause re-flow, complex CSS rules or complicated animations. For more information, see Minimizing browser reflow.
- Reserve corresponding space for asynchronously rendering media or visual elements to avoid skipped frames and stuttering (also known as jank).
- If a certain browser doesn't support a feature used in rendering, either load a polyfill or exclude running dependent code. If the feature is not critical, dispose resources such as event handlers to avoid memory leaks.
Before you make page revisions to remediate performance issues, make a note of the page load time in the analysis results. Run the tool again after your revision to see if the new result is within the baseline standard, and check the new page load time to see if there was an improvement.
Page load time can vary based on a variety of factors such as network load, time of day, and other transient conditions. You should test page load time a few times before and after making changes to help you average the results.