Builder - Performance Tuning

This page lists various techniques for tuning the performance of the Builder theme...

Builder is a highly visual theme which contains several javascripts, images and other components to render pages. This page lists various ways to improve the performance of the theme on your Confluence installation.

Resource Servlet Caching

Issue: Menu takes up to 20 seconds to load
Affects: All versions of Builder running on Confluence 2.1.x

Prior to Confluence 2.2, there is an issue with the "Resources Servlet" that results in images (such as menu icons) being re-loaded each time you visit a new page.

The servlet is a core part of Confluence that allows resources (such as graphics, javascripts, etc) that are stored within plugins to be accessed by the web browser.

Because the servlet did not provide sufficient information to the web browser, files were not getting cached.

Adaptavist identified this issue and raised a bug report with Atlassian.

From Confluence 2.2 onwards, our recommended alterations have become part of Confluence which will massively improve performance of the servlet for a wide range of plugins.

Solution

If you are using Confluence 2.1.x, it is possible to manually apply a patch if you have access to a friendly Java developer - for more information, please see our Conditional GET patch instructions.

If you are unable to apply this patch manually, consider upgrading to 2.2 which includes this patch as standard.

Workaround

If you are unable to apply the patch of upgrade Confluence, an alternative is to upgrade Builder to version 1.5.4 or above which has a feature to turn off icons in the view and edit menus.

View/Edit Menu Icons

Issue: Menus take up to 4 seconds to load in Firefox browser
Affects: All versions of Builder accessed via Firefox browser

There are numerous icons on the view and edit menus which can cause delays in theme rendering over slow connections, particularly on the Firefox web browser.

Even with the "Conditional GET" patch described in the section above, Firefox still checks each file to see if it has changed and this can lead to menus taking up to 4 seconds to appear depending on connection speed.

In order to resolve this issue, additional patches will be required to the Resources Servlet (some of which are described in this comment), however these have not yet been implemented or tested.

Workaround

Prior to a patch being available for Confluence, you can upgrade to Builder 1.5.4 or above which has an option to turn off the menu icons on the view and edit menus thus avoiding this delay.

Slow Automated Menus

Issue: Automated menus, created with macros, can sometimes be slow
Affects: All versions of Builder and Confluence

Our menu tutorials show various examples of automating menu contents by using macros such as the children macro, toc macro and incoming-links macro.

Some macros, the children macro in particular, can generate huge menus. We ran in to this problem here in our user guide where we used to generate the Macros menu as follows:

* [Macros] {children:page=Macros|all=true}

As we added more and more macro sections and tutorials, the "Macros" menu became huge and started to make page rendering in our user guide slower and slower.

Solution

There is no specific solution, other than to limit the size of the menus generated with macros. Obviously, that depends on which macros you are using.

Example: Limiting the items returned from the children macro

To limit the depth of the menu, use the "depth" parameter:

{children:page=Macros|depth=1}

To limit the number of items returned at the top level of the results, use the "first" parameter:

{children:page=Macros|first=10}

The actual solution to over-sized menus depends on the macros you are using, the examples shown above are just tricks that worked for us.

Remember: The bigger your menus get (number of items), the slower they get.

Footer Content Speed

Issue: Some macros in the page footer can slow down page rendering
Affects: Clients who use resource-intensive macros in the footer

If you use macros within footers, extra processing will usually be required on the server whilst those macros go off and get additional information from the database, etc.

Solution

Use the cache macro (available here) to cache your footer.

For example, if your footer is something like this:

{some-macro} {another-macro}
some wiki text or whatever

You can cache that footer, on a page by page basis, as follows:

{cache:refresh=1d}{some-macro} {another-macro}
some wiki text or whatever{cache}

In the example shown above, the footer will be cached for 1 day for each page.