Adding base64 inline attachments can be slow

[barclayadam]

Hi team,

We have been getting reports from various customers regarding our add-in being slow. Through investigations, we have found every time it's how Outlook is adding inline image attachments (base64).

Your Environment

• Platform: PC Desktop & OWA
• Host: Outlook
• Office version number: 16.0.16721.20002
• Operating System: Windows 11
• Browser (if using Office on the web): Chrome v115

Expected behavior

Attachments are added quickly, not delaying the response to the add-in

Current behavior

Adding an attachment can be slow in some circumstances and always in OWA, sometimes with delays being close to 1s. We have created a test add-in that adds 4 base64 image attachments (in parallel) and then uses cid: references to those in the HTML signature we set.

OWA is consistently pretty slow:

Embedding image took 0.713s
Embedding image took 0.907s
Embedding image took 1.112s
Embedding image took 1.332s
Embedding images using base64 inline attachments took 1.333s

Desktop is slow in non-cached mode:

Embedding image took 0.986s
Embedding image took 1.807s
Embedding image took 2.256s
Embedding image took 3.272s
Embedding images using base64 inline attachments took 3.273s

Desktop is incredibly fast in cached mode:

Embedding image took 0.065s
Embedding image took 0.068s
Embedding image took 0.079s
Embedding image took 0.083s
Embedding images using base64 inline attachments took 0.084s

Based on the timings, and from watching the network (in OWA), we can see that adding attachments is making network calls that, regardless of our code, are being down serially and not in parallel:

In addition in OWA further network requests are made to then get the thumbnail of this attachment, adding further to the delays:

Steps to reproduce

1. Run the below add-in in OWA and PC with cached mode on and off.
2. Observe the timings from the logs

Link to live example(s)

1. Gist with source code for event-based add-in: https://gist.github.com/barclayadam/e9219672abf986bd3eb391df1ec8573e
2. Add-in: https://outlook.signature365.com/imageembedmanifest.xml

Context

We are getting reports from customers that adding a signature to their emails can be slow, but there appears to be no extra we can do to improve the speed as it is primarily taken by the adding of these inline attachments.

We have considered switching to inserting a signature with direct HTML references to the images and THEN embedding the attachments and updating the signature again but have noticed flickering in OWA when the images are changed.

We would love to see:

• Attachments added in parallel if we are adding multiple
• OWA being able to drop the 2nd requests for getting a thumbnail, we have already provided the base64 version of the images to display
• Long term an improvement to the setSignature API that could handle the adding of inline images. For example could we provide all relevant base64 images and the HTML with links to these attachment objects and Outlook takes care of adding the attachments (and removing old ones if signature changes) and displaying in the most efficient manner possible.

Thank you for taking the time to report an issue. Our triage team will respond to you in less than 72 hours. Normally, response time is <10 hours Monday through Friday. We do not triage on weekends.

[exextoc]

Thank you for reporting this issue. We are investigating this behavior and will update the thread with next steps.

[barclayadam]

This issue still exists, and we regularly see customers' reports of this slowness. This also affects New Outlook meaning it is becoming more prevalent as that is used by a growing percentage of our customers.

Is there any possibility of this being fixed? To require 2x HTTP calls for every image being inserted means that for some of our customers with large image counts the insertion of a signature can be particularly slow (with some calls to addAttachment taking upwards of 2 seconds)

[barclayadam]

Further to the above we have a customer that is experiencing delays of 30 seconds per call when attempting to attach inline base64 images in OWA. From our logs we can see that we attempted to insert 5 images, with response times from the Outlook call as below:

10 July 2024:

12:44:13 [messageCompose] [DBG] addBase64FileAttachment completed in 0.367s
12:44:43 [messageCompose] [DBG] addBase64FileAttachment completed in 30.288s
12:44:43 [messageCompose] [DBG] addBase64FileAttachment completed in 30.482s
12:44:43 [messageCompose] [DBG] addBase64FileAttachment completed in 30.674s
12:44:44 [messageCompose] [DBG] addBase64FileAttachment completed in 30.804s

Note that "addBase64FileAttachment" is just our wrapper name for the addFileAttachmentFromBase64Async call

[dahuja10]

Hi @barclayadam, thanks for reporting this issue, we are able to repro it. It has been put on our backlog. We unfortunately have no timelines to share at this point. We appreciate your understanding and apologise for the inconvenience caused.

tracking id: 3829922

[MrDaleQ]

Hi @dahuja10

As noted to Akshayta, this issue appears to affect every client currently using New Outlook throughout their organisation.

I would assume that the addFileAttachmentfromBase64Async method is affecting other New Outlook users - it would be extremely useful to have some idea on timescales to share with customers that are affected by this issue.