Unpublished pages and slow performance

rp-7
#1

We have a prototype with many pages and many objects per page
and lots of case logic.

I have noticed, when prototypes get really large, they can slow down and take longer to generate,
longer to surf in the browser… and longer to move from tab to tab in Axure itself

I have a theory that slowness is based on page complexity…
not the number of pages in the RP file.

Which raises a question…

If we have 100 pages in a prototype… but we only open 10 for editing and generation
(leaving 90 pages ungenerated and unpublished) … would the performance be better?

I’m not sure it would be possible to break our pages into more smaller ones… but
we could leave a number unpublished at any given time.

Thanks

#2

Hi Sking,

Let’s see if I can offer some info you’d find relevant:

Preview:

The way the preview works is that Axure RP creates a local server on your machine that serves up the specific page of the project that you are previewing. It only generates one page at a time–as opposed to the whole project–allowing you to do quick views. Slow load times when previewing are probably a result of the size of a single page.

Generating HTML:

This will generate as many pages as you have selected in the “Generate HTML” dialog and the length of time it takes to generate will depend on the respective sizes of all the pages. When viewed in a browser, the individual page size is the biggest determinant in the load time.

Publishing to AxShare:

Regardless of how many pages you are generating, uploading to AxShare will always upload the entire .rp file, un-generated pages and all. Then on top of the uploading, it needs to generate the pages you’ve specified. Once again, when actually viewing the project in a browser, the individual page size is the biggest determinant in the load time.

Working in Axure itself:

The program should keep the 10 most recent pages/panel states cached. That way you don’t actually have 100 pages “open” for editing, so to speak. But still, the larger the page, the more likely you are to see slow performance when arriving, leaving, and editing that page.

So I’m afraid that the performance you are seeing is most likely a result of your individual page sizes.

While there aren’t any technical limits to the amount of widgets you can add to a page, we do recommend not using more than 30 Dynamic Panels, 100 total Dynamic Panel States, 1 to 2 Repeaters, or 500 total Widgets per page if you want nice quick pages in your output. This is especially true when prototyping for mobile devices.

#3

wow… we have a lot more than 30 DP’s ( by an order of magnitude : ) … great food for thought. .thanks much !

#4

Whats the maximum pages, without any functionalities - wireframes only w/ masters, do you recommend using in a single file before it becomes unstable?
We have a product that will probably contain more than 300 pages and more once it is fully built.

thx for the info
Cheers

#5

Hi trck,

It’s possible that a prototype with a large number of pages could experience a slowdown in performance just due to its overall file size, however prototype performance is more tied to the number and type of widgets on those pages. The general recommendation per prototype page is to aim for around 500 widgets, 40 dynamic panels, and 100 panel states or fewer. I’d recommend checking out Ian’s post here, where he provides a more detailed breakdown of this:

Keep in mind that while prototypes are more likely to perform better under these numbers, other factors (such as file size and the types of interactions on the pages) could definitely have an impact on performance as well. If you’re seeing that the total number of pages in your prototype is affecting this, you could also try splitting it up into separate prototype and then linking them together.

I hope this information is helpful!

unlisted #6