the answer is yes, but it doesn’t really slow down on modern hardware until you have over a thousand things in your library. so at 100 stacks, don’t worry – you’ve got plenty of breathing room.
the slowness you’ll see is a delay on startup. stacks does a brief look through your library to see what’s there. with a thousand items in the library that brief look starts to take a noticeable amount of time.
but there are two things that really slow down performance:
- many large images on a page.
- many stacks on a page.
when you have many large images there is not much way around it – at some point RapidWeaver or Stacks or WebKit will have to load these images from somewhere and display them on your screen. Depending on how large they are, how numerous they are, and where they’re located (on the page, in the project, or warehoused on the 'net) it can take more or less time.
the best thing you can do, when planning a large project, is make a plan in advance for how you will handle the images. if you have hundreds of images, let a service like google images or flickr handle it. if you have dozens, then perhaps at least process your images and scale them for your site first. dropping huge 50 10+MegaPixel images into stacks and rapidweaver is just asking for trouble.
it takes quite a few stacks on a page before stacks will start to slow down from the sheer number, but i do see projects like this regularly. they usually take the form of a “single page site” – one where many pages worth of info are strung together to create long scrollable pages.
if you plan to build pages like this i’d recommend – again – making a plan on how you’ll handle that early.
consider designing long pages like this modularly. if the single page will be 5 screens long, perhaps:
- design it as 5 pages.
- create a partial of each page.
- setup these pages not to publish.
- create a final page that simply combines the 5 partials.
this way you can edit and maintain the site as if it were many pages – but after editing the final long page is always kept updated with all the changes. the giant page will be made a bit faster by subdividing it with partials – but it really doesn’t matter, since you shouldn’t need to interact with that page much at all.