Performance problems with huge team project

#1

Hi together,

for my company I’m organizing and working with a huge team project that contains a nearby fully interactive prototype. This prototype has a local file size of 123 MB; the local team project folder on my device shows 1.88 GB. Actually it is not possible to work fluently with this file because the performance is very very bad (using 2015 MacBook Pro Core i7 and a brand new 2016 MacBook Pro Core i7)

Even after splitting this prototype in several parts we have big performance problems. Local file size of the splittet part is 26 MB, team folder on my local devices shows 425 MB.

The prototypes contain a huge amount of interactive features and dynamic panels. But it seems that Axure is not able to manage this depth of interaction and features fluently. Can someone tell me, what we could do?

Edit: The performance of the generated HTML prototypes is ok - not really fast but acceptable. But working in Axure on these files is not possible - I have to wait after every action 10-20 seconds.
BR, Chris

#2

Hi Chris,

Thanks for those details, and I’m sorry to hear about the slow performance. Would it be possible if you could share the exported team project file (“File > Export Team Project to File”) so that we can investigate the causes of the lag? Although it does sound like a content-heavy project, we’d like to make sure there aren’t any other possible culprits for the slow performance other than the sheer number of widgets and interactions. Please feel free to share that here on the forum or through our main support channel at support@axure.com if you’d rather keep the file private. (Since the project is pretty big in terms of MB, I believe you’ll need to upload it to a file-sharing service like Google Drive or DropBox and then send us the link or invite us to it.)

I’d now like to mention that the current release candidate (build 3317) includes some optimizations that should speed things up a bit when working inside Axure RP. One of these optimizations fixes a lag we found behind using the autosave feature. Please give the release candidate a try to see if there’s an improvement in performance with your team project:

Release Candidate | Axure

Since this is a release candidate, it may be prone to more bugs than a public release. We’d recommend trying out the release candidate solely for testing purposes and keeping and using the public release (build 3312) for important work until the release candidate is pushed out to the public build.

Lastly, our team was wondering if you would be willing to do a screen share with us. Having the team project file will be helpful, but doing a screen share will also allow us to observe in closer detail the slowness you’re experiencing on your end to see if there are any other possible culprits for the lag and to compare it to the slowness we observe on our end when testing your team project. If that’s something you’d be interested in, please email support@axure.com with the date and time that works best for you, and we’ll be glad to set something up. Thank you!

#3

Hello Jane,

thanks so much for your fast and detailed reply! Of course I’m actually a little bit stressed cause performance problems but to know that Axure has this great support makes life much easier :wink:

I’m not allowed to share our files without a confidentiality agreement between Axure and our company. Because many SAP employees are working with Axure it would really make sense to sign an agreement. Would this be possible and how do you handle problems like these with other companies that are not allowed to share files without an agreement? If it is not possible I would like to do a screen sharing.

Could you tell me if Axure has performance problems with a lot of pages within a prototype, so would it make sense to split it into several files? We have about 50 pages in our project. Or are too many dynamic panels and widget groups on one page the bigger problem?

BR, Chris

#4

There are a number of things you can do to alleviate performance issues with large prototypes. I’ve not dealt with one of quite the same size as yours, but have in the past found the most effective measures have been:

  1. Identify parts of the prototype that I expect to update only rarely and convert these into images inside masters. For example, headers and footers.

  2. Split apart the prototype and then use iframes to link them together.

Obviously, it depends how interactive and complex the prototype is as to whether the above are feasible. There has also been discussion in the past about the use of different approaches (eg whether trying to keep the number/size of repeaters or panels down), but this seems largely to depend on the version of Axure at the time of the discussion. Using grouped items slowed things down a lot a few months ago, but since an update fixed that it’s not been an issue.

Would be interesting to see what Axure says about all this though, since performance is a bit of a perennial thing.

#5

Hi Jon,

our project has more app- than website-character and our protoype is not only used as building instruction for dev but also used by marketing and sales for presentation events. So it would be a problem to “remove” interactive parts of it.

Splitting doesn’t solve the problem because the main interactions happen on a view pages that contain a lot of interactions.

Seems that I just overstrained the features that Axure offers. Axure seems just not to be able to manage this high level protoyping of complex applications or websites.

#6

Hi Chris,

A confidentiality agreement is absolutely possible. Once you email support@axure.com, we’ll have an NDA ready that we could send to you right away.

Regarding the general causes of slowdown in Axure RP prototypes, the speed of the prototype has a strong correlation to the amount of widgets you have on a single page, as opposed to the size of the overall project. If you had 2 files that are both 50MB in size, but one file had 1000 widgets on a single page, and the other file had 250 widgets spread over 4 pages, then the second file would be a lot faster, both in Axure RP and in the browser.

As JonB mentioned, the best way to go about this is to reduce the overall amount of content you have on a single page, or to split up the content-heavy page into several, smaller pages and then link them together where it makes sense for your project. If you’re working with multiple nested dynamic panels, try un-nesting them or breaking them up whenever possible. If you’re working with big images, try optimizing them via right-click > “Optimize Image”. If you’re working with adaptive views, make sure there aren’t any unnecessary unplaced widgets throughout the file. For more details on performance impacts, this post from one of our engineers should help:

Axure 8, MacOS: Slow like watching paint dry… like Axure 7…

With all that said, we’d still very much like to investigate the slowness you’re experiencing in your file. Once you email support@axure.com, we’ll get the NDA set up so we can start diagnosing the issue. Thank you!

#7

I agree that you may well have “overstrained” the features.

Not that this is any help to you now, but I’ve come to realise that knowing when to stop when it comes to prototyping is a fine art. And it’s not just the fact that you can make a file too slow. Sometimes I’ve painted myself into a corner on something and made it hard to modify. That, in my book, is one of the worst mistakes I can make if I think my prototype is leading my design decisions. I don’t mean to say you’ve let this happen in this case - I’m just recounting my own experience.

I also find it’s rare that more than half an application consists of complex or novel interactions that need to be demonstrated in detail. Often you can rely on people’s prior experience of other applications. For example, I would not (now) prototype any standard geographical mapping with Axure, because people are familiar with how Google maps works. I can just cite that as a reference implementation.

#8

Hi all,

@Jane: Thanks again. I sent a mail out.

@Jon: Thanks for your input; I absolutely agree to all points. My actual project has some special conditions that make it necessary to create more interaction details than I’m used to do. For example we use a form design that makes it necessary to create own form elements like buttons, checkboxes and textfields as dynamic widgets. Finally we reached the performance limit earlier than I thought. I really did not expect, that this limit will be reached with an amount of maybe 50 widgets per page. Also I’m surprised that Axure seems to run much faster on a Windows than on an Apple system.

#9

Hi again,

this morning I tested our file on a 3 years old Macbook Pro Core i5, using Axure 8 with Windows 10 running on Parallels Desktop. And it is MUCH faster than using Axure with MacOS Sierra on a brand new Macbook Pro Core i7 without emulator.

Using Windows with Parallels, I have to wait max. 2 seconds to open one of the big pages, but it is possible to work fluently on them. The same file with Axure 8 on MacOs Sierra on a faster machine is running so slow, that it is not possible to work with it.

It seems, that Axure 8 doesn’t really work with MacOS. That’s really frustrating.

BR, Chris

#10

Hi Chris,

Excellent. We received your email and someone from our support team should respond to you soon with the details of the NDA.

I do want to mention that we do have some big optimizations coming down the pipeline, specifically targeting large files on the Mac version of Axure RP. We’re unable to give a definitive timeline of when these optimizations will be released, but rest assured, we are actively working to ensure that the Mac version of Axure RP is up to the same speed as the Windows version.

If anyone has a file that is particularly slow, please first try out the release candidate (8.0.0.3317) here:

Release Candidate | Axure

If you’d rather stick to the public build (currently 8.0.0.3312) or you see the same slow performance with the RC, we’d like to take a look at the specific file that is exhibiting the lag. If that’s something you’d be interested in, feel free to share the RP file here on the forum or send in the file to support@axure.com so we can investigate. Thanks all!

#11

"It seems, that Axure 8 doesn’t really work with MacOS. "

Ah yes, I forgot about that. Traditionally with Axure, if you want to create big complex prototypes you need Windows. That might change in the future mind you, but for many years that’s been sort of an unwritten rule I think.

#12

Hi!

Yes, I ended up buying a fast PC specifically for Axure and setting my Mac aside. Axure is far slower on the Mac than on the PC when dealing with complex pages. I really hate Windows, so this is something I wouldn’t have done unless it was absolutely necessary!

#13

I always request a Windows PC in the workplace myself, not just to make Axure faster but also because things like Outlook and corporate network accounts and things work so much better (and have more features). As a Mac user, you’re always a second class citizen in a large business environment.

closed #14
unlisted #15
archived #16