Page History

{scrollbar:no-css=true}
h1. Performance Tuning

*{excerpt}This page lists various techniques for tuning the performance of the Builder theme...{excerpt}*

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.

h2. Logo Size

*Issue:* Pages load slow due to large logo
*Affects:* AnyoneSites with ahuge logo that'sfile hugesizes

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 20KBthat, you should seriously consider trimming it down...

h3. 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|ADAPTAVIST:Contact Us] and we'll see what we can do.

h2. Large Style Sheet

*Issue:* Large stylesheet being loaded on every single page
*Affects:* ThemesClients whereusing themassive style sheet hasn't been put in to an external filesheets

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.

h3. 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.

h2. Resource Servlet Caching

*Issue:* Menu takes up to 20 seconds to load, graphical macros seem slow
*Affects:* AllClients versionsusing of Builder running on ConfluenceConfluence 2.1.0 - 2.1.x5a

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)files 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 and were therefore loaded far more often than requied.

Adaptavist identified this issue and raised a [bug report|http://jira.atlassian.com/browse/CONF-5418] 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.

h3. Solution

The easiest solution is to upgrade to Confluence 2.2 which completely fixes the problem.

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|http://confluence.atlassian.com/x/lYkC] instructions.

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

h3. Workaround

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

h2. View/Edit Menu Icons

*Issue:* Menus take up to 4 seconds to load in Firefox web browser
*Affects:* Visitors Allto versionsyour ofsite Builderwho accesseduse viathe Firefox web 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.

EvenAdaptavist 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 commenthave identified [further issues|http://confluence.atlassian.com/display/DISC/Confluence+Patch+-+Supporting+Conditional+GET+When+Serving+Plugins+Downloadable+Resources?focusedCommentId=170376#comment-170376]) with the Resource servlet in Confluence which, howeverat thesepresent, have not yet been implemented or testedresovled.

h3. Workaround

Prior to a patch being available for Confluence, you can upgrade to Builder 1.5.46 or above which has an option to turn off[load the menu iconsas onquickly theas view and edit menus thus avoiding this delaypossible|Menu Settings].

h2. Slow Automated Menus

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

Our menu tutorials Clients using macros that output huge amounts of data

Some of our [menu tutorials|Menus] 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,  When used correctly, these enable you to have your menus automatically adapt to changes in your content.

However, some macros can generate huge amounts of menusinformatio. We ran in to this problem here in our user guide where we used to generate the Macros menu as follows:

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

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.

h3. Solution

ThereThe ismost no specificobvious solution, other thanis to limit the size of the menus generated with macros. Smaller Obviously,menus thatwill depends on which macros you are usingbe faster.

*Example:* Limiting the items returned from the [children macro]

To limit the depth (number of levels) of the menu, use the "depth" parameter:

{noformat}
{children:page=Macros|depth=1}
{noformat}

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

{noformat}
{children:page=Macros|first=10}
{noformat}

TheYou actualmay solutionneed to use over-sizedalternate menusmethods dependsdepending on the macros you arear usingeusing, the examples shown above are just tricks that worked for us.

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

h3. Workaround

If you have no choice other than to have huge menus, you can upgrade to Builder 1.6 or above which has an option to [load the menu as quickly as possible|Menu Settings] - although this will not reduce the amount of data the browser receives, it allows massive menus (even with 10,000+ items) to display almost instantly.

h2. 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.

h3. Solution

Use the [cache macro] ([available here|Scripting and External Content Plugin]) to cache your footer.

For example, if your footer is something like this:

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

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

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

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

h3. Workaround

If caching can't be used (depending on the types of macro you are using in your footer), try using alternate macros or restrict use of macros in the footer of highly-used spaces.

{center}| {rate:Rate This Page} | Could it be improved? {contactus} |{center}