Skip to end of metadata
Go to start of metadata

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?

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.

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.

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.

 Example - Caching the "Other Pages" menu

The view menu has several areas that can be cached and we've provided an example below based on the current structure of the view menu at the time of writing this article.

 {submenu}{menuicon:document}This page
  {menuitem}{menuicon:document_plain}{menulink:normalView}Normal view{menulink}{menuitem}
  {menuitem}{menuicon:printer}{menulink:printableView}Printable view{menulink}{menuitem}
  {menuitem}{menuicon:pdf}{menulink:exportPDF}Export to Adobe Acrobat (PDF){menulink}{menuitem}
  {menuitem}{menuicon:word}{menulink:exportWord}Export to Microsoft Word{menulink}{menuitem}
  {menuitem}{menuicon:mail}{menulink:exportMail}Export mail to page{menulink}{menuitem}
  {menuitem}{menuicon:about}{menulink:information}%page% information{menulink}{menuitem}
  {menuitem}{menulink:favourite}%add% %page% as favourite{menulink}{menuitem}
  {menuitem}{menulink:watch}%watch% this %page%{menulink}{menuitem}
 {submenu}{menuicon:documents}Other pages
  {menuitem}{menuicon:house}{menulink:home}Home page{menulink}{menuitem}
  {menuitem}{menuicon:document_new}{menulink:recent}Recent updates{menulink}{menuitem}
  {menuitem}{menuicon:magic-wand}{menulink:RSS}RSS feed builder{menulink}{menuitem}
  {menuitem}{menuicon:document_into}{menulink:map}Site map{menulink}{menuitem}
  {menuitem}{menuicon:paperclip}{menulink:spaceattachments}Attachments index{menulink}{menuitem}
  {menuitem}{menuicon:id_card}{menulink:profile}Preferences: %user%{menulink}{menuitem}
  {menuitem}{menuicon:user1_into}{menulink:login}Log in{menulink}{menuitem}
  {menuitem}{menuicon:user1_add}{menulink:signup}Sign up{menulink}{menuitem}
  {menuitem}{menuicon:door2}{menulink:logout}Log out{menulink}{menuitem}
 {menuitem}{menulink:children}Show children (%count%){menulink}{menuitem}
 {menuitem}{menulink:comments}Show comments (%count%){menulink}{menuitem}

By caching the "Other Pages" menu, which contains links that are generally available to anyone who can view the space, we've cached the output of 34 macros. Even though those macros don't do much, they still take time to process and when you think of how many times a page is viewed in a single day it's obvious that this will improve performance of your site.

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.

  • No labels