Page display performance tips and techniques

Introduction

Confluence allows more advanced users to construct pages that bring in data from various sources and present the data in nice ways like charts and tables. Unfortunately, some of these types of pages can be very slow to render for users. Fortunately, there are a number of advanced techniques that can be used to significantly improve page rendering performance or restructure pages to provide a better user experience. This page will give somehints and tips for improving performance to render complex pages.

Rendering

Render is the Confluence process that takes page markup and converts it into html that is sent to the browser. In simple terms, the time taken to display the page in the browser is determined by:

1. Server processing - Confluence server processing that converts page markup into html
2. Download time - to transfer the html and all referenced images, scripts, and related information to the browser
3. Browser - rendering time

Constraints

1. is constrained by the amount of CPU needed to do the server work - this is primarily a single threaded activity and can only be improved by single processor rates.
2. is constrained by communications bandwidth which can be variable depending on time and location
3. is constrained by browser performance with FireFox considered to be generally faster than Internet Explorer (IE)

Factors to address

1. is most impacted by page construction techniques to reduce processing load
2. is addressed by reducing the size of the rendered text and images
3. is addressed by browser options (caching) and by pages that best optimize browser capabilities (like caching)

Server processing

It is important to note that all the elements of a page must be rendered even if portions of the page are not displayed initially. For instance, if you use constructs that have tabs or have expand and contract sections, all the data in those sections still must be rendered. Generally, the display of the data is controlled by the browser with no further interaction with the server (an exception is delayed rendering discussed below). This means that pages with a large amount of data that is gathered and processed but not shown immediately to the user, may be wasted processing if the most likely user interaction is to not look at that tab or hidden section.

Extracting data from other systems via SQL or other techniques can take a significant amount of time. Similarly for metadata reporting. Is the data static or dynamic? Does it need to be current to the second or just to the day, week, or month?

Converting data from other formats into charts and tables can be expensive. The cache macro can help here too, but there are special considerations for charts. The chart macro converts the chart data into a image that is then sent to the browser to display.

Letting the user make an explicit choice before viewing information that is expensive to produce can sometimes provide a better user experience. Instead of producing a page that has all the data that the user may need, let the user specify their specific need for data first.

Download time

The techniques above in many cases also help with download time. Pages with less data download faster. Providing page links to data spread out the interaction time over a number of requests. A balance must be made to make sure the user gets the data they normally want without excessive amount of clicking.

Browser

The caching techniques above also help with browser performance. Browser will be able to locally cache static images.

Cookbook

Lots of static charts

If you have a lot of charts that are relatively static (only change occasionally), the best approach is to save the chart image as an attachment and re-use this image for subsequent viewing. This is easy to do:

1. Add the following parameters to your chart macro:
   • attachment=your attachment name.png - this stores the chart image as an attachment to the page (or optionally another page)
   • attachmentVersion=keep - this tells the chart macro to only render the chart data and redraw the image if the attachment referenced by the attachment parameter does not exist

• How can the chart be regenerated? Just delete the attachment and view the page to get it to regenerate the attachment.
• Should I use the cache macro too? No, not in this case unless there is some other reason to use it on the page.

Lots of data gathering

SQL data, excel data, or metadata reporting are expensive (time) operations. If the data is static or it is acceptable for it to be a bit out of date, then use the cache macro specifying the refresh period appropriate for your situation.

• How can the data be regenerated?
  • Add showRefresh=true to the cache macro to provide a button for users to press to get a refresh
  • Or add ?refresh=true to the url for the page in the browser - this can be used by advanced users (usually page authors) or be included in a link provided by the author on some page

Dynamic data gathering used for charts

Decide on an acceptable amount of time the data can be out of date - it might be hours or minutes. Suppose it is 1 hour.

1. Use the cache macro:
   • refresh=1h - this means the data will be retrieved if older than 1 hour
   • checkAttachments=false - this says the cache will be used even if attachments have been changed on the page
2. Add the following parameters to your chart macro:
   • attachment=your attachment name.png - this stores the chart image as an attachment to the page (or optionally another page)
   • attachmentVersion=replace - this tells the chart macro to replace the attachment that represents the chart

• How can the data be regenerated? It is the same case as just using the chart macro.

Mixture of static and dynamic data

Use a combination of the above techniques but narrowed to cover the data of each type.

Multiple portions of a page

If the page has multiple portions that each can take a while to render and the techniques above do not apply, use the future macro around the later portions of the display so that the user perceives that the page is available quicker even though more data gathering is taking place in the background. This is especially useful for tabbed displays where the data on the tabs can be. Warning, the tab to be displayed may not be first one, since, the tab the user last used on a previous visit may be shown first.

Automated caching

The first user to view a page after the cache period has expired can be delayed a significant amount of time while the cached data is being refreshed. One way to mitigate that is to have a background process that can cause the cache to be replenished on a regular basis. The trade-off is additional processing that takes place even if no one is viewing the page verses a faster initial display. One technique is to have various pages with different automated refresh times. By adding an include on the time refresh page, that include page will be rendered as well. Alternatively, the automation can just have a list of page with refresh times. Here is an example of standard refresh times:

• every 15 minutes
• every hour
• every 3 hours
• every day (6:00am)
• every week (Sunday)
• once a month (first day of month)

confluence --action renderPage --space demo --title "my title"