A few "nuggestions" from "Proven Practices for SharePoint Online Portals - Performance"

  • Article

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
    -