• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Something in the PatternSkin slows down Internet Explorer.

Example TWikiVariables takes 23 seconds to load on IE and 4 seconds on Firefox.

I have tried to disable all the decorations by commenting out everything in css.pattern.templ. I then get a very naked looking page which still takes 22 seconds to load. A theory can be that it is the table design that IE is choking on.

Since IE is the mostly used browser - especially in corporate environments - it is a requirement that TWiki works with IE.

The issue is worse with large topics like TWikiVariables. But even with smaller topics the slow performance can be felt. That is probably why Dakar feels so slow and non-responsive in general when you just browse around a Dakar installation using IE. Benchmarking shows Dakar is between 10-30% slower than Cairo. But the subjective feeling is that the difference is much larger when you use IE. And the reason is that between the basic HTML load and loading the remaining elements (GIFS etc) IE spends a lot of time choking on something in the Patternskin. The minute you choose skin=classic also IE. shows a topic like TWikiVariables in 4 seconds.

-- TWiki:Main.KennethLavrsen

What are your experiences using another skin?


How does NatSkin/PatternTheme (Cairo based) perform?


TWiki:Main,MichaelDaum just mentioned in TWikiIRC that perhaps the culprit of the "slowliness" is the twisty mechanism (the javascript) in pattern. See here


The reason it is there is to support no-javascript. So var makeHiddenElements = getElementsByClassName('twistyMakeHidden'); is used to hide the elements that are displayed by default.

Not to say this cannot be optimized, just to issue a warning not to overlook no-javascript support.


As I wrote in TWiki:Codev.DakarPerformanceIssues

I tried another thing. I saved the TWikiVariables webpage (File>Save As>Web Page Complete) on my local harddisk. This saves an HTML file and a subdirectory with all the graphics, .js and .css files. And it still takes IE 22 seconds to open it! Interesting observation. I wish there was a way to debug the execution of code in IE so we could learn where is stalls.


I've looked at the twisty script. It could be optimized if there was a way to discover the twisty parts on the page with the onload (initTwist) - but I wouldn't know how to do this. We cannot just write id=twisty= because ids must be unique. A twisty button is now marked as <span id="demoshow">. We could iterate over all ids in the page to find xxxshow, but that could be even slower than finding all elements with classname twistyMakeVisible.

If someone has a bright idea, the rules are:

  • xxxshow : this element is initially hidden and should be made visible with javascript
  • xxxhide : ditto
  • xxxtoggle : this element is initially shown and should be made hidden with javascript

(where xxx is the twisty id)

Optimization tips from http://homepage.mac.com/rue/JS_Optimization_Techniques/:

NodeLists are lists of elements from object properties like .childNodes and methods like getElementsByTagName(). Because these objects are live (updated immediately when the underlying document changes), they are memory intensive and can take up many CPU cycles. If you need a NodeList for only a moment, it is faster to index directly into the list. Browsers are optimized to access node lists this way. So instead of this:
nl = document.getElementsByTagName("P");
for (var i = 0; i < nl.length; i++) {
  p = nl[i];
Do this:
for (var i = 0; (p = document.getElementsByTagName("P")[i]); i++)
In most cases, this is faster than caching the NodeList. In the second example, the browser doesn't need to create the node list object. It needs only to find the element at index i at that exact moment.

I can't get this to work though, perhaps getElementsByClassName works differently than getElementsByTagName.

I can think of a hack to use the name attribute: <div name="twist">, but that does not validate because divs do not have a name attribute. But forms do. So the hack is to put <form name="twist" action=""></form> around the twisty. Formally ugly, but it validates and can reduce looking up time.


I just tried to delete the twist.js from /pub/TWiki/TwistyContrib and that makes IE load large topics at the same speed as Firefox so there is no doubt this is where the problem lies.


Tried to put some alerts inside twist.js.

    function initTwist () {
        var makeHiddenElements = getElementsByClassName('twistyMakeHidden');
        alert ("MHE: "+makeHiddenElements.length);

The results is that after many many seconds the alert box comes up saying "MHE: 0"

So the code is hanging for a long time in getElementsByClassName('twistyMakeHidden') and the function just returns 0.

So what about this function

function getElementsByClassName(className) {
    var elements = [];
        var allObjects = (document.all) ? document.all : document.getElementsByTagName("*");

        for (var i = 0; i < allObjects.length; ++i) {
            if (allObjects.item(i).className.indexOf(className) != -1)
        return elements;

I also tried to alert out the i variable. The function loops through something like 2885 objects in a topic like TWikiVariables. It is a similar number in Firefox. But it seems IE takes a hell of a time to loop through this.

I can also see that the loop is called 3 times. Even in a normal size topic like the many I have on my Motion Twiki the loop runs through 400-500 items 3 times. So it is not only a giant topic like TWikiVariables that gets slowed down by this code in IE.

-- TWiki:Main.KennethLavrsen

I wouldn't be surprised if IE had problems with memory allocation due to the use of a dynamic array. Suggestion: Use

    var allObjects = (document.all) ? document.all : document.getElementsByTagName("*");
    var elements = new Array(allObjects.length);


-- TWiki:Main.JoachimBlum

Twisty optimize bug entry: Item1071


The major part of slowness can be contributed to non-optimal javascript (see: TWiki:Codev.DakarPerformanceIssues). Discarding this entry, continued in Item1071.


After SVN update 7683 (and previous updates to the javascript code) the TwikiVariables topic now loads much faster

Before the fix

  • IE: 23.2 seconds
  • Firefox: 3.7 seconds

After the fix

  • IE: 2.9 seconds
  • Firefox: 3.4 seconds

All measured using Ethereal and the time is from first GET to last ACK.

So very good job. AC may have additional actions to persue in Item1071. But the reason for this bug and the reason for the urgentcy was the extreme slowness of IE and that seems resolved. In order for people that are testing beta 4 to find the resolutions to already closed bugs I change the state of this from Discarded to Closed.

Very good job CC and AC.

As an extra good thing. This also means that IE no longer "hangs" in a state where you cannot click cancel. I almost filed a bug on it but lacked enough description of the symptom to put in the bug report. This is also resolved with the update of the Javascript code. That is really good.


-- TWiki:Main.KennethLavrsen

Summary Pattern Skin combined with Internet Explorer is dead slow
ReportedBy KennethLavrsen

SVN Range -7683
AppliesTo Engine

Priority Urgent
CurrentState Closed

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2005-11-30 - MartinCleaver
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback