Opening a dialog is slow despite caching

When I want to show a dialog in an Atlassian Connect module that is not full-screen, for example in a macro or on a general page, I need to use AP.dialog to make sure that the backdrop fills the whole screen and not just the opener iframe. To use AP.dialog, a dialog module needs to be defined in the app descriptor. Unfortunately, another module also means another iframe whose content needs to be loaded, meaning that there will be a delay when the dialog is opened. Particularly in cases where the dialog is a simple confirmation box, it is quite a limitation to the user experience when that dialog takes several seconds to load.

I have already managed to speed up the loading of the dialog by using cacheable modules:

        "dialogs": [
                "key": "dialog",
                "url": "/app/#app=dialog&moduleType=dialog",
                "cacheable": true,
                "options": {}

Setting the cacheable property to true means that Confluence will not append all those query parameters like jwt and so on to the URL, making it possible to make the browser cache that resource. Like this, I have managed to make the content of the dialog iframe load instantaneously.

However, the dialog still takes several seconds to open. The reason is that Confluence makes a request to https://<name><app key>/<module key> to find out the URL of the dialog module. This request takes at least one second to load and is not cached.

Has anyone found a way to open a dialog without a delay? It would even be useful if I could open a dialog that simply loads about:blank and I would modify the DOM manually from the opener iframe. But I have not found any way that would make Confluence avoid making an additional request before showing the dialog.

Hi @candid ,

When cacheable app iframes originally launched, we didn’t have module caching which resulted in the behaviour you observe - i.e. the dialog module is resolved at the time of launching it. However, shortly after the launch of cacheable app iframes, we implemented front end caching of modules under ACJS-960: Update content resolver to check WRM for cache-able url before going to the server.

I’m seeing the same behaviour as you - it seems the dialog module is being resolved at the time of launching it, despite the module being tagged as cacheable: true.

I don’t think prefetching the module will provide a workaround since Confluence doesn’t provide caching for the module resource.

If you’re interested in understanding some of the interactions, you can visit to see interactive illustrations and simulations of various scenarios.

I’ll ask the Connect team to investigate this matter.


1 Like