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
  -