Menu Performance Tuning

This document explains how to improve performance of menus in Builder 2.x and above...

Based on common scenarios, the following sequence of tuning tips apply to most sites:

1. If you don't want to show the View and/or Edit menu to anonymous users, use the hideanon==true setting of the viewmenu macro and/or editmenu macro. Remember to provide a link somewhere that allows people to log in!
2. Disable the "Show icons in the View and Edit menus" setting in Menu Options.
   • If you've turned off menu icons, you can modify your View and Edit menu and delete the menuicon macro references. Obviously, if you wanted to turn them back on at a later date you'd have to add them all in again so download your theme config before making this change.
3. Modify your View and Edit menus to remove any items that aren't required. For example, most people don't need the Dashboard menu item in the "View > Other Pages" menu because there is a link to the dashboard in the breadcrumb trail.
4. Enable the "Display menus as quickly as possible" setting in Menu Options - this is particularly useful if you have a huge number of items in your menus.
5. Disable the "Display shadows behind pop-up menus" setting in Menu Options - this reduces the number of files loaded for menus.
6. Disable the "Display menu item tool tips" setting in Menu Options - this reduces the amount of processing required (only a tiny amount) to render the menus in the web browser.

In general, the bigger your menus are, the more work Confluence has to do. Likewise, bigger menus create more HTML for users to download and also there's more work for the browser to do when it comes to rendering all that HTML and using JavaScript to draw the menus. Always look for ways to reduce the number of items in your menus, for example rather than having another sub-menu, could you just direct the user to a page with additional navigation links on it?

Caching Menus

Using the open source cache macro you can cache any content within Confluence for a specified amount of time. While the content still needs to be downloaded by end-users, the caching reduces the amount of work the server has to do - instead of processing all the wiki notation and macros, it just returns a cached copy of the output.

Be very careful!

You need to take in to consideration that the cache macro uses a global cache for all users - if the cached content contains information that's only available to specific users, and the cache is created when those specific users view that content, then other users will see the cached content for those specific users.

Let's use the preferences option on the View menu as an example:

{menuitem}{menuicon:id_card}{menulink:profile}Preferences: %user%{menulink}{menuitem}

Because this macro is processed each time a page is served, it will output different things depending on who is viewing the page:

• If the user is not logged in, the item will not be displayed - because they don't have any preferences as an anonymous user
• If the user is logged in then the item "Preferences: name" will be displayed in the menu, where name will be replaced with their full name and therefore each user will see their own name.

Now, if you wrapped that item in the cache macro as follows:

{cache}{menuitem}{menuicon:id_card}{menulink:profile}Preferences: %user%{menulink}{menuitem}{cache}

Whoever first views the page, prior to the item being cached, will see the item appropriate to them:

• If logged in, they will see the Preferences item and their name
• If logged out, they won't see the Preferences item

Whatever they see, it will then be cached for up to a day (if there are over 100 separate caches, the oldest caches are deleted to make room for new caches).

So, let's imagine the user who creates the cache is called John. All other users, including anonymous users, would see "Preferences: John" for the next 24 hours or so. That will freak everyone out!

Luckily, this doesn't pose an actual security risk as Confluence will ask them to log in (if they were logged out) or take them to their own preferences page (if they were logged in). However, the fear factor of seeing someone elses' name on the preferences option will frighten most users from using the site.

Likewise, system administrators will freak if they find that the Site Administration link in the Edit menu is being shown to end-users - they'll immediately consider it a security concern and lose confidence in Confluence.

So, while the actual security risk of using the cache macro in menus is very low - assuming you have set-up Confluence's privileges correctly - you should be extremely careful when using it because if used incorrectly people will lose confidence in your wiki.

Future warning

Adding cache macros in to your menu notation makes it harder to maintain - you might get weird errors or artefacts appearing and not know whether they are related to the cache, the menus or some other aspect of your configuration.

In a future version of Builder we're going to be implementing our own caching mechanism in the various menu macros provided with the theme - this will allow you to cache any menu far more safely because our cache will use different caches for users, etc.

Wherever possible, we encourage you to wait until we add that feature before using any form of caching in the menus.

We strongly discourage the use of the cache macro in the Edit menu because every item needs to thoroughly check the privileges of the user viewing the page.

See Also

• Performance Tuning
• compound-menuitem macro (Theme Builder 3.x and above only)