"Preview" speed increase in Sierra?

(Lisa Sandler) #21

I have one page like that myself… my blog page, using Poster Stack takes 30 seconds to preview as well.

(Mathew Mitchell) #22

Wow, these are weird numbers. I have one Poster blog page (not too many posts right now). 4 or fewer seconds. 3 to do the “prep” work, 1 to load the content. I’m happy with that. But 30+ seconds is a bit too long.

My longest to preview page is 20 seconds. But this is a very special use of the Formula stack. It uses several fields to teach students about statistical regression. Once created I don’t need to preview again. The same page takes 4-5 seconds to load once published.

(Jannis from inStacks Software) #23

I did a lot of performance tests. Generating 1.000 Poster items takes 25 seconds :wink: Not me…

(Lisa Sandler) #24

It’s my massive amount of images, I’m sure, but no way around it. That’s 99.9% what my blog is.

(Rob D) #25

When I go to Preview right after I launch RW (any page), it takes 15 seconds to render. Interestingly, if I make a small change in the same page, it takes 12 seconds to render (that’s about the fastest Preview time I ever experience). But if I make more complex change – like adding or deleting a stack or creating a partial – the change may take as much as 33 seconds to Preview. Changing the Preview mode (full-size, iPad, phone) also takes about 12 seconds. Go, figure…

I am using MacPro (late 2013 model) with 16 GB of memory and a flash-drive startup drive. RW 7.4.0 and Stacks 3.5.4. All my addons are up-to-date.

BTW, Steve, thanks for sharing your OS-upgrade experience.

(Jannis from inStacks Software) #26

Guys, I have to tell you that it is neither RapidWeaver to blame for that, nor Stacks plugin. IMHO the speed decrease is based on 3 “trends” RapidWeaver users are going to follow:

  1. Usage of frameworks (Foundation, Foundry) in favor of old style themes, because we want to have more freedom. Usage of frameworks needs the usage of Stacks Plugin.
  2. Usage of very impressive and powerful (“heavy”) stacks, which can do a lot, and with this have a lot of settings the Stacks plugin has to parse each time going to preview mode.
  3. Having more content on each page in order to get a one page design. Less pages, more content on each page, and with this more usage of “heavy” stacks on one page.

Easily you can get over hundreds of “heavy” stacks on one page with this. Each of these stack instances contains hundreds to thousands line of code, which have to be parsed each time. If you combine that with additional pictures, which are contained in the page itself, you find the reason for the slow preview and export.

It isn’t RW to be blamed. It also doesn’t make sense to compare to other web development apps, as they have a completely different generation workflow. We have powerful tools available, but we have to use them wisely.

(Rob D) #27

I agree. I do use “heavy” stacks and my pages are rather content-heavy, as well. On top of that, I have to switch between 3 language-versions (on the same page). Luckily for me, on-line rendering is instantaneous.

(Nick Wilcox-Brown) #28

I have not read the whole thread, but a quick heads up on preview speed, and export: certain menu stacks have a terrible effect on preview speed. I have seen it on several stacks, but the one I am currently using for the desktop site is the otherwise excellent ‘SideMenu’ from @1LDskyler Although I love the way it works, preview and site export take around 10 times as long as previously.

Changing OS is not going to resolve this, but in all honesty anyone not using Sierra on a compatible Mac is making a big mistake anyway. It is to use a phrase a ‘No-brainer’.