.

Logo Size

Issue: Pages load slow due to large logo
Affects: Sites with huge logo file sizes

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 bigger than that, 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: Clients using massive style sheets

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, graphical macros seem slow
Affects: Clients using Confluence 2.1.0 - 2.1.5a

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

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

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

Workaround

If you are unable to apply the patch of upgrade Confluence, an alternative is to upgrade to Builder version 1.6 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 web browser
Affects: Visitors to your site who use the 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.

Adaptavist have identified further issues with the Resource servlet in Confluence which, at present, have not been resolved.

Workaround

Prior to a patch being available for Confluence, you can upgrade to Builder 1.6 or above which has an option to load the menu as quickly as possible.

Pages with Images

Issue: Pages with lots of images take longer to load
Affects: Users on slow connections; Internet Explorer users.

If you put lots of images on a page you increase the amount of information the end-user has to download so that's going to make the page load slower regardless which web browser is being used.

Solution

Reduce the number of images on the page, or make them smaller. Consider using the [gallery macro] which displays thumbnails of the images or use the [??thumbnail?? parameter] when adding images to pages.

If a page seems to load a lot more slowly in Internet Explorer than other browsers, consider disabling PNG support as that will reduce the amount of work the browser has to do.

Slow Automated Menus

Issue: Automated menus, created with macros, can sometimes be slow
Affects: Clients using macros that output huge amounts of data

Some of our menu tutorials show various examples of automating menu contents by using macros such as the [children macro], [toc macro] and [incoming-links macro]. 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 information. 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

The most obvious solution is to limit the size of the menus generated with macros. Smaller menus will be faster.

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

To limit the depth (number of levels) 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}

You may need to use alternate methods depending 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.

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

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.

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.

|

Your Rating:

Thanks for voting!

Please Wait

Results:

3

rates