Project-level Best Practices for delivering a performant Add-in based application

Indeed, all of the below are open doors!!

But yet in practice often either overlooked, or on purpose but due wrong reasoning (e.g. save time now in the project) bypassed in development project(s) to deliver a SharePoint Add-in based application:

1. Performance and Capacity Management must be applied as an integral subject during the application development project
2. In the requirements, agree with the application owner on the performance aspects: page download times considered acceptable, applicaton parallel usage
3. Include performance Best Practices in the development guidelines. And make sure that all involved developers know of the guidelines, and that they apply them in their individual developed Add-Ins
   • PnP Guidance: SharePoint Add-in Recipe - Performance Considerations
   • Tune SharePoint Online performance
   • MS Ignite 2015: Best Practices for Design and Performance in SharePoint Online
4. Do not only develop + test SharePoint Add-ins ('Apps') in isolement; also conduct integration test with multiple Add-ins on a page as the user is likely to use them, and monitor the page payload
5. Thorough intake of any external Add-ins before before purchase; intake on architecture, functionality, capacity management and maintenance aspects
6. Structural monitor and proof the application performance during the project, to detect in early stage when something is introduced with a severe performance decrease impact. Load testing is a good means to implement this in the project, for performance quality assurance

Some architectural and technical tips

• Cache where appropriate (but be aware that caching costs resources itself)
• Reduce the number of network roundtrips from client to application server - batch requests
• Retrieve resources that are used in multiple Add-ins from a shared location - e.g. root site of the HostWeb, or a CDN (external or internal)
  • SPCAF: Loading a JavaScript library from a CDN
  • IT Unity: Managing JavaScript References in Office 365
• Reduce the impact of (NTLM) Authentication by retrieving non-authorized resources from anonymous accessible location
• Utilize the sprites-concept for images
• And the same for custom javascripts; for maintenance it is good to separate responsibilities in different libraries, but for performance it is better to collapse in a single resource file
• Apply minimalization in resource files: javascript and CSS resource files
• Apply lazy loading where appropriate (e.g. avoid processing and retrieval impact for Add-in functionality that is initial non-visible, and/or only rare used; in favor of delayed execution if and only if the user intends to use the Add-in)