A few “nuggestions” from “Proven Practices for SharePoint Online Portals – Performance”


nuggestions = nuggets of suggestions

https://msdn.microsoft.com/en-us/pnp_articles/portal-performance

I am often asked/told/screamed at "Hey Tadd! Why is my SharePoint page/site/site collection/etc so slow?"

"What can I do as a designer/developer/site collection administrator do?"

  • A few of initial questions:
    • When did you first notice or was it reported that your "SharePoint" was slow?
    • What did you do?
    • What has been modified?
    • When was it modified?
    • Does your Site Contents page load quickly?
    • Did you compare before and after Network "traces" with F12 developer tools and your browser?
    • Did you compare before and after with Developer Dashboard (if accessible)?

From the link above, I have converted some of the anti-patterns to questions  applicable to almost any on-prem, cloud, etc implementation.

Anti-Patterns (in other words, don't do these things)

  • Build custom client-side controls that issue client-side data requests to SharePoint and add a dozen or more of them to the page
    • What has been modified?
    • When was it modified?
    • Did you compare before and after Network "traces" with F12 developer tools and your browser?
    • Did you compare before and after with Developer Dashboard (if accessible)?
  • Implement your client-side controls without centralized data access to the SharePoint data, so that numerous controls are requesting exactly the same data numerous times in a page
    • tsk, tsk
  • Embed redundant custom JavaScript and CSS throughout the page body
    • If I had a dollar for every time I saw the same libraries loaded multiple times from non-cached locations and then collisions and craploads of stuff, I would have many dollars.
  • Embed several 10MB thumbnail images throughout the page body
    • Review your images for optimization for filetype, size, color, etc etc.
  • Execute all client-side data requests at page load time, even if the data is not initially needed/displayed, even if it might never be used
    • tsk, tsk
  • Inject unnecessary order dependencies into the data request sequence and use synchronous data requests to ensure the order of execution
  • Use the legacy SharePoint Lists (SOAP) web service as the data request API of choice and pass it poorly-formed CAML queries
  • Avoid caching data responses (especially for static data) on the client to ensure that each data request gets re-executed on every page load
  • Perform hundreds of updates to the Document Object Model (DOM) of the page as each data response completes, even if they are redundant or conflicting

 


Comments (0)

Skip to main content