happy Easter to you, too.

I moved your comment from where you posted it to this post, as it belongs to this discussion. Please stick to discussion threads to keep confusion for other readers low.

The thing is, there is no WordPress mechanism (action or filter) to adjust widgets at page generation time. Instead, the morphing takes place with JavaScript, after the page was loaded. It has nothing to do with CSS “execution”. That’s also why “auto-close” is possible, but “start-closed” not.

I think it’s possible to tweak the theme to achieve better perceived performance, but not in a generic way usable in all context, or all themes. Unfortunately, since widget code is by no means bound to any rules regarding its output, tweaking the theme may not do it all.

(this post is about the delay of colapsing on page loads)

I read the link you sent me to and the tweeking manual, but I don’t see there mentions of why there’s no “start closed” as opposed to “auto-colapse”. But yes, I understand that there’s a problem if your css is executed too far down the line, leaving the auto-colaps elements visible a bit at the begining.

Also I was wrong: 1.0.2 showed the same behaviour, it’s just that I noticed it after the upgrade. It’s understandable that on a local server it gets done really fast. But for example, on your site, a page refresh gives a noticeable delay on the colapsing of the archives list (I have a 5Mbit link).

I have to say I have quite a few widgets on my site… but I’ll play with my theme a bit see if I can hide them from the start.

actually, the changes that I made only affect cases with ill-formed widget bodies, so there should be no difference in perceived performance to the prior version. (There are no “start closed” items, only “auto-collapse” items. I’ve elaborated on the Why’s in the Theme Tweaking Manual.)

The effect you describe was there before, and it’s “visibility” depends on what other JavaScript code is executed else (Analytics, Ads, Membership Logos etc.) Perceived performance also depends on whether you have moved JS to the footer (by means of the Footer JavaScript plugin, for ex.) or not, and how many widgets are processed/collapsed in total. For ex., on my local test server, without ads and analytics, the time between loading the page initially and collapsing the selected widgets is so short I don’t ever see it.

However, if there is a difference on your site, I’d appreciate it if you could re-install the prior version (as you have already changed the tag cloud widget), so I can have a closer look at what might be causing it (at my site there’s no difference to before).

Thanks.