I’m experiencing a highly annoying issue with RW, where almost every operation causes a lag, spinning beach ball for five or six seconds, and throws constant messages at the log. Here’s a sample of the console msg:
30/09/2015 11:02:37.479 WindowServer[191]: disable_update_timeout: UI updates were forcibly disabled by application “RapidWeaver” for over 1.00 seconds. Server has re-enabled them.
I’m getting 20 or 30 in rapid succession, and it’s causing RW to crawl.
Does anyone have any idea what this might be caused by? It’s particularly bad when I click away from RW to another app, and back again: that’s guaranteed to stop me working for 20-30 seconds, making it very tiresome to copy/paste, or even refer to another document.
My RW file is large, and it’s full of stacks and globals, making it difficult for me to pinpoint any one area. It’s got lots of pages, too, and whilst I’d like to separate-out individual site areas into separate RW files, I can’t think of a particularly easy way to integrate them all without extensive work.
Mmm… a little odd, but it’s improved after some work on the file.
I’ve been looking at Stacks 3’s new features, and decided to tidy up some pages by Hiding stacks and creating a few Partials to use throughout. This initially only appeared to save some file size (down by around 15MB).
However, about 80% of the way through tidying the pages (about 300 of them!), the lag suddenly went. There’s still a little delay and the odd spinning beach ball when moving between apps.
Console is still showing issues, albeit different to the original message, but they’re certainly not firing off every few seconds as before.
I’ll keep an eye on things and see what I can find.
Without specific info, I can only make guesses as to what might be the issue. Things I’ve seen cause radical slowdowns in other custom projects:
Lots of remote images
Some stacks do “image warehousing” – this can be great at speeding up opening your file – but if you have a page which needs to download dozens of images from the internet – then it will be very slow – and slower still if your internet connection isn’t super fast. Solution: consider using normal image stacks – or if you’re building up a gallery by hand – consider using a stack that’s specifically designed to make that easier/efficient.
Other remote content
Some stacks load Fonts and/or JS Libraries from the internet. Just like above, that comes with a cost – a cost that is very much larger if your internet connection is large. Solution: if a specific stack is causing performance issues report that to the stack designer. Perhaps they are unaware that the issue exists.
Older stacks – especially globals
Stacks 3 came with many great new advances. But some things are so new and different that they aren’t added to your existing files automatically. Some stacks will be most efficient as you create new pages. This is especially true of Stacks like Foundation that have switched from using Global content (which can be slow on large sites) to Partials (which is much much faster).
Or… it could be something entirely different. And this is probably the most likely thing. Of the last few times I’ve looked at specific customer problems with similar symptoms (slow, beachballs, etc.) – all had entirely different causes.
@Isaiah I’m a bit surprised that you say that about remote images. I create all my sites using warehoused images and I haven’t experienced serious lag, despite having dozens of images, a slow internet connection and a very slow computer.
i’m not saying warehousing is good or bad – it is what it is: a solution that comes with some minor costs. but in large files those costs can build up.
let me give you the details of what i saw, why it didn’t work, so you can see the specifics.
a user had a number of pages selling jewelry. each page consisted of a 6x6 grid of image thumbnails (with prices and buy buttons, etc.). when clicked, the images would show a full size light-boxed image. really a very nice site.
but editing the page was torturously slow.
the pages used a stack (sorry i don’t remember which) that warehouses images and allows for separate versions for mobile and retina (4 images total).
each piece had both a thumbnail and the large version of the image. so 2 images * 4 version * 36 items = 288 images. on each page.
many were small, but full size retina images are not – they were all over 1MB. each time the page needed to redraw (stacks are heavily cached, but needs to flush the cache sometimes) it had to re-download ~300 images – many of which where over 1MB. The result: > 100 of MB download on each cache flush. Over a < 5Mb connection that takes a considerable amount of time. > 30 seconds not even considering server latency.
much of this happens in the background, so goes unnoticed as the images fill in, but some of it cannot (Webkit requires all calls to be on the Main thread – the foreground – delays of the main thread are what causes a beachball).
the takeaway from this should not be: warehousing is bad. but… working with hundreds of MB of images over a slow connection is difficult and requires a lot of thought and planning at every stage.
or a lot of patience. probably a good deal of both.
Thanks for the pointers. The more I work with the file, the more I’m erring towards it being an issue with my Globals (ouch). Theses are used extensively throughout the site for item SKU and prices etc, as well as some other bits and bobs.
I don’t use warehousing, but there’s extensive Java calls, and the site is responsive (although multi-sized images are only used by the theme itself). I’m also using FontAwesome and web fonts, which I’ve had issues with in the past. I’ve ironed out most of the problems with these, but, of course, updates often highlight problems not apparent before.
I’m slowly going through and trying to tidy-up and concatenate as much as I can. I’m loving the new Partials feature in Stacks3, and may try using those instead, although I can imagine that using this extensively could also conceivably cause slow-downs (?)
If only version 3 was out when I built the site last year!
One comment: You’ve jumped to a possible conclusion (Globals) without a lot of testing/data to back up that up. This is akin to guessing what illness you have and then starting treatment without consulting a doctor or doing tests. It is very likely to make the patient sicker.
I would strongly encourage you to test your theory on a copy of your project file. Try removing all globals from a page and see if the page speed improves. If not, try remove other things. Simplify the problem until you’ve found the actual cause. Once you know the actual cause you can move on from there.
Isaiah
Just to clarify:
Javascript does not affect the speed of Stacks edit-mode. Edit mode does not enable Javascript. (and Java is a different language that, confusingly, has nothing to do with Javascript)
In Stacks 2 Globals did have a significant impact on performance. In Stacks 3 it is significantly improved, but there are still some significant impacts.
Partials were designed to be fast from the start. They will not have the same performance bottlenecks that Globals do.
Yes: all your points are noted. The site is a live site, so a copy is always used to edit and test.
I’ve been working on the site on-and-off for a while now, and it all seems to have settled down. I’ve replaced a number of globals with partials – although there are still quite a few – as well as a few non-global stacks, and the file feels like it’s back to normal now. No lags or pauses when switching apps, pages or files, and I’m not confronted with the (newer flatter) spinning beach ball at every step.
Hopefully that’s sorted the worst of the problems. When working in other sites, I have noticed a speed increase over previous RW / Stacks versions, which is great, and publishing certainly seems snappier.
