Builder 3 - Niiiice!
Note: I'd originally posted this a week or so ago but in my haste posted it as a page and not news. So here is the blog version. 
A few months ago, I would have said I was the busiest person alive, but things just keep getting more and more hectic.
Amongst the chaos of a rapidly growing company, I've managed to work on a couple of really tasty projects involving Builder 3 (still in Beta as we've not found time to add the licensing code yet *sigh*).
This post could be seen as blatant promotion for one of our products (well, I guess it is really) but that's not why I'm writing it. I'm genuinely excited about this upcoming release of Builder because the plugin has definitely become what I envisaged when we first started out developing Builder shortly after Adaptavist was founded a few years ago.
The plugin is now mature. It's rock solid, very fast and packed full of amazing features. It's some of these new features that really make it rock my world (and hopefully clients will feel the same).
There won't be any screen grabs in this post because I just don't have time, but I'll try to link to pages in our user guide where you can see a bit more. Some of the user guide pages aren't complete yet but I'll link to them anyway heh.
Centralised Layouts
One of the biggest gripe about Builder 2.x was that if you wanted to use the same layout on more than one space, you needed to download the theme config from one space and upload it to the next space and so on.
Not only was this a tedious process, but it meant that if you changed the theme in one space you then had to repeat the whole darn process. Not nice!
To completely erase this issue, Builder 3 now uses centralised "layouts" (essentially theme configs stored centrally rather than on a space by space basis).
When you want to apply a layout to a space, you can use the Layout Chooser to simply pick from the list of available layouts (complete with live preview of what your space will look like!) or use the awesome new Manage Spaces tool which allows you to centrally administer theme settings and even do bulk updates.
Because the layouts are centralised, changing one instantly updates all the spaces that are using it 
Layout Inheritance
Oh my, this feature really does rock my world. It saves so much time!
Layouts can inherit settings from their parent layout - this means that I can create a master "look and feel" layout and then have other layouts which are based on it but change various things, eg. add side bars or different navigation.
It's probably easier to understand by reading our page on Layout Hierarchy.
Space-level customisations
In Builder 2.x, to customise the theme at space level you had to do just that - customise the theme. For most space admins, being dumped in to the fully blown theme customisation tool is a tad overwhelming to say the least.
When we centralised layouts in Builder 3, we realised that space admins no longer had any customisation options - sure, they could select a layout, but what if they wanted to change the colours or add extra navigation, etc?
So, after much internal hair pulling and chin scratching one of my all time "most wanted" feature requests got added in - the ability to use colours defined in the Confluence "Colour Scheme" within the layout visual editor and custom CSS settings.
One one of the projects I've been working on, this instantly cut my workload by two thirds - instead of having to make 3 layouts just to handle different colours, I now only had to make one and set it up so that the colours could be defined using the colour scheme.
I then started investigating how to make the navigation more customisable and thanks to things like the "include" and "import" macros, that became really easy - just as you can customise the navigation in Atlassian's "left navigation" theme, you can now do the same in Builder layouts, only with far more flexibility.
I've been able to create a layout which, with very little effort on my part, allows space admins to easily add items to the menu bars, sidebars and elsewhere.
Performance
Oh my, we've excelled ourselves! Some of our larger clients were running in to problems with performance. Builder tends to use lots of macros and lots of CSS, JavaScript and image files.
Our first major breakthrough came when we realised just how much overhead there is to process a Confluence macro. Any macro. It doesn't matter how simple or fast the macro itself is, there's a fairly big overhead for Confluence just to render it.
We decided to create a new compound-menuitem macro which combines all the features of the menuitem, menulink and menuicon macros. Furthermore, it has no "body" so as well as shrinking three macros in to one it also removes two "body" renders. The result - menus are instantly three times faster!
Next, we decided to take a long hard look at caching all the various resources. Caching has always been a problem for plugin resources because the "resources servlet" generally doesn't output the headers the browser would need to do caching.
To start with, we combined lots of the CSS and JavaScript resources - so instead of needing something like 11 external files only 3-5 were needed. That instantly takes a fair chunk of latency out of the equation.
We were able to add much improved "cache expire" headers to our CSS files but struggled with the other resources pulled from the plugin. Sure, we could easily have written our own servlet but this seemed insane - surely there was something lurking deep within Confluence that would already provide this functionality...? And there was!
In just a couple of days, we had extreme caching applied to practically every resource imaginable. You still need to load the resources the first time you visit the site, but after that they are well and truly cached by the browser.
We also looked at the internals of the plugin and even the placement of various things in the output HTML (eg. move CSS to the very top, move JS as far down as possible).
The net result is that for a page which would take 11 seconds to load on Builder 2.x, the equivalent page in Builder 3 takes 1.8 seconds to load. It feels fast!
Read more: Performance Tuning 3.x
Search Engine Optimisation
No, not Confluence's search engine, public ones like Google and Yahoo!
With Theme Builder appearing on more and more public-facing sites, SEO had started to become an issue.
Amongst other things, we've now added new features for controlling "robots" - for example, should pages be indexed, should their snippets come from public directories, should links be followed?
Theme Defaulting
Oh the joy. In our theme admin you can now set the default layouts to use for global and personal spaces. Create a new space using Builder as it's theme and the relevant layout is automatically applied. Sweet.
Gah, the phone rings - looks like that's all for now! You probably won't hear from me again until Builder 3 is released but you can keep track of where things are up to in our user guides.