indexmenu JS index loads very slowly -> replace image loading

A large menu loads very slowly because there are so many images. While it's loading, it's too tall, and then it collapses down. Two things can be done to fix this:

Specify width and height of all IMG tags. For example <img width="8" height="8" src="icon_plus.gif">
Use CSS backgrounds instead of IMG tags. This will allow DokuWiki (Anguna or higher) to convert the images to inline CSS, which will make it immensely faster. For example:

CSS:

.indexmenu_icon_plus {
  display:inline-block;
  width:8px;
  height:8px;
  background-image:url(icon_plus.gif);
}

May 24 '13 12:05 zioth

Can you supply some numbers please? How many nodes do you list?

I haven't no priorities for looking into this. Maybe Samuele? Otherwise it depends at other contributions.

Workaround: maybe it helps to reduce the size of the tree that's displayed at once, by defining number of displayed levels? You can do that by adding #1 behind the namespace definition. For example {{indexmenu>:wiki#1|js}} instead of {{indexmenu>:wiki|js}}

May 24 '13 12:05 Klap-in

I'm displaying maybe 15 nodes at once, so it's not a huge number.

Fix #1 should be very easy. It won't make the tree render any faster, but it will keep it from jumping around while it's rendering. Fix #2 would make it render far faster, and make it much more usable as a sidebar.

May 24 '13 13:05 zioth

One of the issues with fixed sizes is that there are icons with different sizes. (Mostly 18px x 18px)

May 24 '13 13:05 Klap-in

I guess that at the moment i have a too fast connection, because i can not reproduces jumping, with a page with more indexes, which containts my whole test wiki (large) too.

May 24 '13 13:05 Klap-in

Default theme: 18x18 px

Some of the checked themes: tree images 18x18px, folder images 16x16px

doku theme - more strange sizes.

Proposal: 18x18px is default, other images need rescaling.

May 24 '13 13:05 Klap-in

Good point, though alternate themes could use different CSS files to specify the height and width.

May 24 '13 13:05 zioth

Your second approach allows that a theme supplies its own css, so that it can also define its own image sizes, isn't?

So better the second approach is implemented.

I have no experience with using sprites (all images combined in one image). Is that an useful improvement too? or to difficult for contributors? @samuelet what are your thoughts?

May 24 '13 13:05 Klap-in

Sprites would speed things up, but would be very difficult for contributors, as you suggest. Fix #2 would allow the images to be inlined, which would be even faster than sprites. The default theme could always have images inlined, while leaving the option open for alternate themes with non-inlined images.

This change is relatively easy. If samuelet doesn't have time, I'd consider doing it myself (when I have time, which might take a while).

May 24 '13 13:05 zioth

What is inlining of images? that you embed base-encode images in the css file?

May 24 '13 14:05 Klap-in

Yes. base64 encoding, preferably done to a compressed png to minimize size and allow transparency (the free Windows tool "Png Optimizer" does a good job compressing png files).

May 24 '13 14:05 zioth

Inline images seem a good compromise, but it needs anyway to adapt the indexmenu.js script (i'm thinking for example to the open/close function). I will look at this but, considering my few time, if Zioth wants to contribute even only with a starting branch to work on, i think it'll greatly speed up the thing. Just a question to understand its severity, does the browser cache mitigates the current behaviour as i suppose? I mean, it happens only during the first page view in presence of a slow connection or also during next views?

May 25 '13 09:05 samuelet

The cache sometimes helps during the same browser session, but if you close and re-open the browser, it has to check the server to see whether any files have been updated, and that check is just as large as the image itself in this case, due to the minimum size of TCP packets.

I might take a look later if I have time. I don't think it will be very hard.

May 26 '13 01:05 zioth

It looks like doing this will invalidate all current themes. Is that okay?

May 26 '13 17:05 zioth

Ok for me. I think that themes can be easly converted, but if i'm wrong we have anyway a new branch to work on.

May 26 '13 19:05 samuelet

There is a new JavaScript tree based on Fancytree introduced (use treenew option, before it becomes the default). It uses sprites or font icons. I expect this must bring improvements. However, maybe I will replace the icon fonts by a limited set of svg icons that are included with the plugin, that needs probably some attention regarding this topic.

Dec 24 '23 00:12 Klap-in