So we have a unique problem with our Easy Drop Menu Cloud app. By its very nature clients tend to use far more than one of the macros per page (especially when used in conjunction with page properties/page property reports). Some client instance contain up to 200 macros per page.
We have been experiencing horrible performance in such cases. After a lot of head scratching, enabling cacheable macros, and caching of static assets in browser we are no closer to better performance.
Inspecting the waterfall model in chrome dev tools, we noticed that the initial requests (initiated via the app descriptor) stalls, sometimes for up to 20+ seconds. After reading up we saw that each browser only allows up to 6 TCP connection at a time.
The current assumption is that each macro being render in an iframe opens up a new connection and therefor many of the requests first stalls.
Is our assumption correct? If so is their anything we can do about it or are we pretty much limited by how many iframes we can load without stalling a request?
Any feedback, suggestions or comments would be much appreciated.
Each iFrame is very similar to a new browser tab. Opening 200 browser tabs and loading then quickly will be very very tricky to make fast; if it’s possible at all. @dmorrow what would you recommend here?
Despite you declaring the module as cacheable, it’s possible the browser still needs to create TCP connections to check if it has the latest version of your resources. You may be able to do some tuning of your app and its serving of resources to minimise this. You’ll need to look at your browser’s dev tools to see what network activity is taking place.
When I spoke about this at Atlas Camp in Barcelona a couple of years ago, I wrote a simple app that illustrates the key interactions. Whilst it may not be the most intuitive app, it may help with your understanding of what is going on to search each iframe. You can see it by visiting https://webtimingdiagrams.atl-paas.net/.
Did you consider not loading contents of iframes which are not in the viewport? Loading the same cacheable page 200 times should not stall, I guess the problem is caused by additional resources loaded by your app, and that’s how you hit the 6 connection limit.
This should be responsibility of Atlassian Connect and Confluence, to not load below the fold content, but still you can do it on your own to some extent. You won’t be able to eliminate that initial request.
This does depend on the browser you’re using (older versions of IE only allowed 2 connections at a time… - I just dated myself ).
If you’re looking at chrome it’s 6 connections per hostname and a total of 10 connections all together. Best way around it is to upgrade your serving infrastructure to http2 instead of http1.1 since that does raise the connection limit.
A hacky way of getting increased connections (but you’re limited to 10 in Chrome) is to serve your assets inside the iframe on a different domain.