The reliance on Office.js (and its dependencies) delivered from the network proves to be challenging in some scenarios. While ideally the platform would support full offline use, I'm hopeful that there are some incremental improvements that could be made to address some of our challenges in the shorter term.
As an example, our add-in hooks into Outlook's OnMessageSend, which inherently puts it on the critical path of the user experience when sending emails. In scenarios where the user's network is slow or unreliable, or in an event of an Azure CDN outage that makes Office.js unavailable or slow to be delivered, the user experiences a long wait while Office.js is loaded on message send. I should highlight that Outlook attributes this delay to the add-in: "Add-in X is taking longer than expected". I'd like to propose that the platform gives the add-in more control over the user experience in these cases.
What this would look like for our OnMessageSend add-in is that the add-in would execute some code outside of the event handler (before Office.js finishes loading) to start a timer, and if the loading phase exceeds a timeout value defined in the add-in code then the add-in would instruct Outlook to conclude the processing of the event (similarly to how event.completed() is invoked inside an event handler). That last part would require some interface with Outlook that is available even if Office.js hasn't been fully loaded.