I've written before about various optimizations I've done to Spanning Feed Builder, but I just made a change that will have a dramatic impact, not only on load times of the S-Control, but also on my bandwidth bill.
When a user logs into Salesforce.com and clicks on the Feeds tab to access SFB, a back-end process builds a model of that user's objects and fields and ships it down to the browser as a big glob (somewhere north of 500K in size) of JavaScript. Until now, that big glob was getting sent every time the user returned to the Feeds tab. But now that glob is cached by the user's browser1 along with the user's Salesforce.com session, so after subsequent clicks on the Feeds tab result in almost immediate screen redraw. This is a big usability win.
The only downside is that in the rare event a user modifies his object model, say, by adding a new custom application, object, or field, the Feeds tab will have out-of-date information—but only for the duration of the current session. So logging out and logging back in brings the Feeds tab up to date. (Navigating around the site long enough for the session ID to change will work too.)
So one big optimization is done, and only one design flaw is yet to be addressed before next week's announcement.
1 Unless that browser is Mac OS X Safari, which completely ignores cache directives. Ugh.
I