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.

Logo Size

Issue: Pages load slow due to large logo
Affects: Anyone with a logo that's huge

We've encountered some cases of clients using huge logos - not their on-screen size (width and height) but their file size.

The logo shown at the top of this page is about 14.6KB - not perfect, but good enough for our needs.

If your logo is bogger than about 20KB, you should seriously consider trimming it down.

Solution

There are various techniques for reducing the file size of logos:

• Use a different image format: JPEG, GIF or PNG all give different results and one will generally be smaller than the others
• If you are using JPEG compression, try reducing the quality of the image – significant reductions in file size can be made for only minor loss in image quality, this is especially true for photographic images
• If you are using a GIF image, try reducing the number of colours in the image
• If you are using a PNG image, which is ideal for logos and other graphics with large areas of flat colour, ensure that compression is switched on.

Generally, it's a case of trial and error to find the best settings.

If you've found your logo to be huge and are having trouble shrinking it down, [send it to Adaptavist] and we'll see what we can do.

Large Style Sheet

Issue: Large stylesheet being loaded on every single page
Affects: Themes where the style sheet hasn't been put in to an external file

Builder comes with a default style sheet showing all the various settings we've used to improve content design and even resolve a few issues with the inbuilt stylesheets that come with Confluence.

Because the style sheet is editable in the CSS Custom Styles setting, it makes it relatively easy for you to alter it and add your own styles, etc.

However, that style sheet gets embedded in to each page that uses the Builder theme and as such increases the file size of the page.

Solution

To resolve this issue, follow the instructions in our tutorial on Creating CSS Files which shows how to move the style sheet in to a separate file that can then be referenced by the theme thus ensuring the style sheet is only loaded once after which it can be cached by your web browser.

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.

Unknown macro: {center}

Your Rating: Thanks for voting! Please Wait Results: 2 rates

Could it be improved? Unknown macro: {contactus}