Large DOM Performance issue

[gizmo1177]

We have some performance problems with pages that have many elements in the DOM. On one page we have 7000 elements in the DOM.

In the center of our application we have a paginated datatable that shows 100 rows per default. Select/unselect of rows and update of detail area is really slow. If we reduce the row count to 10 rows selection is much faster. Is there any way to get a better performance without reducing the tables row count?

[kukeltje]

Is firebug enabled?

[cagatay.civici]

Can you try opening the page with 100 rows and no row selection as well just to try?

[gizmo1177]

We use firebug to analyze the page but while usage it is not activated. Here are some test results from firebug and yslow.

Firebug result on row change:
POST: 135kb -> 3.57 seconds (stated as "waiting" in firebug)
GET: 12.1kb -> 5ms

YSlow:
There are 9758 DOM elements on the page
A complex page means more bytes to download, and it also means slower DOM access in JavaScript. Reduce the number of DOM elements on the page to improve performance.

I found out that the pages that are slow contains some dialog composite components. The dialogs does only shows data (without logic) and are hidden in my test case. When I remove the dialogs I will get the following results on row select.

Firebug result on row change:
POST: 135kb -> 1.37 seconds (stated as "waiting" in firebug)
GET: 12.1kb -> 16ms

YSlow:
There are 8499 DOM elements on the page
A complex page means more bytes to download, and it also means slower DOM access in JavaScript. Reduce the number of DOM elements on the page to improve performance.

Reducing the row count to ten rows doesn´t bring better performance, so I think the problem belongs to the dialogs.

Any tips? I have really no idea how to fix it. Uncommting of the dialogs is not really a solution .

I found a similar post in pf forum about dom problems. Please see:
viewtopic.php?f=3&t=5817&p=24705&hilit= ... nce#p24705

YSlow shows some more performance tips but I think the main Problem is the large DOM.

[gizmo1177]

For your interest. Large DOM etc. is bad but does not cause the performance problems we have. It´s also no problem with primefaces components. The real problem are the composite components. The last weeks we developed core composite components to reduce code redundancy and have centralized places for changes. We replaced each individual implementation within our application(s) with the composite component.

First test case:
We´ve created a single page with a commandButton, a outputText and 50 composite components that contains a p:dialog. Click on the button just updates the outputText component.
The update takes about 1.5 seconds.

Second test:
Same page with commandButton and outputText component. Instead of using the composite components we´ve added the p:dialogs directly to the page.
The update takes 0.06 seconds.

[porthos]

Thanks for the update. I've started placing dialogs inside composites as well recently. (Didn't used to work very well with PF2.x).

We haven't noticed significant slowdown yet. But a typical page currently has only about 5-10 dialogs inside of composites.